Plague of jar files

One of the development app servers that we recently upgraded to Java 6 and JBoss 5.0.0.GA’s hard drive filled up.  I emptied 4GB out of the Recycle Bin, which let a build complete Friday, but by this morning it was full again.

A diligent co-worker discovered a server\default\tmp\vfs-nested.tmp\ directory containing 67,444 hexadecimally-named jar files totalling 16GB in size.

The Research

A quick search turned up this in the JBoss 5.0.0.Beta4 Release Notes:

Excessive nestedjarNNN.tmp files in the tmp directory. The VFS unwraps nested jars by extracting the nested jar into a tmp file in the java tmp directory. This can result in a large number of files that fill up the tmp directory. You can disable this behavior by setting -Djboss.vfs.forceNoCopy=true on command line used to start jboss. This will be enabled by default in a future release, JBAS-4389.

That was 5.0.0 Beta 4.  In 5.0.0.CR1, JBAS-4389 made NoCopy the default behavior.  Also in CR1 though, JBAS-5262 replaced the jboss.vfs.forceNoCopy setting with a jboss.vfs.forceCopy setting defaulting to false; and JBAS-5633 enabled jboss.vfs.forceCopy by default, if unspecified.

SO THAT… by the time you get to the JBoss 5.0.0.GA Release Notes, we see:

JBoss VFS provides a set of different switches to control it’s internal behavior. JBoss AS sets jboss.vfs.forceCopy=true by default.

A Workaround

I gather that to turn off the copying for JBoss5.0.0.GA, we would set

-Djboss.vfs.forceCopy=false

on the JBoss command line.

Update: It looks like when we set the forceCopy flag to false, the heap space may fill up in memory instead.  We may need a better solution!

Update 2: In this JBoss forum thread, alesj says:

I’ve got the fix locally, just need to create some proper long running tests.  But this will be definitely included in the up-coming 5.0.1.