glassfish
  1. glassfish
  2. GLASSFISH-18858

After the execution of versioning timer apps deployment, next timer apps deployment - failed.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_b43
    • Fix Version/s: 4.0_b50_ms4
    • Component/s: ejb_container
    • Labels:
      None

      Description

      Promoted 4.0 build 43. OEL6 or Solaris Sparc 10.

      Created a cluster with two instances.

      The deployment of all timer apps to the cluster failed.

      It happened if before were executed the follow timer app deployment commands:
      asadmin deploy --target domain --name=timersession:1.0 --retrieve /opt/appserver-sqe/pe/deploymen
      t_v3 /opt/appserver-sqe/pe/deployment_v3/archives_nodb/timersession.ear

      asadmin deploy --target my-c1 --name=timersession:1.0 --retrieve /opt/appserver-sqe/pe/deployment
      _v3 /opt/appserver-sqe/pe/deployment_v3/archives_nodb/timersession.ear

      (The second deployment created syntax warning, see bug: 18857)

      Then the apps were undeployed; cluster and instances were removed, recreated and started; DB restarted; domain restarted; all required resources recreated.

      After that was executed the follow depoyment command:

      asadmin deploy --target my-c1 /opt/appserver-sqe/pe/deployment_v3/archives_nodb/timersession.ear

      This deployment and the deployment of all other timer apps - failed. I've attached the correspondent error messages from server.log.

      If these two first versioning timer app deployment would not be executed, then the next timer apps deployment would not fail.

      This is a regression issue, for example, this issue was not seen for b35.

      1. domain.xml
        57 kB
        aelena
      2. setup_cl.pl
        1 kB
        aelena
      3. timer.log
        43 kB
        aelena
      4. workaround.sh
        0.4 kB
        aelena

        Activity

        Hide
        aelena added a comment -

        The problem happened when first was executed the deployment of the timer app to the domain. Then the deployment of any timer app, for example to the cluster, failed. It doesn't matter, whether the domain deployment of the timer app, used versioning or not.

        Also, after the domain deployment happened, then any timer deployment failed, independently whether the domain/cluster/db were restarted or not.

        Show
        aelena added a comment - The problem happened when first was executed the deployment of the timer app to the domain. Then the deployment of any timer app, for example to the cluster, failed. It doesn't matter, whether the domain deployment of the timer app, used versioning or not. Also, after the domain deployment happened, then any timer deployment failed, independently whether the domain/cluster/db were restarted or not.
        Hide
        marina vatkina added a comment -

        I'm surprised it ever worked. We do not support more than one configuration for the EJB TS on a domain, but domain undeploy tries to remove the timers, and not knowing that they never ran, or if the app was ever enabled in any instance, looks for the TS config on the domain, which points to the embedded pool. The next (real) deploy hits an existing TS and doesn't create the table in the cluster-specific resource.

        Show
        marina vatkina added a comment - I'm surprised it ever worked. We do not support more than one configuration for the EJB TS on a domain, but domain undeploy tries to remove the timers, and not knowing that they never ran, or if the app was ever enabled in any instance, looks for the TS config on the domain, which points to the embedded pool. The next (real) deploy hits an existing TS and doesn't create the table in the cluster-specific resource.
        Hide
        aelena added a comment -

        This a regression issue. Everything worked fine for GF 3.1.2 and it worked fine, for example, for GF 4.0 b35.

        Show
        aelena added a comment - This a regression issue. Everything worked fine for GF 3.1.2 and it worked fine, for example, for GF 4.0 b35.
        Hide
        marina vatkina added a comment -

        It was a false positive. The behavior was actually wrong. But I can restore it, and then create a feature request to do it right.

        Show
        marina vatkina added a comment - It was a false positive. The behavior was actually wrong. But I can restore it, and then create a feature request to do it right.
        Hide
        marina vatkina added a comment -

        Fixed with rev 55512 by keeping resource name null for target 'domain'. Timers can't be removed when undeploy target is 'domain' (may be we should document it).

        Show
        marina vatkina added a comment - Fixed with rev 55512 by keeping resource name null for target 'domain'. Timers can't be removed when undeploy target is 'domain' (may be we should document it).

          People

          • Assignee:
            marina vatkina
            Reporter:
            aelena
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: