glassfish
  1. glassfish
  2. GLASSFISH-20234

autoundeploy directory-deployed application successful, then autodeploy it again false

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 4.0_b83
    • Fix Version/s: 4.1
    • Component/s: deployment
    • Labels:
      None

      Description

      Decompression hello.war to a directory named hello, copy the directory hello to autodeploy dir, and then rm it.It is deployed and undeployed. But next it is deployed false when I copy the directory hello to autodeploy dir again.

        Activity

        Hide
        Jeremy_Lv added a comment -

        I see. Here's some of my comments:
        1).Althought it seems a little strange because the useful warning messages was thrown out on the undeploy operation but it is failed in deploying the same application. As this solution will not affect the original syntax about the deployment...

        The issue is occured because we have deleted the related directory before clean the related info about the deployed application.
        So it can be also reproduce as follow:
        1). asadmin deploy test_sample.war
        2). delete the directory of test_sample under domains/domain1/applications/test_sample
        3). asadmin udneploy test_sample
        4). asadmin deploy test_sample.war
        After step4, it will be failed because of the application info isn't cleanup without restart the domain. We will continue to look into this if the syntax about this will change in the future.

        Show
        Jeremy_Lv added a comment - I see. Here's some of my comments: 1).Althought it seems a little strange because the useful warning messages was thrown out on the undeploy operation but it is failed in deploying the same application. As this solution will not affect the original syntax about the deployment... The issue is occured because we have deleted the related directory before clean the related info about the deployed application. So it can be also reproduce as follow: 1). asadmin deploy test_sample.war 2). delete the directory of test_sample under domains/domain1/applications/test_sample 3). asadmin udneploy test_sample 4). asadmin deploy test_sample.war After step4, it will be failed because of the application info isn't cleanup without restart the domain. We will continue to look into this if the syntax about this will change in the future.
        Hide
        Hong Zhang added a comment -

        Actually with some further testing/investigation today, I noticed the deployment infrastructure will not be able to always undeploy an application cleanly with its original source deleted. We can clean to the point we can, but it will require a server restart to ensure the server is in consistent state before any redeployment is attempted. For that reason, I have not committed the previous suggested change, and just enhanced the existing warning message to state a server restart is required for this kind of case (so code does not fail at an unexpected place with the source been deleted prior to undeployment).

        I am going to close the bug as "won't fix" as this is not a supported feature and looking at the current code, the undeployment code cannot be enhanced easily to guarantee a proper undeployment for such case.

        Show
        Hong Zhang added a comment - Actually with some further testing/investigation today, I noticed the deployment infrastructure will not be able to always undeploy an application cleanly with its original source deleted. We can clean to the point we can, but it will require a server restart to ensure the server is in consistent state before any redeployment is attempted. For that reason, I have not committed the previous suggested change, and just enhanced the existing warning message to state a server restart is required for this kind of case (so code does not fail at an unexpected place with the source been deleted prior to undeployment). I am going to close the bug as "won't fix" as this is not a supported feature and looking at the current code, the undeployment code cannot be enhanced easily to guarantee a proper undeployment for such case.
        Hide
        Jeremy_Lv added a comment -

        Hong:
        I think the solution you have comments is better than me because the variable of info can judge more conditions than only check about the appname.

        Show
        Jeremy_Lv added a comment - Hong: I think the solution you have comments is better than me because the variable of info can judge more conditions than only check about the appname.
        Hide
        Hong Zhang added a comment - - edited

        I tried to reproduce the problem from my side and I see what the problem is now.
        As the source directory does not exist for directory auto-undeploy case, the code went into that block which made it return too early and skip all the code to properly undeploy the application. To fix this and also continue accommodating the case that we tried to solve originally with this block, I think we could add the additional condition for checking "info". If "info" is non-null, it means the application is in memory and needs proper undeployment and should not go into this block and exit early.

        bash-4.1$ svn diff
        Index: UndeployCommand.java
        ===================================================================
        --- UndeployCommand.java        (revision 61867)
        +++ UndeployCommand.java        (working copy)
        @@ -304,7 +304,7 @@
                     }
        
                     File sourceFile = new File(source.getURI());
        -            if (!source.exists()) {
        +            if (!source.exists() && info == null) {
                         logger.log(Level.WARNING, "Cannot find application bits at " +
                             sourceFile.getPath());
                         // remove the application from the domain.xml so at least server is
        
        

        Let me know what you think.

        Show
        Hong Zhang added a comment - - edited I tried to reproduce the problem from my side and I see what the problem is now. As the source directory does not exist for directory auto-undeploy case, the code went into that block which made it return too early and skip all the code to properly undeploy the application. To fix this and also continue accommodating the case that we tried to solve originally with this block, I think we could add the additional condition for checking "info". If "info" is non-null, it means the application is in memory and needs proper undeployment and should not go into this block and exit early. bash-4.1$ svn diff Index: UndeployCommand.java =================================================================== --- UndeployCommand.java (revision 61867) +++ UndeployCommand.java (working copy) @@ -304,7 +304,7 @@ } File sourceFile = new File(source.getURI()); - if (!source.exists()) { + if (!source.exists() && info == null ) { logger.log(Level.WARNING, "Cannot find application bits at " + sourceFile.getPath()); // remove the application from the domain.xml so at least server is Let me know what you think.
        Hide
        Jeremy_Lv added a comment -

        If I just execute the appRegistry.remove(appName); to remove the appname, another exception about the context root will be thrown out:

        remote failure: Error occurred during deployment: Exception while loading the ap
        p : java.lang.Exception: Virtual server server already has a web module test_sam
        ple5 loaded at /test_sample5 therefore web module test_sample5 cannot be loaded
        at this context path on this virtual server. Please see server.log for more deta
        ils.
        

        So I think we should not only remove the application registered in domain.xml but also execute the ApplicationLifecycle.undeploy in this situation.

        Show
        Jeremy_Lv added a comment - If I just execute the appRegistry.remove(appName); to remove the appname, another exception about the context root will be thrown out: remote failure: Error occurred during deployment: Exception while loading the ap p : java.lang.Exception: Virtual server server already has a web module test_sam ple5 loaded at /test_sample5 therefore web module test_sample5 cannot be loaded at this context path on this virtual server. Please see server.log for more deta ils. So I think we should not only remove the application registered in domain.xml but also execute the ApplicationLifecycle.undeploy in this situation.

          People

          • Assignee:
            Jeremy_Lv
            Reporter:
            sonky2
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: