I second Byron's comments completely about the handle utility. It's
very helpful.
With most cases I've worked on - especially when restarting the server
resolves the problem - it is indeed the app server's JVM that has locked
the file and handle can verify this quickly. My next step is usually
the following unsupported but extremely useful hack. I have a small jar
file that contains a hacked version of the Java runtime's classes that
come from ZipFile.java (which JarFile extends). The hack I wrote logs,
for selected ZipFile objects, a stack trace that shows where the file
was opened from. When such ZipFile objects are closed, it records that
also. I then use an awk script on the log file to find which files were
opened but not closed. That leads me directly to the particular stack
trace for that ZipFile instance which, usually, implicates the code that
opened but failed to close the ZipFile.
It's a fairly simple matter of setting a couple of jvm-options in the
app server's domain.xml to instruct the app server to add this small
hack jar file as a prefix to the bootclasspath (so the JVM uses my
hacked ZipFile instead of the real one from the Java runtime) and
restart the server.
You can probably see why this is completely unsupported, but it's
extremely useful for diagnosing problems like this.
- Tim
Byron Nevins wrote:
> A very very useful tool that runs on Windows is Handle
> <http://www.sysinternals.com/utilities/handle.html>
>
> You simply run it like so:
>
> /handle batik
> /
> -- it will tell you what process is using (and has locked) the jar file
>
> Example output from my system:
>
> c:\dev\src\webapps\remodel>*handle appserv*
>
> Handle v3.01
> Copyright (C) 1997-2005 Mark Russinovich
> Sysinternals - www.sysinternals.com
>
> java.exe pid: 3220 C:\pe\lib\sun-appserv-ant.jar
> java.exe pid: 3220 C:\pe\lib\appserv-upgrade.jar
> java.exe pid: 3220 C:\pe\lib\appserv-tags.jar
> java.exe pid: 3220 C:\pe\lib\appserv-jwsacc.jar
> java.exe pid: 3220 C:\pe\lib\appserv-cmp.jar
> java.exe pid: 3220 C:\pe\lib\appserv-admin.jar
> java.exe pid: 3220 C:\pe\lib\appserv-deployment-client.jar
> java.exe pid: 3220 C:\pe\lib\appserv-ext.jar
> java.exe pid: 3220 C:\pe\lib\appserv-rt.jar
> java.exe pid: 3220 C:\pe\lib\appserv-jstl.jar
> java.exe pid: 3220 C:\pe\lib\appserv-ws.jar
> java.exe pid: 3220 C:\pe\lib\appserv-launch.jar
>
> Tim Quinn wrote:
>> Hi, Roger.
>>
>> Roger I Martin PhD wrote:
>>> While redeploying I'm hitting
>>> Module directory is locked and cant be deleted: {1}
>>> frequently. The webapp is jsf based and I'm employing backing beans
>>> which employ batik. The Batik jar cannot be deleted from the
>>> module's folder. Everything else is gone.
>>>
>>> How to avoid?
>> I assume this is on a Windows system.
>>
>> There have been numerous issues with jar files remaining locked on
>> Windows systems and, therefore, causing problems redeploying or
>> undeploying the app to which they belong.
>>
>> There are a variety of potential causes for this. To figure out
>> exactly what's going on:
>>
>> 1. Which build of GlassFish are you using?
>>
>> 2. Can you share the app with us? If so, you could send it to me in
>> e-mail or send me a link by which I could retrieve it.
>>
>> 3. If you aren't able to or comfortable with sending the app to us,
>> let me know. There is an alternative that we could pursue if needed.
>> Thanks.
>>
>> - Tim
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>