glassfish
  1. glassfish
  2. GLASSFISH-16931

404 error accessing application after redeploy on instance other than DAS

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1_b10
    • Fix Version/s: 3.1.1_b10, 4.0
    • Component/s: deployment
    • Labels:
      None
    • Environment:

      FF5, Windows XP, ogs-3.1.1-b10-06_28_2011.zip

      Description

      After I redeploy application on mixed instances (DAS and non DAS), I cannot access it any longer on non DAS instance. Steps to reproduce:

      1. Create a standalone instance and start it.
      2. Deploy an application to instance and DAS, e.g. hello.war.
      3. Launch the application on both instances - it's displayed fine.
      4. Go to Applications screen and click on Redeploy link for the hello.war application.
      5. On the next, Deployment screen select the same application and click Deploy.
      6. Access application again - it's displayed fine on DAS but no on the standalone instance. 404 error is displayed instead.

      Nothing is written to the standalone instance's server.log during redeployment. DAS server.log contains the following record at the end:

      [#|2011-06-30T15:39:25.203-0700|SEVERE|oracle-glassfish3.1|javax.enterprise.syst
      em.tools.admin.org.glassfish.deployment.admin|_ThreadID=85;_ThreadName=Thread-2;

      The log message is null. #]

      The workaround is to remove standalone instance target and add it again to the application. After that the application can be accessed again.

        Activity

        Hide
        Anissa Lam added a comment -

        When re-deploy an application, we basically do the same thing as "deploy" but set the force option to "true".
        And Hong has told me that setting target to domain will take care of all the targets. Thats true before we stop using DeploymentFacility.
        Maybe redeploy to "domain" only will be fine if going through DF, but not otherwise ?
        I forgot if i have confirmed with Hong if using the deploy command instead of using DF will behave the same, it never occurs to me that it will not.

        I am transferring this to Tim for evaluation.
        If i cannot deploy to "domain" during redeployment, please let me know whats the step i should do.
        Do i need to call deploy for each target specifying force to true ? but i will guess deploy will fail.
        Or should i remove the resource-ref for that target and then add it back ? Doesn't sound efficient this way.

        While debugging this, i see a bug when building the Properties during redeployment. I will fix that.

        Show
        Anissa Lam added a comment - When re-deploy an application, we basically do the same thing as "deploy" but set the force option to "true". And Hong has told me that setting target to domain will take care of all the targets. Thats true before we stop using DeploymentFacility. Maybe redeploy to "domain" only will be fine if going through DF, but not otherwise ? I forgot if i have confirmed with Hong if using the deploy command instead of using DF will behave the same, it never occurs to me that it will not. I am transferring this to Tim for evaluation. If i cannot deploy to "domain" during redeployment, please let me know whats the step i should do. Do i need to call deploy for each target specifying force to true ? but i will guess deploy will fail. Or should i remove the resource-ref for that target and then add it back ? Doesn't sound efficient this way. While debugging this, i see a bug when building the Properties during redeployment. I will fix that.
        Hide
        Tim Quinn added a comment -

        I believe I found exactly this same issue earlier this week.

        I checked in changes for this problem earlier today (commit log below). (both 3.1.1 and the trunk)

        If the same cause triggered your error and the one I found, then the fix should be in the June 30 nightly builds.

        I am marking this as fixed. Please retest using tonight's nightly - from looking at the list of nightlies I expect it will be timestamped July 1 - and re-open this issue if you still see the problem.

        3.1.1 commit: 47781
        trunk commit: 47782

        Project: glassfish
        Repository: svn
        Revision: 47781
        Author: tjquinn
        Date: 2011-06-30 12:37:44 UTC
        Link:

        Log Message:
        ------------
        Incremental fix for 16747

        The earlier fix for this performance problem clears the transient app metadata at the end of deployment to release some large data structures.

        But redeployment used transient app metadata to let the post deployment command know what targets the app was originally deployed, so the performance fix caused this information to be lost.

        These changes store the previous targets in the DeployCommandSupplementalInfo, a separate data structure which conveys some information from the deployment command logic to the PostDeployCommand. This way, when the transient app metadata is cleared, the post-command still has access to the targets to which the app had been previously deployed.

        16747 approved: Sathyan
        Tests: QL, deployment cluster devtests

        Revisions:
        ----------
        47781

        Modified Paths:
        ---------------
        branches/3.1.1/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommandSupplementalInfo.java
        branches/3.1.1/deployment/admin/src/main/java/org/glassfish/deployment/admin/PostDeployCommand.java

        Show
        Tim Quinn added a comment - I believe I found exactly this same issue earlier this week. I checked in changes for this problem earlier today (commit log below). (both 3.1.1 and the trunk) If the same cause triggered your error and the one I found, then the fix should be in the June 30 nightly builds. I am marking this as fixed. Please retest using tonight's nightly - from looking at the list of nightlies I expect it will be timestamped July 1 - and re-open this issue if you still see the problem. 3.1.1 commit: 47781 trunk commit: 47782 Project: glassfish Repository: svn Revision: 47781 Author: tjquinn Date: 2011-06-30 12:37:44 UTC Link: Log Message: ------------ Incremental fix for 16747 The earlier fix for this performance problem clears the transient app metadata at the end of deployment to release some large data structures. But redeployment used transient app metadata to let the post deployment command know what targets the app was originally deployed, so the performance fix caused this information to be lost. These changes store the previous targets in the DeployCommandSupplementalInfo, a separate data structure which conveys some information from the deployment command logic to the PostDeployCommand. This way, when the transient app metadata is cleared, the post-command still has access to the targets to which the app had been previously deployed. 16747 approved: Sathyan Tests: QL, deployment cluster devtests Revisions: ---------- 47781 Modified Paths: --------------- branches/3.1.1/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommandSupplementalInfo.java branches/3.1.1/deployment/admin/src/main/java/org/glassfish/deployment/admin/PostDeployCommand.java
        Hide
        lidiam added a comment -

        Verified in build ogs-3.1.1-b11-07_04_2011-aix.zip.

        Show
        lidiam added a comment - Verified in build ogs-3.1.1-b11-07_04_2011-aix.zip.

          People

          • Assignee:
            Tim Quinn
            Reporter:
            lidiam
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: