Red Hat Bugzilla – Bug 834730
Handling task deadlines in container causes TX errors
Last modified: 2016-09-20 01:07:14 EDT
Description of problem: Setting a deadline-based reassignment or notification for a task causes a TX rollback at the scheduled time: 2012-06-22 13:39:43,006 ERROR [org.jbpm.task.service.TaskService] (pool-33-thread-1) Could not start transaction. java.lang.RuntimeException: Could not start transaction. at org.jbpm.task.service.TaskServiceSession.executeEscalatedDeadline(TaskServiceSession.java:1075) at org.jbpm.task.service.TaskService.executeEscalatedDeadline(TaskService.java:221) at org.jbpm.task.service.TaskService$ScheduledTaskDeadline.call(TaskService.java:359) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Caused by: java.lang.NullPointerException at org.drools.persistence.jta.JtaTransactionManager.getStatus(JtaTransactionManager.java:205) at org.jbpm.task.service.persistence.TaskJTATransactionManager.getStatus(TaskJTATransactionManager.java:63) at org.jbpm.task.service.persistence.TaskJTATransactionManager.begin(TaskJTATransactionManager.java:36) at org.jbpm.task.service.persistence.TaskPersistenceManager.beginTransaction(TaskPersistenceManager.java:87) at org.jbpm.task.service.TaskServiceSession.executeEscalatedDeadline(TaskServiceSession.java:1048) ... 9 more Version-Release number of selected component (if applicable): ER9 How reproducible: Set up a deadline on a task and start the process using a LocalTaskService, for example: [users:babak]@[15s] Watch the log at the time of deadline Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: When the application is running in JBoss EAP, a single TaskSessionFactoryImpl is created for the TaskService and useJTA is detected as true. However the execution of the escalation handler happens within spawned-off threads as part of a ScheduledThreadPoolExecutor(). At the time of the execution, a new TaskServiceSession() is created with a new TaskPersistenceManager(), which in turn means a new instantiation of JtaTransactionManager() and an attempt to look up "java:comp/UserTransaction". However this JNDI name is only available when looked up from deployed code. Threads spawned off from deployed applications, including those in this scenario for handling task deadlines, will not have access to "java:comp/UserTransaction" and that results in a null UserTransaction and an NPE at the time of execution.
So far was not able to reproduce the issue but runnin on ER9, GA build is downloading but it tasks sometime. Configuration I tried: - default standalone BRMS ER9 (hornetq task service deployed by web application - jbpm-human-task-war) - modified business-central-server configuration to enable local task service instead of remote (hornetq) In both configuration run single process with one human task and reassignment after 1minute. All tests so far performed worked fine. Could you please provide bit more information on how the application is composed? Does it use standalone brms or embedded in an application, if so, what kind of application, is it spring based?
No, not from Spring... just the opposite, it must be a Java EE application. I'm starting the process from a BMT stateless session bean and of course, that means it's embedded. The EntityManagerFactory is being injected into the EJB and that is significant because the jBPM code does a getTransaction() call on emf to figure out if it's a JTA environment and if it is, that's when the issue comes to light.
Added support for various JNDI look up keys for global transaction in case execution is done by non ee thread. By default support EAP5 and AS7 (EAP6). Committed to master (commit https://github.com/droolsjbpm/jbpm/commit/cd06254f8e906c9f9bc25609a73c936e3ed3ea4c)
Additional commit was made to drools =-persistence-jpa module to avoid NPE and throw IllegalStateException when no UT was found when bootstraping JTA transaction manager: https://github.com/droolsjbpm/drools/commit/653e9a7cdb8011c1eb3193c034c161db79d14e8a
Thank you Maciej, I believe your code changes provide a flexible fix to the issue in hand and should certainly help us get past this client use case. We will need a patch for this as soon as possible, to help the client application go forward. Kindly provide us with the necessary patch on top of the GA application.
Alright, Lukas what is the procedure now for this patch? Shall this be merged into dedicated branch? One thing to notice is that there was an issue dicovered with deadlines some time ago and was fixed on master https://issues.jboss.org/browse/JBPM-3661 that I believe should be part of the patch.
Maciej (and Lukas), I talked to Kashinath this morning (CEST) and "patch" means "jars". That seems to be the case ("patch" == "jars") for most non-engineers. :) I'm going to do the following: - add a 5.2-patch branch to the community github and cherry-pick/adapt the commit to that branch. - produce jars based on that branch and send them to Babak and Kashinath.
Uhm, ignore my comment above and see the ongoing conversation on #jbosssoa instead. :)
Maciej has already completed the code fixes for this BZ. The commits are currently on master: https://github.com/droolsjbpm/jbpm/commit/cd06254f8e906c9f9bc25609a73c936e3ed3ea4c https://github.com/droolsjbpm/drools/commit/653e9a7cdb8011c1eb3193c034c161db79d14e8a with the JIRA:https://issues.jboss.org/browse/JBPM-3661 At this point development needs help to know what branches to commit this fixes to so it can be moved forward to QA. Please let Maciej know. Thanks.
The commit to the human-task module has been cherry-picked to the 5.2.x branch. ( https://github.com/droolsjbpm/jbpm/commit/cd06254f8e906c9f9bc25609a73c936e3ed3ea4c )
Patch verified. The TX issue is resolved. Thank you Maciej et al.
Verified on 5.3.1.BRMS-ER1.
Doc text has been edited for inclusion in the release notes. Thanks for providing the text, Maciej. - Lee