glassfish
  1. glassfish
  2. GLASSFISH-9665

improve error handling for application which fails upgrade

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: V3
    • Fix Version/s: V3
    • Component/s: upgrade_tool
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Sun

    • Issuezilla Id:
      9,665

      Description

      After upgrade to v3, could not get client stubs to run application.

      Os= linux5.0
      upgradetype = sidebyside
      mode=cli

      Steps to reproduce:

      1) install 9.1_01 from /net/koori/onestop/glassfish/9.1_01/promoted/fcs/b09d/bundles
      2) check out quicklooks test using instruction at
      http://glassfish.dev.java.net/public/GuidelinesandConventions.html#Quicklook_Tests
      3)cd workspace/v2/glassfish/appserv-tests/sqetests/ejb/stateless/converter
      4) edit build.xml to skip undeploy and unsetup
      5) start-domain, start derby
      6) execute ant all
      7) stop domain, stop derby
      8) install latest-glassfish.zip dated 9/22/09 nightly build
      9) get client stubs

      Output from console:
      /usr/nga/v3/retest/glassfishv3/glassfish/bin/asadmin get-client-stubs --user
      admin --appname ejb-stateless-converterApp .
      Deprecated syntax, instead use:
      asadmin --user admin get-client-stubs [options] ...
      com.sun.enterprise.admin.cli.CommandException: remote failure: Error while
      downloading generated files
      /usr/nga/v3/retest/glassfishv3/glassfish/domains/domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar/ejb-stateless-converter-clientClient.jar
      (No such file or directory)

      Command get-client-stubs failed.

      Error in server.log:
      [#|2009-09-22T09:18:08.542-0700|SEVERE|glassfish|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=31;_ThreadName=Thread-3;|Error
      while downloading generated files
      java.io.FileNotFoundException:
      /usr/nga/v3/retest/glassfishv3/glassfish/domains/domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar/ejb-stateless-converter-clientClient.jar
      (No such file or directory)
      at java.io.FileInputStream.open(Native Method)
      at java.io.FileInputStream.<init>(FileInputStream.java:106)
      at
      org.glassfish.admin.payload.PayloadImpl$Outbound.attachFile(PayloadImpl.java:117)
      at
      org.glassfish.deployment.admin.DeployCommand.retrieveArtifacts(DeployCommand.java:431)
      at
      org.glassfish.deployment.admin.DeployCommand.retrieveArtifacts(DeployCommand.java:414)
      at
      org.glassfish.appclient.server.core.GetClientStubsCommand.execute(GetClientStubsCommand.java:106)
      at
      com.sun.enterprise.v3.admin.CommandRunnerImpl$4.execute(CommandRunnerImpl.java:403)
      at
      com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:418)
      at
      com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:505)
      at
      com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:138)
      at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:355)
      at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:195)
      at
      com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
      at
      com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
      @ at
      com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:215)
      at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:753)
      at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:661)
      at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:914)
      at
      com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
      at
      com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
      at
      com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
      at
      com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
      at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
      at
      com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
      at
      com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
      at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
      at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
      at
      com.sun.grizzly.util.FixedThreadPool$BasicWorker.dowork(FixedThreadPool.java:379)
      at
      com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:360)
      at java.lang.Thread.run(Thread.java:619)

      #]
      1. domains.jar
        3.19 MB
        1xpert
      2. ejb-stateless-converterApp.ear
        33 kB
        1xpert
      3. server.log
        60 kB
        Hong Zhang
      4. server.log
        518 kB
        1xpert

        Activity

        Hide
        marina vatkina added a comment -

        Tim,

        The error says that a) "Error while downloading generated files" and b) that
        there is no ejb-stateless-converter-clientClient.jar (and on the latest build
        there is no stack trace printed on the asadmin client).

        So the problem is not in the stubs (i.e. the error text is misleading), but
        that there is no generated directory after the upgrade for a failed redeploy.

        On the other note: there are no generated stubs in the v2 deploy, so I'm not
        sure if anything would've been download in the 1st place...

        Reassigning back to you to check for the generated dir and to improve the error
        message. To reproduce the problem I commented out the body of the postConstruct
        method in EJBTimerServiceUpgrade.

        Show
        marina vatkina added a comment - Tim, The error says that a) "Error while downloading generated files" and b) that there is no ejb-stateless-converter-clientClient.jar (and on the latest build there is no stack trace printed on the asadmin client). So the problem is not in the stubs (i.e. the error text is misleading), but that there is no generated directory after the upgrade for a failed redeploy. On the other note: there are no generated stubs in the v2 deploy, so I'm not sure if anything would've been download in the 1st place... Reassigning back to you to check for the generated dir and to improve the error message. To reproduce the problem I commented out the body of the postConstruct method in EJBTimerServiceUpgrade.
        Hide
        Tim Quinn added a comment -

        Sorry to be dense, but what error text do you think is misleading, Marina? The
        admin CLI says that the get-client-stubs command failed, which is true. The
        displayed message says that the server could not download a file it tried to
        download, which is true.

        As for the app generating stubs (or not) in v2 and v3... You are
        (understandably) confusing downloaded client files with stubs. Stub classes can
        appear inside one of the generated downloaded files, but the downloaded files
        will exist (in a successful deployment at least) regardless of whether stubs
        were generated or not during the deployment.

        What has happened, somehow, is (1) the app client deployer registered the app's
        expected files for download, and (2) those files are not there when
        get-client-stubs asks for them. I do not understand how this would happen,
        especially in the absence of any errors in the server.log at the time of the app
        client deployer work.

        Bobby and Hong, during the upgrade if the redeploy fails does the upgrade tool
        or the attempted redeployment operation itself delete any files that might have
        been generated so far? If so, how does it do that? The AppClientDeployer's
        clean method which is invoked during an undeployment unregisters the
        downloadable artifacts for the client. If the upgrade path in case of an error
        were to undeploy the app then the get-client-stubs command should not even find
        entries for those files when it runs.

        So I guess the app is not undeployed, because GetClientStubsCommand checks to
        make sure the app is in the configuration before proceeding, and it must be
        there because the logic continues on after its check to try to download the
        files. But the files are not there, so that's why I wonder if the follow-up
        after the failed redeployment includes cleaning out the generated directory for
        the app.

        Show
        Tim Quinn added a comment - Sorry to be dense, but what error text do you think is misleading, Marina? The admin CLI says that the get-client-stubs command failed, which is true. The displayed message says that the server could not download a file it tried to download, which is true. As for the app generating stubs (or not) in v2 and v3... You are (understandably) confusing downloaded client files with stubs. Stub classes can appear inside one of the generated downloaded files, but the downloaded files will exist (in a successful deployment at least) regardless of whether stubs were generated or not during the deployment. What has happened, somehow, is (1) the app client deployer registered the app's expected files for download, and (2) those files are not there when get-client-stubs asks for them. I do not understand how this would happen, especially in the absence of any errors in the server.log at the time of the app client deployer work. Bobby and Hong, during the upgrade if the redeploy fails does the upgrade tool or the attempted redeployment operation itself delete any files that might have been generated so far? If so, how does it do that? The AppClientDeployer's clean method which is invoked during an undeployment unregisters the downloadable artifacts for the client. If the upgrade path in case of an error were to undeploy the app then the get-client-stubs command should not even find entries for those files when it runs. So I guess the app is not undeployed, because GetClientStubsCommand checks to make sure the app is in the configuration before proceeding, and it must be there because the logic continues on after its check to try to download the files. But the files are not there, so that's why I wonder if the follow-up after the failed redeployment includes cleaning out the generated directory for the app.
        Hide
        marina vatkina added a comment -

        Yes, I was confused, thinking that RMI stubs are being registered without being
        created.

        But this is what happens in my test (and somebody needs to explain this behavior):
        1.run with -upgrade true - this exits at the end
        2. % find glassfishv3/glassfish/domains/v2domain1/generated | grep
        ejb-stateless-converterApp
        glassfishv3/glassfish/domains/v2domain1/generated/jsp/ejb-stateless-converterApp
        glassfishv3/glassfish/domains/v2domain1/generated/jsp/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
        glassfishv3/glassfish/domains/v2domain1/generated/jsp/ejb-stateless-converterApp/ejb-stateless-converter-client_jar
        glassfishv3/glassfish/domains/v2domain1/generated/ejb/ejb-stateless-converterApp
        glassfishv3/glassfish/domains/v2domain1/generated/ejb/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
        glassfishv3/glassfish/domains/v2domain1/generated/ejb/ejb-stateless-converterApp/ejb-stateless-converter-client_jar
        glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp
        glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
        glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar
        glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar/ejb-stateless-converter-clientClient.jar
        glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converterAppClient.jar
        glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp
        glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
        glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar/granted.policy

        3. run with the new domain (this fails to start the timer service)
        4. % find glassfishv3/glassfish/domains/v2domain1/generated | grep
        ejb-stateless-converterApp
        glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp
        glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar
        glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar/granted.policy

        Show
        marina vatkina added a comment - Yes, I was confused, thinking that RMI stubs are being registered without being created. But this is what happens in my test (and somebody needs to explain this behavior): 1.run with -upgrade true - this exits at the end 2. % find glassfishv3/glassfish/domains/v2domain1/generated | grep ejb-stateless-converterApp glassfishv3/glassfish/domains/v2domain1/generated/jsp/ejb-stateless-converterApp glassfishv3/glassfish/domains/v2domain1/generated/jsp/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar glassfishv3/glassfish/domains/v2domain1/generated/jsp/ejb-stateless-converterApp/ejb-stateless-converter-client_jar glassfishv3/glassfish/domains/v2domain1/generated/ejb/ejb-stateless-converterApp glassfishv3/glassfish/domains/v2domain1/generated/ejb/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar glassfishv3/glassfish/domains/v2domain1/generated/ejb/ejb-stateless-converterApp/ejb-stateless-converter-client_jar glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converter-client_jar/ejb-stateless-converter-clientClient.jar glassfishv3/glassfish/domains/v2domain1/generated/xml/ejb-stateless-converterApp/ejb-stateless-converterAppClient.jar glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar/granted.policy 3. run with the new domain (this fails to start the timer service) 4. % find glassfishv3/glassfish/domains/v2domain1/generated | grep ejb-stateless-converterApp glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar glassfishv3/glassfish/domains/v2domain1/generated/policy/ejb-stateless-converterApp/ejb-stateless-converter-ejb_jar/granted.policy
        Hide
        Hong Zhang added a comment -

        tim: for a failed (re)deployment during upgrade, we handle like what we handled
        with any failed deployment in normal path. We tried to roll back as much as we
        can (cleaning up the registry, deleting the files etc). It's possible that the
        policy files were left behind as the security code does their own clean up in
        failed situation. But I don't understand why the file contents are different
        right after upgrade versus after starting the new domain.

        Show
        Hong Zhang added a comment - tim: for a failed (re)deployment during upgrade, we handle like what we handled with any failed deployment in normal path. We tried to roll back as much as we can (cleaning up the registry, deleting the files etc). It's possible that the policy files were left behind as the security code does their own clean up in failed situation. But I don't understand why the file contents are different right after upgrade versus after starting the new domain.
        Hide
        Tim Quinn added a comment -

        I went through exactly the steps outlined in the original post, with the
        exception that I downloaded the Oct. 31 nightly build of b71.

        The files in the generated directory were as expected.

        Everything worked as expected, including the get-client-stubs. I could even
        launch the client successfully after the download.

        So I'm closing this, because it seems to be working with the latest changes in v3.

        Show
        Tim Quinn added a comment - I went through exactly the steps outlined in the original post, with the exception that I downloaded the Oct. 31 nightly build of b71. The files in the generated directory were as expected. Everything worked as expected, including the get-client-stubs. I could even launch the client successfully after the download. So I'm closing this, because it seems to be working with the latest changes in v3.

          People

          • Assignee:
            Tim Quinn
            Reporter:
            1xpert
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: