Hi, Byron.
Definitely. I'm actually going to write a short blog very soon about my
process for diagnosing locked jars on Windows and I'll put a link to the
hack jar there. I'll also describe the set-up to get the app server to
use it instead of the normal one.
- Tim
Byron Nevins wrote:
> Tim,
> Can I have a copy of this hack jarfile? Also, exactly how does one
> get the hacked jar to override the JVM files?
>
>
>
> Tim Quinn wrote:
>> 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
>>>>