ZipEntryContext retention in JBoss EAP 5

Resolution

• A workaround is to reduce the number of deployed jars:
  • Slim EAP 5.
  • For applications that use the same library version, move any duplicate jars amongst deployments to $JBOSS_HOME/server/$CONFIG/lib/.
• use unzipped deployments
• use the below JVM option to re-order in-memory JAR handling to reduce VFS cache memory consumption at potential performance hit:

-Djboss.vfs.optimizeForMemory=true

The jboss.vfs.optimizeForMemory option causes JBossVFS to open the jar prior to and close it after each operation. The potential benefit is that it does not need to keep the zip metadata in memory between requests. The drawback is than reading the zip metadata for each request can be very expensive.

The potential benefit only sometimes help (and often does not), since reloading the metadata frequently adds garbage collection pressure, and if operations are frequent the transient memory used loading it is often higher than the memory saves between calls. Class files are only loaded once to initialise the class and possibly on startup for annotation scanning. The main problem comes from the loading of non-class resources, such as ServiceLoader service files (if the service is not cached), or library configuration files.