-
1. Re: JBoss/Tomcat deleting it's own config files
timhague Jun 16, 2003 8:24 AM (in response to timhague)An update on this - it appears to be a ZipException caused by having too many Zip files open - vis:
13:02:10,263 WARN [JARDeployer] operation failed; ignoring
java.util.zip.ZipException: Too many open files
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:112)
at java.util.jar.JarFile.(JarFile.java:117)
at java.util.jar.JarFile.(JarFile.java:55)
at org.jboss.deployment.SubDeployerSupport.processNestedDeployments(SubDeployerSupport.java:200)
at org.jboss.deployment.SubDeployerSupport.init(SubDeployerSupport.java:127)
at org.jboss.deployment.MainDeployer.init(MainDeployer.java:668)
at org.jboss.deployment.MainDeployer.init(MainDeployer.java:686)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:604)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:564)
)
Does anyone know if this has been fixed in more recent versions of JBoss? -
2. Re: JBoss/Tomcat deleting it's own config files
jonlee Jun 16, 2003 9:00 AM (in response to timhague)Java imposes no real limitation on open files. However, the underlying operating system will impose restrictions. On *nix, you can use ulimit to increase this.
If your deployments are taking a long while, it may be possible that you have several deployers executing in parallel. You could increase the time between deployment scans to overcome this.
It is also possible that your OS is munching the files as the OS file interface and Java separate during the exception. I've only seen this in Windows with their file-locking work-around. -
3. Re: JBoss/Tomcat deleting it's own config files
timhague Jun 17, 2003 11:21 AM (in response to timhague)I've been keeping a track of the files in the tmp\deploy directory. I'm now attempting to manually delete all the files that I can between deployment - unfortunately I can't delete any archive files at all.
Attempting to manually delete these archives - even ones that have now been undeployed, results in 'The source or destination file may be in use' message - i.e. they are still being locked by JBoss.
I'm going to try upgrading to 3.2.1 to see if that actually releases archive file locks on undeployment!
Where can I look to find out what has changed/been fixed from one version of JBoss to the next? -
4. Re: JBoss/Tomcat deleting it's own config files
jonlee Jun 17, 2003 2:44 PM (in response to timhague)Go here for change notes:
http://sourceforge.net/docman/?group_id=22866
You'll probably find that the underlying problem is Windows and its file-sharing, file locking mechanism - I'm assuming that you are using Windows. Linux and the others usually don't care too much if you delete a file from under the program - even if it crashes the program. The problem probably is due to the file stream remaining open until the file stream object is reaped.
I haven't looked at the code around this area but I assume the objects linked to the temp files are no longer in scope but not garbage collected. You could try playing with GC and see if this gets things to release.