The
problem seems more complicated than I thought initially. The suggested
fix alone does not solve the problem. I also found input or output
streams are not closed in more places spread in different packages.
One
of the causes of the problem, I think, is the way how the deployers
work. When an application is deployed, JAR files are opened by creating
new JarFile objects to peek the info of the JAR file. For example, in
the accept() method of the JARDeployer class, JarFile object is created to
check if the JAR file contains META-INF or *.xml file or not. But, the JarFile
objects never closes because they are returned by JarURLConnection objects and
it closing the JarFile could cause the close of the application archive
file and therefore will break the deployment. Hence, the files are left
open. However, when the application is undeployed, there is no way to
check if the file is open or not in the deployer system and the opened files
never get closed. I think this is the reason why the temp files and
directories cannot be deleted during undeploying an application. And, it
is also the reason why repeated deploy and undeploy eventually causes "Too
many open files" problem.
Some
non-trivial work might need to sort this out.
Please let me know if I am correct or not.
Regards
Qingxian
Have you verified that the suggested change
fixes the problem?
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology
Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
----- Original Message -----
Sent: Tuesday, July 16, 2002 10:00
AM
Subject: [JBoss-dev] RE: InputStream
and JarFile are not closed in getManifest()
And this the reason why JBoss cannot delete the files after
undeploy EAR files or SAR files.
Qingxian
The getManifest() method of DeploymentInfo
class in org.jboss.deployment package does not close FileInputStream and
JarFile after creating or getting a Manifest object. This perhaps
is the reason why JBoss cannot close JAR files when undeploying EAR or
SAR files and therefore "Too many open files" problem is caused.
The snipet of the JBoss (3.0.0) code is as
follows:
/**
* getManifest returns
(if present) the deployment's manifest
* it is
lazy loaded to work from the localURL
*/
public Manifest getManifest()
{
try
{
if (manifest ==
null)
{
File file = new
File(localUrl.getFile());
if (file.isDirectory())
manifest= new Manifest(new FileInputStream(new File(file,
"META-INF/MANIFEST.MF")));
else // a
jar
manifest = new
JarFile(file).getManifest();
}
return
manifest;
}
// It is ok to barf at any time in
the above, means no manifest
catch
(Exception ignored) { return null;}
}
The suggested changes are as
below:
public Manifest getManifest()
{
try
{
if (manifest ==
null)
{
File file = new
File(localUrl.getFile());
if (file.isDirectory())
{
FileInputStream fis = null;
try
{
fis = new FileInputStream(new File(file,
"META-INF/MANIFEST.MF"));
manifest= new
Manifest(fis);
} finally { // close the input
stream
fis.close();
}
} else {// a
jar
JarFile jarFile = new
JarFile(file);
try
{
manifest =
jarFile.getManifest();
} finally { // close the
JarFile
jarFile.close();
}
}
}
return
manifest;
}
// It is ok to barf at any time in
the above, means no manifest
catch
(Exception ignored) { return null;}
}
Regards
Qingxian
Wang
This e-mail and any files transmitted with it
are confidential and intended solely for the use of the individual or entity
to whom it is addressed. If you have received this e-mail in error you must
not copy, distribute or take any action in reliance on it. Please notify the
sender by e-mail or telephone.
We utilise an anti-virus system and therefore
any files sent via e-mail will have been checked for known viruses. You are
however advised to run your own virus check before opening any attachments
received as we will not in any event accept any liability whatsoever once an
e-mail and/or any attachment is received. Any views expressed by an individual
within this e-mail do not necessarily reflect the views of Systems Union Group
plc or any of its subsidiary
companies.
