Geronimo
  1. Geronimo
  2. GERONIMO-3764

DeployerReaper fails to cleanup the temp directories left behind by deployer

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.1, 2.0.2, 2.1
    • Fix Version/s: 2.0.3, 2.1
    • Component/s: deployment
    • Security Level: public (Regular issues)
    • Labels:
      None

      Description

      Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it.

      1. GERONIMO-3764-2.0.patch
        1 kB
        Vamsavardhana Reddy
      2. GERONIMO-3764-deploymentutil.patch
        4 kB
        Vamsavardhana Reddy

        Activity

        Hide
        Vamsavardhana Reddy added a comment -

        Completed: At revision: 613388 in branches\2.0 and trunk (2.1).
        o DepoymentReaper needs full path, not just the filename.
        o DeploymentUtil.recursiveDelete() returns true upon successful deletion.
        o Remove the dirName, not deleteDir from pendingDeletionIndex.

        Show
        Vamsavardhana Reddy added a comment - Completed: At revision: 613388 in branches\2.0 and trunk (2.1). o DepoymentReaper needs full path, not just the filename. o DeploymentUtil.recursiveDelete() returns true upon successful deletion. o Remove the dirName, not deleteDir from pendingDeletionIndex.
        Hide
        Vamsavardhana Reddy added a comment -

        Offline deployer does not get a chance to cleanup temporary files

        Show
        Vamsavardhana Reddy added a comment - Offline deployer does not get a chance to cleanup temporary files
        Hide
        Vamsavardhana Reddy added a comment -

        GERONIMO-3764-2.0.patch:

        How about DeployerReaper cleaning up temp directories left by any previous runs?

        Anyone has a better idea?

        Show
        Vamsavardhana Reddy added a comment - GERONIMO-3764 -2.0.patch: How about DeployerReaper cleaning up temp directories left by any previous runs? Anyone has a better idea?
        Hide
        Vamsavardhana Reddy added a comment -

        deleteOnExit() seems to be a better option. But then deleteOnExit() does not delete files if the JVM is terminated abnormally.

        Show
        Vamsavardhana Reddy added a comment - deleteOnExit() seems to be a better option. But then deleteOnExit() does not delete files if the JVM is terminated abnormally.
        Hide
        Vamsavardhana Reddy added a comment -

        Completed: At revision: 614127 in branches\2.0 and trunk (2.1)
        o DeployerReaper in offline deployment does not get a chance to reap the temporary directories. Reap these directories in the next run.
        o If anyone has a better idea on how to handle this or sees something I am missing, please suggest/comment.

        Show
        Vamsavardhana Reddy added a comment - Completed: At revision: 614127 in branches\2.0 and trunk (2.1) o DeployerReaper in offline deployment does not get a chance to reap the temporary directories. Reap these directories in the next run. o If anyone has a better idea on how to handle this or sees something I am missing, please suggest/comment.
        Hide
        Vamsavardhana Reddy added a comment -

        Completed: At revision: 614136 in branches\2.0 and trunk (2.1)
        o Cleanup even when creation of temp file for deployment fails

        Show
        Vamsavardhana Reddy added a comment - Completed: At revision: 614136 in branches\2.0 and trunk (2.1) o Cleanup even when creation of temp file for deployment fails
        Hide
        Vamsavardhana Reddy added a comment -

        Incase of offline deployment, using deleteOnExit also did not help. Even at jvm process termination the locks on the files are not released and so the files are left behind.

        Show
        Vamsavardhana Reddy added a comment - Incase of offline deployment, using deleteOnExit also did not help. Even at jvm process termination the locks on the files are not released and so the files are left behind.
        Hide
        Vamsavardhana Reddy added a comment -

        GERONIMO-3764-deploymentutil.patch:
        The reason for archive files getting locked is that some of the code uses URLs to extract content from the archive, for e.g., application.xml from an ear file. See http://marc.info/?l=geronimo-dev&m=120111383903434&w=2 . We will need to update DeploymentUtil and the attached patch gives an idea on what should be done. The drawback is that we may end up with more temp files (but these will be deletable as soon as the deployment operation completes) and deleteOnExit may be called only if delete fails on these files.

        Comments? Suggestions? Help!!!

        Show
        Vamsavardhana Reddy added a comment - GERONIMO-3764 -deploymentutil.patch: The reason for archive files getting locked is that some of the code uses URLs to extract content from the archive, for e.g., application.xml from an ear file. See http://marc.info/?l=geronimo-dev&m=120111383903434&w=2 . We will need to update DeploymentUtil and the attached patch gives an idea on what should be done. The drawback is that we may end up with more temp files (but these will be deletable as soon as the deployment operation completes) and deleteOnExit may be called only if delete fails on these files. Comments? Suggestions? Help!!!
        Hide
        Vamsavardhana Reddy added a comment -

        Completed: At revision: 615134 in branches\2.0 and trunk (2.1)

        NestedJarFile and UnpackedJarFile use DUMMY_JAR_FILE in their
        constructors with super(DUMMY_JAR_FILE) but the close method does not
        invoke super.close(). Because of this, the DUMMY_JAR_FILE is locked and
        so, it does not get deleted at JVM termination.

        Show
        Vamsavardhana Reddy added a comment - Completed: At revision: 615134 in branches\2.0 and trunk (2.1) NestedJarFile and UnpackedJarFile use DUMMY_JAR_FILE in their constructors with super(DUMMY_JAR_FILE) but the close method does not invoke super.close(). Because of this, the DUMMY_JAR_FILE is locked and so, it does not get deleted at JVM termination.
        Hide
        Vamsavardhana Reddy added a comment -

        Completed: At revision: 615225 in branches\2.0 and trunk (2.1)
        o When url.openStream() is used to read an individual file from an archive i.e. when protocol is "jar", the archive file is locked even after the stream is closed and it prevents immediate deletion of temporary files created during the deployment process. This can be avoided by using JarFile.getInputStream() instead.

        Show
        Vamsavardhana Reddy added a comment - Completed: At revision: 615225 in branches\2.0 and trunk (2.1) o When url.openStream() is used to read an individual file from an archive i.e. when protocol is "jar", the archive file is locked even after the stream is closed and it prevents immediate deletion of temporary files created during the deployment process. This can be avoided by using JarFile.getInputStream() instead.
        Hide
        Vamsavardhana Reddy added a comment -

        Completed: At revision: 615389 in branches\2.0 and trunk (2.1)
        o NestedJarFile should close the baseJar irrespective of whether it is packed or not. In case of inPlace deployment of an ear file, not closing baseJar is resulting in a lock on DUMMY_JAR_FILE.

        Show
        Vamsavardhana Reddy added a comment - Completed: At revision: 615389 in branches\2.0 and trunk (2.1) o NestedJarFile should close the baseJar irrespective of whether it is packed or not. In case of inPlace deployment of an ear file, not closing baseJar is resulting in a lock on DUMMY_JAR_FILE.
        Hide
        Vamsavardhana Reddy added a comment -

        Completed: At revision: 615417 in branches\2.0 and trunk (2.1)
        o NestedJarFile should close the baseJar only if it is created by itself.
        o This is sort of correcting the previous rev 615389 which may close the parent jar in one case (I doubt if we will be hitting that instance in Geronimo, but just to keep things straight...)

        Show
        Vamsavardhana Reddy added a comment - Completed: At revision: 615417 in branches\2.0 and trunk (2.1) o NestedJarFile should close the baseJar only if it is created by itself. o This is sort of correcting the previous rev 615389 which may close the parent jar in one case (I doubt if we will be hitting that instance in Geronimo, but just to keep things straight...)
        Hide
        Vamsavardhana Reddy added a comment -

        Completed: At revision: 617648 in branches\2.0 and trunk (2.1)
        o EARConfigBuilder should close modules when deployment fails due to already existing configuration. Otherwise deployer leaves temp files behind.

        Show
        Vamsavardhana Reddy added a comment - Completed: At revision: 617648 in branches\2.0 and trunk (2.1) o EARConfigBuilder should close modules when deployment fails due to already existing configuration. Otherwise deployer leaves temp files behind.
        Hide
        Vamsavardhana Reddy added a comment -

        Completed: At revision: 617659 in branches\2.0 and trunk (2.1)
        o Offline deployer leaves temporary files behind since using URLs with "jar" protocol locks the jar file and prevents deletion. This is prevented by creating a temporary file when the protocol is "jar".
        o This behaviour is controlled using a system property "org.apache.geronimo.deployment.util.DeploymentUtil.jarUrlRewrite" which is false by default, meaning no change from existing behavior for online-deployer.
        o Offline deployer sets the system property to true.
        o See http://www.mail-archive.com/dev@geronimo.apache.org/msg55811.html

        Show
        Vamsavardhana Reddy added a comment - Completed: At revision: 617659 in branches\2.0 and trunk (2.1) o Offline deployer leaves temporary files behind since using URLs with "jar" protocol locks the jar file and prevents deletion. This is prevented by creating a temporary file when the protocol is "jar". o This behaviour is controlled using a system property "org.apache.geronimo.deployment.util.DeploymentUtil.jarUrlRewrite" which is false by default, meaning no change from existing behavior for online-deployer. o Offline deployer sets the system property to true. o See http://www.mail-archive.com/dev@geronimo.apache.org/msg55811.html
        Hide
        Vamsavardhana Reddy added a comment -

        I think I really nailed this one . If anyone finds I cracked open something else in the process, please reopen the JIRA or create a new one.

        Show
        Vamsavardhana Reddy added a comment - I think I really nailed this one . If anyone finds I cracked open something else in the process, please reopen the JIRA or create a new one.

          People

          • Assignee:
            Vamsavardhana Reddy
            Reporter:
            Vamsavardhana Reddy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development