geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: Offline Deployer leaving behind temporary files
Date Wed, 23 Jan 2008 14:18:41 GMT

On Jan 23, 2008, at 5:23 AM, Vamsavardhana Reddy wrote:

> I see the following in
>             // 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.

View raw message