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.
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.
I gather that to turn off the copying for JBoss5.0.0.GA, we would set
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!
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.