[
https://issues.apache.org/jira/browse/GERONIMO-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532435
]
Ted Kirby commented on GERONIMO-3489:
-------------------------------------
I tested G3489-3 patch, and it worked.
I tested with a sample app that deployed to (whose location was):
repository\org\apache\geronimo\applications\examples\geronimo-jsp-examples\2.0\geronimo-jsp-examples-2.0.war
Both before and after the fix, if any subcomponent/subset of the location
existed, deploy would succeed.
The fix works when the entire location exists, it is a directory, and the
directory is empty.
I log a debug message to show how many and which files are in the location
directory, if it exists.
In my testing, I did not see the message in my server log. I attributed this
to the server currently having logging severely locked down to WARN logging,
and my not being able to find all the places I needed to tweak to enable DEBUG
logging. Is there any doc on how to do this?
> 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
> Assignee: Donald Woods
> Fix For: 2.0.2, 2.0.x, 2.1
>
> Attachments: G3489-1.patch, G3489-2.patch, G3489-3.patch
>
>
> 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.
