Mark Eggers wrote:
Folks,
Off topic, so I'm going to be burning a little karma (OK, a lot).
Environment:
Window 7 64 bit
JRE 1.7.0_25
Tomcat 7.0.42 (with tcnative) run from startup.bat
I have a web application that scans for a resource path using:
this.getClass().getClassLoader().getResources(resourcePath)
It then wanders through the resources, checking the protocol for each
URL in the returned enumeration.
Based on the protocol, the URL is scanned for desired information and
the names of those resources are collected.
For a JAR file, I use the following code (don't shoot me - I'm an admin
/ architect, not a developer).
public ArrayList<String> getResources(String resourcePath,
String ending) {
JarURLConnection urlCon = null;
Pattern p =
Pattern.compile("^" + resourcePath + "/.+(" + ending + ")$");
try {
urlCon = (JarURLConnection) url.openConnection();
urlCon.setUseCaches(false);
JarFile jar = urlCon.getJarFile();
Enumeration<JarEntry> je = jar.entries();
while (je.hasMoreElements()) {
String entry = je.nextElement().getName();
if (log.isDebugEnabled()) {
log.debug("JAR entry: " + entry);
}
Matcher m = p.matcher(entry);
if (m.matches()) {
resources.add(entry);
}
}
} catch (IOException ex) {
resources.add("Could not open resource");
if (log.isErrorEnabled()) {
log.error("Could not open resource",ex);
}
} finally {
if (null != urlCon) {
urlCon = null;
}
}
return this.resources;
}
Finally,
this.getClass().getClassLoader().getResourceAsStream()
is used to obtain the resources, process them, and stuff them into a
HashMap managed by a singleton.
This is all done via a servlet context listener, and the HashMap is
emptied in the listener's contextDestroyed method.
On Linux, this all works well. I can deploy and undeploy with abandon.
The Tomcat manager reports no leaks.
On Windows, I cannot cleanly undeploy. The JAR files containing the
resourcePath (and hence the resources) remain in
%CATALINA_HOME%\webapps\appname.
However, once even a minor garbage collection occurs I can then cleanly
undeploy the web application.
I have several solutions:
1. context.xml antiResourceLocking="true"
This works, but there are a lot of downsides ( noted in the
documentation). This also indicates that an underlying InputStream is
being held open when parsing the JAR file. The solution is also Tomcat -
specific.
2. Never package the desired resources in a JAR
This works, but developers may balk. Also, the path to the desired
resources must be unique, otherwise you could still trigger loading from
a JAR (although I could just not handle JAR scanning).
3. Copy the JAR file to java.io.tmpdir, extract, and read
This is ugly, but might work. It would impact the application start up
time even more, but the JAR scanning issue would no longer exist. I
think Glassfish does this.
4. Use a properties file
Read in a properties file with a list of desired resources, and use that
list to populate the singleton. This is actually what I had in place
before, but this then requires developers to manage both the resources
and the list.
This solution also makes developing a modular, platform-independent
build system more difficult (it can be done, just creates an extra step
using Maven). Right now the build is a convoluted Ant script that
requires a specific environment. I'm trying to get away from that.
5. Do this right
How, I'm not exactly sure. Hence, the question.
I'll go a bit on a limb here, so someone may shoot me too and you won't be
alone. (*)
It's also [OT][OT], just to provide some background information.
I believe that the underlying issue here is the difference in behaviour between Windows
and Unix/Linux, with regard to a file opened by one process, when another process tries to
delete the file.
Unix/Linux allow this. The file entry in the directory is deleted, the process deleting it
gets no error. The file itself is not deleted, and the process which has it open still has
a handle to the file and can continue to access it.
Under Windows however, the process trying to delete the file gets an error, at the very
moment of the "delete".
What probably happens here, is that one level below the InputStream which holds the
filehandle in Java, is some native file object which has the file open. The InputStream
object is discarded at tbe Java level, but is only really destroyed at the next GC. In the
meantime, the underlying native object still holds the file. When the GC happens, the
underlying filehandle is closed, and everyone is happy.
(*) I don't see why they would though. I'm pretty impressed by your admin/architect code
above, and wish I was as fluent in Java as you seem to be.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
