Bug 771742

Summary:	race conditions with claimTask operation
Product:	[JBoss] JBoss Enterprise BRMS Platform 5	Reporter:	Jeffrey Bride <jbride2001>
Component:	jBPM 5	Assignee:	Kris Verlaenen <kverlaen>
Status:	VERIFIED ---	QA Contact:	Radovan Synek <rsynek>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	BRMS 5.3.0.GA	CC:	atangrin, lpetrovi
Target Milestone:	ER6	Keywords:	Reopened
Target Release:	BRMS 5.3.0.GA
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-02-03 03:45:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Jeffrey Bride 2012-01-04 19:44:15 UTC

using a Resource-Local configured JPA EntityManager, a race condition occurs when multiple clients attempt to claim the same task.  The comments section of this bugzilla will include a link to the test case that demonstrates this race condition.

using a JTA enabled EntityManager, a race condition continues to occur when multiple clients attempt to claim the same task while other clients simultaneously create new tasks.  The race condition is reproducible in a JBoss EAP 5.1 environment.  at this time, I do not have a test case that reproduces the problem using JbpmJUnitTestCase.

what has been proven to completely resolve race conditions with task functionality is the addition of an optimistic lock on org.jbpm.task.Task.

Comment 1 Jeffrey Bride 2012-01-04 19:55:24 UTC

the following is the URL of the test case that reproduces the race condition in a non-JTA environment :

https://github.com/jbride/jbpm/blob/5.2.x-gbd/jbpm-human-task/src/test/java/org/jbpm/task/service/local/sync/BRMS_771742_Test.java

Comment 3 Kris Verlaenen 2012-01-26 15:44:34 UTC

If I understood correctly, you already implemented a fix to this using optimistic locking?  Is this available on your branch?  If so, could you link me to it, as I tried browsing the commits but couldn't find it immediately.

Comment 5 Jeffrey Bride 2012-01-29 15:15:16 UTC

Hi Kris,
  here is the url to a Task class with an optimistic lock :
  
https://github.com/jbride/jbpm/blob/5.2.x-gbd/jbpm-human-task/src/main/java/org/jbpm/task/Task.java

... it's implemented similar to your processInstanceInfo / workItemInfo/ sessionInfo classes.

I'm of the opinion that we may want to add an optimistic lock to the Task class even if JTA solves race conditions.  Seems that there are several requests to have jbpm5 support non-JTA environments in which case support for task concurrency (free of race conditions) is still going to be needed.

our performance test findings are that when using a non-JTA enabled TaskServiceSession ..... jbpm5 is extrememly performant.  As soon as the switch to JTA enabled TaskServiceSession is made.... performance and scalability drops drastically in a JBoss EAP 5.1.x.

some of this performance/scalability/stability degradation can be resolved by tuning arjuna .... which we eventually may decide to do.  However, it would be nice to be able to switch between JTA / non-JTA without worrying about race conditions.

thanks Kris,

jeff

Comment 6 Kris Verlaenen 2012-01-31 16:11:51 UTC

Jeff,

This change has been committed in the community, could you check if this solves your issue?

Kris

Comment 7 Jeffrey Bride 2012-02-03 03:45:45 UTC

thanks for implementing this Kris.
I've tested it out and the new lock works perfectly.
I'll close this bug.

thanks again!

jeff

Comment 8 Kris Verlaenen 2012-02-08 13:05:15 UTC

I had to temporarily roll back this fix in the jbpm 5.2.x branch as it is causing unwanted side effects in the jbpm-console.  I'll investigate.
See https://bugzilla.redhat.com/show_bug.cgi?id=788489

Comment 9 Kris Verlaenen 2012-04-12 13:25:25 UTC

The fix was reapplied (a while ago) as it was not the cause for the side effects, everything was working fine already.

Comment 10 Ryan Zhang 2012-04-23 07:35:45 UTC

Update status to ON_QA. Please verify them against ER6.