glassfish
  1. glassfish
  2. GLASSFISH-13213

failed commands should not be listed as pending changes.

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1
    • Fix Version/s: future release
    • Component/s: admin
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Sun

    • Issuezilla Id:
      13,213

      Description

      Build 18 08/31

      I've generated two failed deployments: first deployment failed because of JNDI
      name conflict. In second case a directory deployment failed for second instance
      because this directory was presented on the remote machine. So in both cases
      either _deploy or _instanceValidateRemoteDirDeployment commands failed. But then
      these commands were listed between pending changes. I don't think that the
      failed commands have to be listed as pending changes.
      ==========================================================
      asadmin deploy --target c2 --name stateless-simple:1
      archives_nodb/stateless-simple.ear
      Application deployed successfully with name stateless-simple:1.
      WARNING : Command _deploy did not complete successfully on server instance in3 :
      remote failure: Failed to load the application on instance in3. The application
      will not run properly. Please fix your application and redeploy.
      Exception while loading the app : java.lang.RuntimeException: EJB Container
      initialization error. Please see server.log for more details.
      EJB Container initialization errorException while invoking class
      org.glassfish.ejb.startup.EjbDeployer load method : java.lang.RuntimeException:
      EJB Container initialization error
      EJB Container initialization error

      WARNING : Command _deploy did not complete successfully on server instance in4 :
      remote failure: Failed to load the application on instance in4. The application
      will not run properly. Please fix your application and redeploy.
      Exception while loading the app : java.lang.RuntimeException: EJB Container
      initialization error. Please see server.log for more details.
      EJB Container initialization errorException while invoking class
      org.glassfish.ejb.startup.EjbDeployer load method : java.lang.RuntimeException:
      EJB Container initialization error
      EJB Container initialization error

      Command deploy executed successfully.

      asadmin deploy --target c1 --name webapp:1 webapps-caching
      remote failure: A supplemental command failed; cannot proceed further
      Command _instanceValidateRemoteDirDeployment failed on server instance in2 :
      java.lang.IndexOutOfBoundsException: Index: 0, Size: 0

      Command deploy failed.
      asadmin list-instances
      in1 running
      in2 running; requires restart [pending config changes are :
      _instanceValidateRemoteDirDeployment
      /opt/appserver-sqe/pe/deployment_v3/webapps-caching/; ]
      in3 running; requires restart [pending config changes are : _deploy
      /opt/glassfishv3/glassfish/domains/domain1/applications/__internal/stateless-simple~1/stateless-simple.ear;
      ]
      in4 running; requires restart [pending config changes are : _deploy
      /opt/glassfishv3/glassfish/domains/domain1/applications/__internal/stateless-simple~1/stateless-simple.ear;
      ]
      a1 running
      a2 running

      Command list-instances executed successfully.

        Activity

        easarina created issue -
        Hide
        vijaysr added a comment -

        "I don't think that the failed commands have to be listed as pending changes." - No, that is the real
        intention.

        Deployment (which changes the config of the intended target and hence is a config change) is
        attempted on an instance. Deployment fails. So that instance is flagged as pending config change - this
        is what the restart-required feature with additional info is meant for.

        In your scenario, deployment of stateless-simple.ear failed on instances in3, in4 of cluster c2.
        Deployment of webapps-caching failed on instance in2 of cluster c2. When you do list-instances, this is
        what is exactly displayed and this is the intention.

        The whole intention of listing pending config changes is to let the admin know which commands failed
        so that the admin can decide when to restart the instance.

        As I said, I need to understand what the real issue here is.

        Show
        vijaysr added a comment - "I don't think that the failed commands have to be listed as pending changes." - No, that is the real intention. Deployment (which changes the config of the intended target and hence is a config change) is attempted on an instance. Deployment fails. So that instance is flagged as pending config change - this is what the restart-required feature with additional info is meant for. In your scenario, deployment of stateless-simple.ear failed on instances in3, in4 of cluster c2. Deployment of webapps-caching failed on instance in2 of cluster c2. When you do list-instances, this is what is exactly displayed and this is the intention. The whole intention of listing pending config changes is to let the admin know which commands failed so that the admin can decide when to restart the instance. As I said, I need to understand what the real issue here is.
        Hide
        easarina added a comment -

        The failed comands did not create any changes. So the result of their execution
        can not be "pending changes".

        Show
        easarina added a comment - The failed comands did not create any changes. So the result of their execution can not be "pending changes".
        Hide
        vijaysr added a comment -

        I am trying to understand which failed command did not make any change ? The second deployment ?

        Show
        vijaysr added a comment - I am trying to understand which failed command did not make any change ? The second deployment ?
        Hide
        easarina added a comment -

        In both cases no changes were made. In first case the deployment totally
        failed. In second case the directory deployment did not happen for second
        instance, because the directory was not presented on that machine. So again,
        no changes.

        Show
        easarina added a comment - In both cases no changes were made. In first case the deployment totally failed. In second case the directory deployment did not happen for second instance, because the directory was not presented on that machine. So again, no changes.
        Hide
        vijaysr added a comment -

        Changing state as per bug scrubbing process
        (http://wikis.sun.com/display/GlassFish/Bug+Scrubbing+Process)

        Show
        vijaysr added a comment - Changing state as per bug scrubbing process ( http://wikis.sun.com/display/GlassFish/Bug+Scrubbing+Process )
        Hide
        vijaysr added a comment -

        I tried some different ways of solving this issue but none of them is generic enough to enable all
        commands behave the same way.

        As of now, any failure in command replication, forces the instance state to be changed along with the
        "pending config changes are ..." message. This happens even with commands that do only read
        operation like get commands. This is as per the smaller scope impl of instance state :
        http://wikis.sun.com/display/GlassFish/Phase+1

        Ideal solution will be for the framework to give a way for the command impl to specify that the
        command is doing a read only operation (through some annotation like @ReadOnly). We can also
        achieve this with some enhancement to the the AdminLock facility that was introduced towards end of
        MS5.

        Implementing a complete solution at this stage requires introduction of new annotation, change to all
        commands to use this new annotation etc. So I am changing this as a feature request for 3.2.

        For this release, any failure during command replication will result in the behavior mentioned in this
        bug since what has been implemented is http://wikis.sun.com/display/GlassFish/Phase+1

        Show
        vijaysr added a comment - I tried some different ways of solving this issue but none of them is generic enough to enable all commands behave the same way. As of now, any failure in command replication, forces the instance state to be changed along with the "pending config changes are ..." message. This happens even with commands that do only read operation like get commands. This is as per the smaller scope impl of instance state : http://wikis.sun.com/display/GlassFish/Phase+1 Ideal solution will be for the framework to give a way for the command impl to specify that the command is doing a read only operation (through some annotation like @ReadOnly). We can also achieve this with some enhancement to the the AdminLock facility that was introduced towards end of MS5. Implementing a complete solution at this stage requires introduction of new annotation, change to all commands to use this new annotation etc. So I am changing this as a feature request for 3.2. For this release, any failure during command replication will result in the behavior mentioned in this bug since what has been implemented is http://wikis.sun.com/display/GlassFish/Phase+1
        Hide
        vijaysr added a comment -

        Transferring requested / planned enhancements for 3.2 to Tom to be reassigned to appropriate engineers
        later

        Show
        vijaysr added a comment - Transferring requested / planned enhancements for 3.2 to Tom to be reassigned to appropriate engineers later
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 13213 44817
        Hide
        Tom Mueller added a comment -

        A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.

        Show
        Tom Mueller added a comment - A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.
        Tom Mueller made changes -
        Fix Version/s future release [ 11148 ]
        Fix Version/s 3.2 [ 10969 ]
        Tom Mueller made changes -
        Assignee Tom Mueller [ tmueller ] kumara [ kumara ]

          People

          • Assignee:
            kumara
            Reporter:
            easarina
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: