Need to be able to use property file to shut off JBoss's exp
memoryerror May 14, 2004 10:48 PMWe are one inch from the goal line in terms of getting acceptance from an extremely large customer (Fortune 50, seriously). What we are asking for in this post will eliminate the remaining gap.
We need to be able to configure JBoss from a property file to not call runGarbageCollector() in SystemImpl.java.
We are obviously able to comment out the call ourselves, and recompile, which we have already done, but the extremely large customer refuses to deploy on a custom build. They are already very very skeptical about open source, and about JBoss, and are a WebLogic shop.
If we can get this control moved to a property file, in an official release of JBoss, it will eliminate the we-can't-deploy-a-custom-build objection, which eliminates the last remaining obstacle to getting them to accept on JBoss. (We have already passed all of the other tests needed for acceptance.)
The reason we need to shut off JBoss's explicit GC call is that we have very tight response requirements on every transaction, and every time JBoss makes that call, it causes transactions to take too long. (We are using the concurrent GC, but JBoss's call appears to invoke the default GC. That might be something that should also be looked at.)
We can't just shut off all explicit GC on the JVM command line using XX:DisableExplicitGC, because our own application needs to explicitly call GC during its initialization, while loading a huge set of data from the database into an in-memory cache. We have to do the load in chunks, and call GC after each chunk, because when we tried loading all of the data at once, the concurrent GC crashed the JVM with a “problematic thread” error. This bug is fixed in 1.5, but 1.5 is beta, and therefore also forbidden by the extremely large customer (and JBoss doesn’t support 1.5 yet anyway).
Once we have the data loaded, from then on we never call GC explicitly ourselves, and we canÂ’t have JBoss doing so either.
If we could start with the default GC during initialization, and then switch dynamically to concurrent GC after that, it would work around the JVM crash bug, and allow us to not have to load in chunks, which would allow us not to have to make explicit GC calls, which would allow us to invoke XX:DisableExplicitGC on the command line, obviating the need for our request. But we canÂ’t.
If we could invoke XX:DisableExplicitGC after initialization, that would also obviate the need for our request. But we canÂ’t.
If we could use 1.5, it would solve all of our problems. But we canÂ’t.
So we are left with asking for an official version of JBoss in which we are able to use a property file to shut off JBossÂ’s call to runGarbageCollector() in SystemImpl.java.
We are using Windows 2000 Server, JDK 1.4.2, JBoss 3.0.7, and SQL Server 2000. All of the Windows software has the latest service packs and windowsupdate.microsoft.com patches.