Bug 834730 - Handling task deadlines in container causes TX errors
Summary: Handling task deadlines in container causes TX errors
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5
Version: BRMS 5.3.0.GA
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
: ---
Assignee: Kris Verlaenen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 836996
TreeView+ depends on / blocked
 
Reported: 2012-06-23 00:28 UTC by Babak Mozaffari
Modified: 2025-02-10 03:20 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
: 836996 (view as bug list)
Environment:
Last Closed: 2025-02-10 03:20:11 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Babak Mozaffari 2012-06-23 00:28:40 UTC
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.

Comment 1 Maciej Swiderski 2012-06-24 14:47:26 UTC
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 17:44:03 UTC
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 12:28:09 UTC
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 15:03:30 UTC
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 16:09:17 UTC
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 22:38:50 UTC
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 07:37:57 UTC
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 08:22:15 UTC
Uhm, ignore my comment above and see the ongoing conversation on #jbosssoa instead. :)

Comment 11 Tihomir Surdilovic 2012-06-29 16:06:40 UTC
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.

Comment 13 Marco Rietveld 2012-07-02 14:01:32 UTC
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 23:10:37 UTC
Patch verified. The TX issue is resolved.

Thank you Maciej et al.

Comment 15 Radovan Synek 2012-09-25 08:03:12 UTC
Verified on 5.3.1.BRMS-ER1.

Comment 16 lcarlon 2012-10-22 04:14:19 UTC
Doc text has been edited for inclusion in the release notes. Thanks for providing the text, Maciej.

- Lee

Comment 26 Red Hat Bugzilla 2025-02-10 03:20:11 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.


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