geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy" <c1vams...@gmail.com>
Subject Re: Offline Deployer leaving behind temporary files
Date Wed, 23 Jan 2008 15:02:09 GMT
Kevan,

I am testing this with an ear file.  So, the EARConfiBuilder should be
reading this file.  I guess it is the same with other builders as well.  The
JarFileClassLoader has the following comment

 * Note: This implementation currently does not work reliably on windows,
since the jar URL handler included with the Sun JavaVM
 * holds a read lock on the JarFile, and this lock is not released when the
jar url is dereferenced.  To fix this a
 * replacement for the jar url handler must be written.

BTW, I am running G 2.0.3-SNAPSHOT on Win XP.

++Vamsi

On Jan 23, 2008 7:48 PM, Kevan Miller <kevan.miller@gmail.com> wrote:

>
> On Jan 23, 2008, at 5:23 AM, Vamsavardhana Reddy wrote:
>
> I see the following in Deployer.java
>
>             // todo jar url handling with Sun's VM on Windows leaves a
> lock on the module file *preventing rebuilds*
>             // to address this we use a gross hack and copy the file to a
> temporary directory
>             // the lock on the file will prevent that being deleted
> properly until the URLJarFile has
>             // been GC'ed.
>             boolean cleanup = true;
>             try {
>                 tmpDir = File.createTempFile("geronimo-deployer",
> ".tmpdir");
>                 tmpDir.delete();
>                 tmpDir.mkdir();
>                 tmpFile = new File(tmpDir, moduleFile.getName());
>                 DeploymentUtil.copyFile(moduleFile, tmpFile);
>                 moduleFile = tmpFile;
>
> Can someone explain the "preventing rebuilds" part in the above?  It is
> followed by code that creates a temporary copy of the module archive that
> should be cleaned up by DeployerReaper which does not delete these files in
> case of offline deployment.  In online deployment also, the files may be
> left behind if the DeployerReaper does not get a chance to run after the
> files are added to pendingDeletionIndex.  Incase of offline deployment
> DeployerReaper does not get a chance at all as the java process terminates
> immediately.  I have tried deleteOnExit() as well with offline deployment,
> but the files won't just go away.  I am wondering if the reason this is
> introduced in the first place is applicable to 2.x.  If not, we can get
> rid of this code.
>
>
> Hi Vamsi,
> Well, the fact that the files are locked indicates a problem, I think. Can
> you tell who's reading the files? I thought we would be using
> org.apache.geronimo.kernel.classloader.JarFileClassLoader and would thus
> avoid the Windows file locking problem.
>
> Hmm, perhaps we're not calling JarFileClassLoader.destroy()? This should
> free up the file locks.
>
> --kevan
>

Mime
View raw message