Bug 834730 - Handling task deadlines in container causes TX errors
Handling task deadlines in container causes TX errors
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5 (Show other bugs)
BRMS 5.3.0.GA
All All
unspecified Severity high
: ---
: ---
Assigned To: Maciej Swiderski
Radovan Synek
Depends On:
Blocks: 836996
  Show dependency treegraph
Reported: 2012-06-22 20:28 EDT by Babak Mozaffari
Modified: 2016-09-20 01:07 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Different application servers provide different forms of access to UserTransaction when running in a non-managed thread. Usually UserTransaction is accessible via JNDI but can be registered under different namespaces for different application servers. As a result of this, when there was no access to transaction instances a failure occurred. To resolve this issue known JNDI namespaces were added (EAP5 and EAP6), and others can be defined by setting the system property jbpm.ut.jndi.lookup, ensuring that UserTransaction can be accessed via JNDI.
Story Points: ---
Clone Of:
: 836996 (view as bug list)
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Babak Mozaffari 2012-06-22 20:28:40 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):

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:
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.
Comment 1 Maciej Swiderski 2012-06-24 10:47:26 EDT
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?
Comment 2 Babak Mozaffari 2012-06-24 13:44:03 EDT
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.
Comment 3 Maciej Swiderski 2012-06-27 08:28:09 EDT
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)
Comment 4 Maciej Swiderski 2012-06-28 11:03:30 EDT
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
Comment 5 Babak Mozaffari 2012-06-28 12:09:17 EDT
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.
Comment 6 Maciej Swiderski 2012-06-28 18:38:50 EDT
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.
Comment 8 Marco Rietveld 2012-06-29 03:37:57 EDT
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.
Comment 9 Marco Rietveld 2012-06-29 04:22:15 EDT
Uhm, ignore my comment above and see the ongoing conversation on #jbosssoa instead. :)
Comment 11 Tihomir Surdilovic 2012-06-29 12:06:40 EDT
Maciej has already completed the code fixes for this BZ. 
The commits are currently on master:
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.

Comment 13 Marco Rietveld 2012-07-02 10:01:32 EDT
The commit to the human-task module has been cherry-picked to the 5.2.x branch. 

( https://github.com/droolsjbpm/jbpm/commit/cd06254f8e906c9f9bc25609a73c936e3ed3ea4c )
Comment 14 Babak Mozaffari 2012-07-02 19:10:37 EDT
Patch verified. The TX issue is resolved.

Thank you Maciej et al.
Comment 15 Radovan Synek 2012-09-25 04:03:12 EDT
Verified on 5.3.1.BRMS-ER1.
Comment 16 lcarlon 2012-10-22 00:14:19 EDT
Doc text has been edited for inclusion in the release notes. Thanks for providing the text, Maciej.

- Lee

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