[CAM-9671] Weblogic: Platform startup fails if history cleanup job cannot be re-configured Created: 23/Jan/19  Updated: 28/Feb/19  Resolved: 25/Jan/19

Status: Closed
Project: camunda BPM
Component/s: engine
Affects Version/s: None
Fix Version/s: 7.11.0, 7.10.2, 7.9.9, 7.11.0-alpha1

Type: Bug Report Priority: L3 - Default
Reporter: Thorben Lindhauer Assignee: Nikola Koevski
Resolution: Fixed Votes: 0
Labels: SUPPORT
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes

Attachments: Text File AdminServer.log     Text File org.camunda.bpm.integrationtest.functional.scriptengine.PaLocalScriptEngineCallActivityConditionTest-output.txt    
Issue Links:
Depedendency
Related
is related to CAM-8866 Engine startup can fail with OLE when... Closed

 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

Generated at Wed Oct 23 07:44:37 CEST 2019 using JIRA 6.4.6#64021-sha1:33e5b454af4594f54560ac233c30a6e00459507e.