Bug 780932 (SOA-3399) - jBPM tests consistently shows potential deadlock for some of the tests
Summary: jBPM tests consistently shows potential deadlock for some of the tests
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-3399
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBPM - within SOA
Version: 5.2.0.ER4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 5.2.0.ER5
Assignee: tcunning
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-21 10:55 UTC by Jiri Pechanec
Modified: 2011-10-21 08:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-21 08:21:02 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-3399 0 Minor Closed jBPM tests consistently shows potential deadlock for some of the tests 2012-09-19 15:13:39 UTC

Description Jiri Pechanec 2011-09-21 10:55:12 UTC
project_key: SOA

Look at the test report in the link

https://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbpm-db-openjdk16/73/testReport/

There are four tests that fail consistently across all supported databases
org.jbpm.jbpm2094.JBPM2094Test.testJobExecutorDeadlock
org.jbpm.jbpm2787.JBPM2787Test.testProcessInstancesStuckInJoin
org.jbpm.jbpm983.JBPM983Test.testConcurrentJobs
org.jbpm.job.executor.JobExecutorDbTest.testJobExecutor

It seems that there can be a deadlock inside the code.
If the issue is related to JobExecutor only then we can lower the priority as JobExecutor is not used in SOA-P.
The tests are passing with H2 database.

Comment 1 Len DiMaggio 2011-09-26 14:11:27 UTC
Affects Testing: Added: [Regression]


Comment 2 Kevin Conner 2011-10-04 01:41:27 UTC
This is not a deadlock in the jBPM code, rather it is a problem with the way in which the tests are being executed.

What appears to be happening is that the JobExecutorThread executes the job and catches an exception, causing it to attempt to save the information and reschedule.
Within the saveJobExecution method it attempts to calculate the waitPeriod as follows
      int waitPeriod = jobExecutor.getRetryInterval() / 2;
      waitPeriod += random.nextInt(waitPeriod) ;
however the retry interval of the jobExecutor is 0.  This causes the Random.nextInt to throw an IllegalArgumentException and stall the test.

The tests are obtaining their configuration from the ESB configuration, specifically jbpm.esb/config/jobexecutor/jbpm.cfg.xml.config, which does not specify the retryInterval.

In order to fix this we must simply add the following to the end of the jbpm.job.executor configuration
    <property name="retryInterval"><int value="4000" /></property> <!-- 4 seconds -->


Comment 3 Kevin Conner 2011-10-04 01:45:40 UTC
Link: Added: This issue depends JBESB-3696


Comment 4 tcunning 2011-10-10 04:23:11 UTC
Added retryInterval.

new-host-3:services cunningt$ svn commit
Sending        services/jbpm/src/main/resources/config/hornetqscheduler/jbpm.cfg.xml.config
Sending        services/jbpm/src/main/resources/config/jmsscheduler/jbpm.cfg.xml.config
Sending        services/jbpm/src/main/resources/config/quartzscheduler/jbpm.cfg.xml.config
Sending        services/jbpm/src/main/resources/jbpm.cfg.xml
Transmitting file data ....
Committed revision 37523.

Comment 5 Jiri Pechanec 2011-10-21 08:21:02 UTC
Verified in ER5


Note You need to log in before you can comment on or make changes to this bug.