glassfish
  1. glassfish
  2. GLASSFISH-16262

deleting instance leaves lifecycle module around that cannot be deleted

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1.1_b01
    • Component/s: deployment
    • Labels:
      None

      Description

      Consider the following sequence of commands:

      asadmin start-domain
      asadmin create-local-instance i1
      asadmin create-lifecycle-module --target i1 --classname foo.Bar --failurefatal=true abc
      asadmin delete-local-instance i1

      asadmin create-lifecycle-module --classname foo.Bar --failurefatal=true abc
      remote failure: Lifecycle module with name [abc] already exists
      Command create-lifecycle-module failed.

      asadmin delete-lifecycle-module abc
      remote failure: Lifecycle module abc is not deployed on this target [server]
      Command delete-lifecycle-module failed.

      When the instance was deleted, the reference to the "abc" lifecycle module was deleted, but the <application> element for that lifecycle module is still in the domain.xml. This is why the attempt to create it on the DAS fails. The delete fails because it isn't deployed on the DAS, but the problem at this point is that it isn't deployed anywhere because the instance has been deleted.

      So we are left in the state where we have this "abc" lifecycle module hanging around in the domain.xml, but we can't get rid of it.

      To workaround this problem, one can do this:

      asadmin create-application-ref abc
      asadmin delete-lifecycle-module abc

      Not exactly an obvious workaround, especially since list-applications doesn't list lifecycle modules.

      Either the system should make sure that when the last instance that references a lifecycle module is deleted, then the lifecycle module is deleted too automatically, or, the delete-lifecycle-module command should allow for deleting a lifecycle module that isn't referenced by any target.

        Activity

        Hide
        Hong Zhang added a comment -

        Tom, this seems pretty similar to issue http://java.net/jira/browse/GLASSFISH-13979 where a regular application was left deployed in the domain after the instance was deleted and a subsequent deployment was attempted.

        I fixed that issue to have similar behavior as v2, where the failure message will tell user that the application was already deployed to domain and a create-application-ref command should be used to deploy to subsequent targets. This is consistent with how we handled the scenario where the application was deployed to a target ABC, and then need to be deployed to subsequent target XYZ (you cannot use deploy command here and have to use create-application-ref), only the target ABC here is the special target "domain".

        I plan to fix this issue the similar way. The error message for regular application is like this:
        Application foo is already deployed in this domain. Please use create-application-ref command to create application reference on target XYZ.

        The error message I plan to have for lifecycle module case will be something like this:
        Lifecycle module foo is already created in this domain. Please use create-application-ref command to create application reference on target XYZ.

        BTW: The list-lifecycle-modules command takes special target "domain" which shows all the created lifecycle modules in this domain. So the module should be in the list when you do "asadmin list-lifecycle-modules domain"
        after the instance is deleted.

        Show
        Hong Zhang added a comment - Tom, this seems pretty similar to issue http://java.net/jira/browse/GLASSFISH-13979 where a regular application was left deployed in the domain after the instance was deleted and a subsequent deployment was attempted. I fixed that issue to have similar behavior as v2, where the failure message will tell user that the application was already deployed to domain and a create-application-ref command should be used to deploy to subsequent targets. This is consistent with how we handled the scenario where the application was deployed to a target ABC, and then need to be deployed to subsequent target XYZ (you cannot use deploy command here and have to use create-application-ref), only the target ABC here is the special target "domain". I plan to fix this issue the similar way. The error message for regular application is like this: Application foo is already deployed in this domain. Please use create-application-ref command to create application reference on target XYZ. The error message I plan to have for lifecycle module case will be something like this: Lifecycle module foo is already created in this domain. Please use create-application-ref command to create application reference on target XYZ. BTW: The list-lifecycle-modules command takes special target "domain" which shows all the created lifecycle modules in this domain. So the module should be in the list when you do "asadmin list-lifecycle-modules domain" after the instance is deleted.
        Hide
        Tom Mueller added a comment -

        Should there be a "create-lifecycle-module-ref" command? Is it commonly understand that a lifecycle module is actually an application?

        Thank you for the tip about using "domain" as the target for list-lifecycle-modules.

        It turns out that this also works for delete-lifecycle-module, i.e., if there is an unreferenced lifecycle-module, it can be deleted with:

        asadmin delete-lifecycle-module --target domain abc

        So the bug as reported doesn't actually exist.

        Show
        Tom Mueller added a comment - Should there be a "create-lifecycle-module-ref" command? Is it commonly understand that a lifecycle module is actually an application? Thank you for the tip about using "domain" as the target for list-lifecycle-modules. It turns out that this also works for delete-lifecycle-module, i.e., if there is an unreferenced lifecycle-module, it can be deleted with: asadmin delete-lifecycle-module --target domain abc So the bug as reported doesn't actually exist.
        Hide
        Hong Zhang added a comment -

        It's probably more consistent to have a create-lifecycle-module-ref command as we have a separate create-lifecycle-module command, but as this is the syntax since 8.* and lifecycle module is kind of deprecating, I am relucant to add a new command for this now.

        Right, the domain is a supported target for delete-lifecycle-module as well so we can delete the lifecycle module in this case. I will still enhance the error message for the create-lifecycle-module so user has some clue what they need to do to have this module created on the specified target.

        Show
        Hong Zhang added a comment - It's probably more consistent to have a create-lifecycle-module-ref command as we have a separate create-lifecycle-module command, but as this is the syntax since 8.* and lifecycle module is kind of deprecating, I am relucant to add a new command for this now. Right, the domain is a supported target for delete-lifecycle-module as well so we can delete the lifecycle module in this case. I will still enhance the error message for the create-lifecycle-module so user has some clue what they need to do to have this module created on the specified target.
        Hide
        Hong Zhang added a comment -

        enhanced the error message in this case to give user more clue how to proceed

        Show
        Hong Zhang added a comment - enhanced the error message in this case to give user more clue how to proceed

          People

          • Assignee:
            Hong Zhang
            Reporter:
            Tom Mueller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: