Description of problem: The problem is that Human Task related operations via the Remote API (REST or JMS) end up blocking because of a shared object TaskService instance (between all requests). How reproducible: Steps to Reproduce: 1. Run a performance test involving concurrent task-related remote requests 2. 3. Actual results: In JBPM-4547, the user reports that the average time is 30 seconds per request. Expected results: Faster than this. Additional info: The cause for this, an unforeseen combination of the TaskService architecture and the kie-wb/business-central CDI architecture, has already been identified.
fixed on master, another fix for 6.0.x (that this bug was originally filed against) is ready as well. jbpm master: https://github.com/droolsjbpm/jbpm/commit/0a2af06add50d2a78e258ffbd95c77019d969c55 if that shall be back ported to 6.2.x please assign this back to me as it has not all flags acks. same thing when 6.0.x fix should be applied - it does have different change not in jbpm but in droolsjbpm-integration)
Assigned again for backport.
backported to 6.2.x: jbpm 6.2.x: https://github.com/droolsjbpm/jbpm/commit/8953ff7a18ca86c0e4e86741460c992437112184
Maciej Swiderski <swiderski.maciej> updated the status of jira JBPM-4547 to Resolved
Maciej, Thank you for pointing me to a reproducer [1]. I reproduced the problem in BPMS 6.0.3.GA using the provided scenario. I could see ten BLOCKED threads containing TaskTransactionInterceptor, I used ten client threads. I have tested this with BPM Suite 6.1.0.ER6 and the problem is fixed. I could see only one thread with TaskTransactionInterceptor instance in status RUNNABLE. Verified in BPM Suite 6.1.0.ER6. [1] https://mojo.redhat.com/people/selrahal/blog/2015/02/04/load-testing-jbpm