Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-9671

Weblogic: Platform startup fails if history cleanup job cannot be re-configured

    Details

      Description

      Situation:

      • On engine startup, the history cleanup job is re-configured according to updated cleanup settings
      • This may fail with an optimistic locking exception if the job is currently executed or if another engine does the same in a cluster
      • With CAM-8866 we fixed that this exception is not propagated but only logged

      Current behavior:

      • On weblogic, the cleanup re-configuration failure is logged; however, the cleanup job is re-configured in the context of a container-managed transaction, which is then set to rollback-only
      • Subsequently, when the transaction is supposed to be committed, it fails
      • Apparently, the process engine is then not available in the container and subsequent process application deployments fail as well

      Expected behavior:

      • The re-configuration failure is logged, but other than that platform startup should not be affected

      Details:

      • see log files for exceptions
      • I reproduced this by remotely debugging an integration test and artificially creating an instance of OptimisticLockingException in CommandContext#close. This exception is then rethrown which creates the same situation as if there was an actual optimistic locking problem.
      • You can configure Weblogic for remote debugging by adding the entry <property name="jvmOptions">-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y</property> to arquillian.xml
      • I did not yet understand why the failure of the managed transaction also results in the process engine not being available in the container
      • I was a bit surprised to see a managed transaction here, since EjbBpmPlatformBootstrap is annotated with @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED), but I guess that I just don't have that level of Java-EE-fu

        Issue Links

          Activity

          thorben.lindhauer Thorben Lindhauer created issue -
          thorben.lindhauer Thorben Lindhauer made changes -
          Field Original Value New Value
          Description Situation:

          * On engine startup, the history cleanup job is re-configured according to updated cleanup settings
          * This may fail with an optimistic locking exception if the job is currently executed or if another engine does the same in a cluster
          * With CAM-8866 we fixed that this exception is not propagated but only logged

          Current behavior:

          * On weblogic, the cleanup re-configuration failure is logged; however, the cleanup job is re-configured in the context of a container-managed transaction, which is then set to rollback-only
          * Subsequently, when the transaction is supposed to be committed, it fails
          * Apparently, the process engine is then not available in the container and subsequent process application deployments fail as well

          Expected behavior:

          * The re-configuration failure is logged, but other than that platform startup should not be affected

          Details:

          * see log files for exceptions
          * I reproduced this by remotely debugging an integration test and artificially creating an instance of {{OptimisticLockingException}} in {{CommandContext#close}}. This exception is then rethrown which creates the same situation as if there was an actual optimistic locking problem.
          * You can configure Weblogic for remote debugging by adding the entry {{<property name="jvmOptions">-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y</property>}} to {{arquillian.xml}}
          * I did not yet understand why the failure of the managed transaction also results in the process engine not being available in the container
          Situation:

          * On engine startup, the history cleanup job is re-configured according to updated cleanup settings
          * This may fail with an optimistic locking exception if the job is currently executed or if another engine does the same in a cluster
          * With CAM-8866 we fixed that this exception is not propagated but only logged

          Current behavior:

          * On weblogic, the cleanup re-configuration failure is logged; however, the cleanup job is re-configured in the context of a container-managed transaction, which is then set to rollback-only
          * Subsequently, when the transaction is supposed to be committed, it fails
          * Apparently, the process engine is then not available in the container and subsequent process application deployments fail as well

          Expected behavior:

          * The re-configuration failure is logged, but other than that platform startup should not be affected

          Details:

          * see log files for exceptions
          * I reproduced this by remotely debugging an integration test and artificially creating an instance of {{OptimisticLockingException}} in {{CommandContext#close}}. This exception is then rethrown which creates the same situation as if there was an actual optimistic locking problem.
          * You can configure Weblogic for remote debugging by adding the entry {{<property name="jvmOptions">-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y</property>}} to {{arquillian.xml}}
          * I did not yet understand why the failure of the managed transaction also results in the process engine not being available in the container
          * I was a bit surprised to see a managed transaction here, since {{EjbBpmPlatformBootstrap}} is annotated with {{@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)}}, but I guess that I just don't have that level of Java-EE-fu
          thorben.lindhauer Thorben Lindhauer made changes -
          Link This issue is related to CAM-8866 [ CAM-8866 ]
          thorben.lindhauer Thorben Lindhauer made changes -
          Fix Version/s 7.9.x [ 15107 ]
          Fix Version/s 7.10.x [ 15312 ]
          Fix Version/s 7.11.0 [ 15343 ]
          thorben.lindhauer Thorben Lindhauer made changes -
          Assignee Tobias Metzke [ tobias.metzke ]
          thorben.lindhauer Thorben Lindhauer made changes -
          Link This issue is depended on by SUPPORT-5295 [ SUPPORT-5295 ]
          tobias.metzke Tobias Metzke made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          tobias.metzke Tobias Metzke made changes -
          Fix Version/s 7.10.2 [ 15351 ]
          Fix Version/s 7.10.x [ 15312 ]
          tobias.metzke Tobias Metzke made changes -
          Fix Version/s 7.9.9 [ 15352 ]
          Fix Version/s 7.9.x [ 15107 ]
          tobias.metzke Tobias Metzke made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Original Estimate 0 minutes [ 0 ]
          Remaining Estimate 0 minutes [ 0 ]
          Assignee Tobias Metzke [ tobias.metzke ] Nikola Koevski [ nikola.koevski ]
          Resolution Fixed [ 1 ]
          thorben.lindhauer Thorben Lindhauer made changes -
          Remote Link This issue links to "Page (camunda confluence)" [ 12596 ]
          nikola.koevski Nikola Koevski made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          thorben.lindhauer Thorben Lindhauer made changes -
          Fix Version/s 7.11.0-alpha1 [ 15370 ]
          thorben.lindhauer Thorben Lindhauer made changes -
          Workflow camunda BPM [ 54623 ] Backup_camunda BPM [ 64208 ]
          thorben.lindhauer Thorben Lindhauer made changes -
          Remote Link This issue links to "Page (camunda confluence)" [ 12596 ]

            People

            • Assignee:
              nikola.koevski Nikola Koevski
              Reporter:
              thorben.lindhauer Thorben Lindhauer
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development