Bug 850891
| Summary: | AbstractBpm5Action is registering handlers too freely | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 5 | Reporter: | Rick Wagner <rwagner> | ||||||
| Component: | JBossESB | Assignee: | tcunning | ||||||
| Status: | CLOSED UPSTREAM | QA Contact: | Matej Melko <mmelko> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 5.3.0 GA | CC: | jpechane, ldimaggi, mbaluch, nobody, tcunning | ||||||
| Target Milestone: | ER1 | ||||||||
| Target Release: | 5.3.1 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: |
There is an issue with the way in which AbstractBpm5Action is registering handlers when processes start. When a user closes a task via the console, a race condition is causing an exception to occur.
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 876280 (view as bug list) | Environment: | |||||||
| Last Closed: | 2025-02-10 03:20:34 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 860046 | ||||||||
| Attachments: |
|
||||||||
Why is this marked as private? What is the status of this bugreport? Thanks Changed permissions to mkae public. (Sorry, it looks like I had marked it private even though no customer-specific information is here.) I've tentatively added this bug to Roll up patch SOA_5.3_2_2012. We'll know more about ETA as other work progresses. Thanks, Rick Tom Cunningham <tcunning> updated the status of jira JBESB-3862 to Resolved Tom Cunningham <tcunning> made a comment on jira JBESB-3862 Only register the handlers once - we had been registering handlers every time a process instance was started. Tom Cunningham <tcunning> updated the status of jira JBESB-3862 to Closed This BZ is for 5.3.1. There is a 5.3_2 Roll up BZ that matches it 876280. Created attachment 649687 [details]
Server Log
Created attachment 649688 [details]
Reproducer
The race condition between handlers still occurs. See attached server.log.
The stack in the server log can be easily reproduced using the following steps.
1) deploy the attached esb application
2) invoke it a few times
{code}
Message esbMessage = MessageFactory.getInstance().getMessage();
esbMessage.getBody().add("Empty");
new ServiceInvoker("FirstServiceESB", "StartListener").deliverSync(esbMessage, 5000L);
{code}
3) go to the console, log in as krisv:krisv and attempt to complete one of the tasks.
*** Bug 881925 has been marked as a duplicate of this bug. *** Tom Cunningham <tcunning> updated the status of jira JBESB-3862 to Reopened *** Bug 904952 has been marked as a duplicate of this bug. *** This product has been discontinued or is no longer tracked in Red Hat Bugzilla. |
AbstractBpm5Action is doing some handler registration for *each* process instance start and service callback: .... ksession.getWorkItemManager().registerWorkItemHandler("JBossESB", esbhandler); ksession.getWorkItemManager().registerWorkItemHandler("ESBAction", actionhandler); ksession.getWorkItemManager().registerWorkItemHandler("Human Task", khandler); 'khandler' in particular is an instance of CommandBasedHornetQWSHumanTaskHandler by default. So when the user goes to close a task, all those handlers fire (JPA trips up, too): 012-08-22 12:32:06,006 INFO [STDOUT] (Thread-32) Notification of completed task 132 2012-08-22 12:32:06,017 INFO [STDOUT] (Thread-34) Notification of completed task 132 2012-08-22 12:32:06,025 INFO [STDOUT] (Thread-35) Notification of completed task 132 2012-08-22 12:32:06,033 INFO [STDOUT] (Thread-36) Notification of completed task 132 2012-08-22 12:32:06,042 INFO [STDOUT] (Thread-37) Notification of completed task 132 2012-08-22 12:32:06,049 INFO [STDOUT] (Thread-37) Notification of completed task 132 2012-08-22 12:32:06,056 INFO [STDOUT] (Thread-38) Notification of completed task 132 2012-08-22 12:32:06,063 INFO [STDOUT] (Thread-39) Notification of completed task 132 2012-08-22 12:32:06,069 INFO [STDOUT] (Thread-40) Notification of completed task 132 2012-08-22 12:32:06,076 INFO [STDOUT] (Thread-41) Notification of completed task 132 2012-08-22 12:32:06,082 INFO [STDOUT] (Thread-41) Notification of completed task 132 2012-08-22 12:32:05,985 INFO [STDOUT] (Thread-31) Notification of completed task 132 2012-08-22 12:32:05,998 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (Thread-31) Could not synchronize database state with session org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.persistence.processinstance.ProcessInstanceInfo#44] at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1782) ....... at org.jbpm.task.service.hornetq.CommandBasedHornetQWSHumanTaskHandler$GetCompletedTaskResponseHandler.execute(CommandBasedHornetQWSHumanTaskHandler.java:273)