[jboss-jira] [JBoss JIRA] Closed: (JBPM-995) CLONE -concurrent job acquirement fails

[Tom Baeyens (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBPM-995?page=all ]

Tom Baeyens closed JBPM-995.
----------------------------

    Fix Version/s: jBPM jPDL 3.2.2
       Resolution: Done

The static synchronization was added on the JobExecutor object.

Furthermore, the logging of optimistic locking failures is made configurable.  This is what was added to the user guide:

6.4. Logging of optimistic concurrency exceptions
When running in a cluster, jBPM synchronizes on the database. By default with optimistic locking. This means that each operation is performed in a transaction. And if at the end a collision is detected, then the transaction is rolled back and has to be handled. E.g. by a retry. So optimistic locking exceptions are usually part of the normal operation. Therefor, by default, the org.hibernate.StateObjectStateExceptions the that hibernate throws in that case are not logged with error and a stack trace, but instead a simple info message 'optimistic locking failed' is displayed. 

Hibernate itself will log the StateObjectStateException including a stack trace. If you want to get rid of these stack traces, put the level of org.hibernate.event.def.AbstractFlushingEventListener to FATAL. If you use log4j following line of configuration can be used for that: 

log4j.logger.org.hibernate.event.def.AbstractFlushingEventListener=FATAL

If you want to enable logging of the jBPM stack traces, add the following line to your jbpm.cfg.xml: 

<boolean name="jbpm.hide.stale.object.exceptions" value="false" />


> CLONE -concurrent job acquirement fails
> ---------------------------------------
>
>                 Key: JBPM-995
>                 URL: http://jira.jboss.com/jira/browse/JBPM-995
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM jPDL 3.2
>            Reporter: Edward Staub
>         Assigned To: Tom Baeyens
>             Fix For: jBPM jPDL 3.2.2
>
>
> when more than 1 job executor thread is configured and concurrent async nodes are to be executed, it results in hibernate exceptions.
> reason: job acquirement is not synchronized well, resulting in multiple threads trying to work on the same job.
> In reproducing JBPM-983, I ran into Alex's JBPM-974 problem, which has already been closed.  So I cloned it here..  let me know if that was incorrect process.  
> The problem was easy to reproduce, and was easy to predict in the first place.  Alex's fix (sychronize on a static class member around acquireJobs()) works for me as well.  It probably trivially improves performance, by avoiding aborted acquire attempts.
> As noted in JBPM-974, it only causes an erroneous error message being emitted - the code operates correctly.  It also makes debugging other race conditions much more difficult by injecting a lot of noise - they usually show up as stale objects as well.
> I believe the reason the trace is dumped to the log is because it's dumped at ERROR level before it even gets to JBPM, in org.hibernate.event.def.AbstractFlushingEventListener.performExecutions.  So the "catch (StaleStateException e)" doesn't suppress it - the horse has left the barn, the train has left the station, the s--t has already hit the fan - pick your favorite metaphor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira