I am trying to figure out if the IBM Persistent Reusable JVM is still relevant and supported with latest Java versions. There is very little I find when searching on internet. There is just this document that talks about it and it looks very old, it refers to JDK 1.4.2 and mentions that the -Xresettable feature is deprecated. I have tried using -Xresettable with JDK 8 and that failed as expected, that however doesn't mean the entire concept doesn't work and hence the question. We have a requirement where we want to invoke a JVM from C code and keep the JVM around and not destroy it for further request processing. Since the OS is z/OS which runs IBM JVM, I am trying to understand if the Persistent Reusable JVM is an option though my hopes are dim. If anyone knows about it, please let me know.
If it turns out to be outdated, I will evaluate other options of keeping a JVM alive, but that's secondary right now.
I believe it is as you fear: the Persistent Resusable JVM feature never made it past Java 1.4.2.
If you haven't checked it out yet, look at the -Xshareclasses JVM option available in the more current IBM Java releases. It creates a shared memory cache of user and system classes, mostly with no impact to applications - somewhat similar in result to what persistent reusable JVM did, but without the side-effects.
Related
We are using Drools in a Java 11 Web application via the kie-spring library.
This library depends on xstream.
The compatibility of xstream with newer Java versions is uncertain as described in this Issue which is already 3 years old and not going to be "fixed" as far as I understand it.
Is there a plan to switch to a different underlying technology or any other changes that would move away from xstream? Or at least a way to get rid of the JVM warning and assurance that it will work with future versions?
This is an XStream problem. The very link which is shared in the original question, provide some valid solutions to avoid the mentioned XStream issue.
Is there [...] at least a way to
get rid of the JVM warning and assurance that it will work with future
versions?
As can be seen on this change https://github.com/kiegroup/drools/pull/2988#issuecomment-658079653 modifications are already underway to resolve the mentioned issue as it manifests inside the Drools project which make use of the XStream library.
So this is resolved currently for the Drools' DMN module, and Kogito; if you spotted a specific module of Drools which is not yet updated, you are encouraged to raise a JIRA.
Question on StackOverflow is one of the channel we monitor as #schrobe correctly commented here; if you need a more back/forth exchange you can also interact with Drools developers via chat or forum. All these are valid channel that we monitor as originally described in the project get help page.
I hope this fully answers your original question, let us know if you noticed the issue in other modules!
I would like to run Erlang application on a centOS server for stress testing. I would like to know what I must accomplish to deploy a Erlang application before I send it to the server admin to install and run.
What will I need to tell my admin to properly run an Erlang app on a server? (Basically how can I send him a file and give him an really stupid easy instructions to install it?)
Is their a way to send my app in a executable format that the admin can easily install with? Kinda like PyPy?
How can I perform code swapping? Will the app need to be in it's code state still in order to do this?
I would appreciate any help to make this process easy. Thank you!
For anyone just passing by: Even though this is my first Erlang app, I highly recommend anyone wanting to build a easy to scale server user Erlang. The benefits are amazing, if you know how to use Erlang properly.
Cheers!
The usual way of deploying an Erlang program (I'm avoiding the word application here, as it's somewhat ambiguous in an Erlang context) involves building a release (see this for some background). A release is essentially a packaging of your Erlang code (which often consists of multiple applications - hence the ambiguity) and the parts of the runtime system required to run it. The Erlang release system was designed with code upgrades in mind.
If you are using Rebar to build your program, you may find this article helpful. In addition to describing how to build a release (the process is a bit tricky) it also explains how you can deploy an upgrade.
A similar guide is also available for users of erlang.mk. If you're not using one of them already, or a comparable build tool, I strongly encourage you to do so as it makes release handling much less painful.
You may also find the answers to this question helpful. They list some additional options.
We are evaluating few options for developing a telecommunication related application platform (and migrating/consolidating some of the standalone apps into the new platform). One of our main concerns is the ability to handle high volume of requests during peak hours.
We feel the TorqueBox seems to an interesting solution worthy of consideration because:
Speed (Next to pure Java performance)
Faster development time over Java
Maintainability
Support for threads/concurrency even though it's Ruby
Faster/Easier front end development with Rails
...
RedHat supported and runs on JBoss (scalability, future development and ability to call Java if necessary)
Has anyone developed/deployed similar application(s) with JRuby/TorqueBox?
Any serious performance bottlenecks ahead? (or why we shouldn't use JRuby and should stick with Java?)
The answer is YES but be aware of memory leaks (gems, threadsafety issues, etc). You have to be familiar with tools like VisualVM, Eclipse MAT and/or NewRelic.
We're successfully using Torquebox on production for some clients on amazon EC2 handling 60k-80k visits per day (new c3 instances are great for Java).
Deployment is also an issue. We're unable to setup any kind of rolling restart because of memory consumption. So every time we deploy using Capistrano a full JBoss restart is needed (no big issue for us).
Bests,
Antonio
yes any mature Java web-server with JRuby is a valuable option. the details of handling high-loads on peak hours will really depend on what kind of app you'll be running, how much "hardware" can you afford to use but in general it's achievable but be aware there might still be some "gotchas" e.g. Ruby libraries (gems) that do not handle thread-safety well. you simply need to understand how to proceed than - which seems you do since you're want to use 'Celluloid.IO' :)
My company has a large legacy Java code base and many of our customers run WebSphere and WebLogic. We are considering starting to use Scala but have been unable to confirm that Scala (2.9.X) works well with IBM's JDK (and BEA's JRockit).
Since these JVM's passes the TCK I would say that it should just work, but given the various problems I have had with the different JVM's over the years I am a little nervous. Are there any gotchas to be aware of when using scala with other JVM's ?
Any compiler flags to use (or avoid) ?
Should I compile the code using Scala on hotspot or on the customers JVM ?
Any problems with mixing JAR's compiled using different versions of Scala/Java on different JVM's ?
Any war stories, links and suggestions are welcome.
The Scala compiler should produce the same byte-code regardless of the JVM you use. I would expect Scala to run on all three platforms however HotSpot has tried to optimise for dynamic languages and might be slightly better. (Possibly not enough to worry about)
In recent years there has been less and less difference between these platforms and in the near future I expect them all to be directly based on OpenJDK (as IBM has agreed to support OpenJDK now) The JRockit and Hotspot teams have been merged for some time since Oracle owns both.
However if you are not running recent version of the JDK, you may see some issue.
JVMs talk to each other very well and I would consider running Scala in its own JVM to isolate any concerns you might have.
Yes, Scala works on non-Sun JVM. Consider, for instance, these two comments from the source code:
//print SourceAnnotation in a predefined way to insure
// against difference in the JVMs (e.g. Sun's vs IBM's)
// on IBM J9 1.6 do not use ForkJoinPool
There aren't many of these. After all, the various JVM are supposed to be compatible -- and tested for it. But, whereas issues arise, action is taken to make sure things run smoothly.
Nothing I could think of.
The compiler shouldn't make a difference, in fact if running scalac on different VM would generate different bytecode, it is definitely a bug.
You should always run Scala code with the same version of Scala it was compiled with. Code compiled on 2.x won't run on 2.x+1 by default. Code compiled on 2.x.y should run on 2.x.y+1, though.
I agree though, that it would be nice to get licenses from third-party vendors like IBM or Azul to include those platforms into testing.
I have a client that's running an application based on JBoss 4.0.5, Seam 1.2 and RichFaces 3.0.1. Their system is having performance problems due to the fact that a lot of data is coming back from the server to be displayed on screen and it seems like the rendering of that data is taking forever. The data brought back is displayed in a tabbed interface, but the tabs aren't currently being loaded individually, but all at once.
I'm trying to build up a case to present to the client on the benefits of upgrading to never version of RichFaces, which, as I understand it, has added a great number of features related to tabbed panels and being able to use ajax to page the data and load the chunks you actually need to display at the moment, and not the rest that's in other tabs.
The move to a newer version of RichFaces will also result in never versions of Jboss and Seam, as the current production build of RichFaces 3.2.1 requires JSF 1.2.
IF anyone has some suggestions or experience on performance of current versions RichFaces, paging, etc, I would really appreciate some feedback.
I haven't noticed much of a performance improvement by upgrading through various Richfaces versions. You're better off optimizing the code that is involved in the rendering - for example checking whether code is called mutliple times (as is the case when logic is placed in a getter).
I've found the bean-timing interceptor (#MeasureCalls) that Tobias Hill outlines in the Seam forum to be absolutely fantastic - more so than a profiler for specific problems (probably less so if you don't know where to start looking). It lets me track down those methods that are called more often than required and allows me to streamline my beans.
The forum link is : http://www.seamframework.org/Community/SeamPerformanceProblemRewardingWorkaround
One warning... I recently upgraded to JBoss 5.1.0GA, JSF 1.2, etc... so that our software stays current, but there is a drawback. JBoss 5 uses -significantly- more memory than JBoss 4, and takes longer to start. It would be wise for you to test our your new configuration on one machine before attempting to switch system-wide.
Use a profiler and do it for yourself. Only you have the application. Only you know which combination of components are "slow". I think you can measure it for yourself very fast.
p.s. show us the results ,-)
I find the Apache implementation of JSF1.2 much better the the Apache implementation of JSF1.0. I use a little RichFace 3.2 and it seems fine, still a bit too much information being sent on the ajax requests from the client so RichFaces Ajax executes much slower then a hand crafted AJAX solution, but code very much faster in RichFaces.