[jira] Commented: (GERONIMO-3489) Deployment problems caused by file deletion failures

["Shiva Kumar H R (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GERONIMO-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530643 ] 

Shiva Kumar H R commented on GERONIMO-3489:
-------------------------------------------

Thanks Ted for raising this. I have hit this problem many a times when deploying from within Eclipse Plug-in. I use Windows XP + NTFS + Sun JDK 1.5.0_11.

> Deployment problems caused by file deletion failures
> ----------------------------------------------------
>
>                 Key: GERONIMO-3489
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-3489
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: deployment
>    Affects Versions: 2.0.1
>            Reporter: Ted Kirby
>             Fix For: 2.0.2, 2.0.x, 2.1
>
>
> File.delete() failures in IOUtil.recursiveDelete() are causing various deployment problems.  I open this JIRA to discuss them to see how the server might better handle them.  In all but one case, delete failures are not even noted with a log record!  Deletion problems are seen in many environments and platforms, but they are persistently fatal when using a NFS file system for the repository.
> In investigating the problem, I have added code to recursiveDelete to retry the delete a few times if it fails.  I added code to list directory contents if a directory delete failed, and saw a file named .nfs000000002bc43500000053e in the directory.  My first attempt at a bypass was to retry a failed delete 5 times, sleeping a second before each try.  This did not work.  I added a call to System.gc() before each sleep, and this got me passed the problem.  Interestingly, two retries were required to get this to work.  In another version, each retry was a second longer, and I printed all file names in a directory before trying the delete.  This worked in most cases, but required the full 5 retries, so I suspect System.gc() would have time.  System.runFinalization() would be something else to try.
> RepositoryConfigurationStore.createNewConfigurationDir(Artifact) shows the failing end of the deletion problem, with the dreaded ConfigurationAlreadyExistsException("Configuration already exists: " + configId)exception.  I think this message is not good.  It should really say directory already exists.  If the file is not deleted on undeploy, this failure occurs on a subsequent deploy.  What is really bad is if the user invokes a redeploy operation, and the file delete fails on the undeploy.  It is important that undeploy not complete until the file goes away.
> From other environments, I am not convinced that all file handles and references, and particularly open streams, are being closed on some artifacts.  This will cause the delete to fail.  It may be that the gc() calls are cleaning these up, and allowing the deletes to work in my case above.
> Another option is that RepositoryConfigurationStore.createNewConfigurationDir(Artifact) not throw a ConfigurationAlreadyExistsException if the only problem is an empty directory structure exists.  The next line creates the directory structure anyway.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.