This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 850891 - AbstractBpm5Action is registering handlers too freely
AbstractBpm5Action is registering handlers too freely
Status: ASSIGNED
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB (Show other bugs)
5.3.0 GA
Unspecified Unspecified
unspecified Severity unspecified
: ER1
: 5.3.1
Assigned To: tcunning
Matej Melko
:
: 881925 (view as bug list)
Depends On:
Blocks: 860046
  Show dependency treegraph
 
Reported: 2012-08-22 12:15 EDT by Rick Wagner
Modified: 2015-11-02 03:04 EST (History)
6 users (show)

See Also:
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:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Server Log (394.78 KB, text/x-log)
2012-11-22 05:49 EST, Marek Baluch
no flags Details
Reproducer (3.15 KB, application/octet-stream)
2012-11-22 05:50 EST, Marek Baluch
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBESB-3862 Major Reopened AbstractBpm5Action is registering handlers too freely 2015-07-08 13:26:38 EDT
JBoss Issue Tracker JBESB-3900 Major Closed Use existing session if message has same session ID 2015-07-08 13:26:38 EDT
JBoss Issue Tracker JBESB-3901 Major Closed jbpm5 sessions should be static by processDefName 2015-07-08 13:26:38 EDT

  None (edit)
Description Rick Wagner 2012-08-22 12:15:51 EDT
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)
Comment 1 Adam Kovari 2012-10-12 08:14:24 EDT
Why is this marked as private? What is the status of this bugreport? Thanks
Comment 2 Rick Wagner 2012-10-12 13:45:49 EDT
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
Comment 4 JBoss JIRA Server 2012-10-18 15:06:32 EDT
Tom Cunningham <tcunning@redhat.com> updated the status of jira JBESB-3862 to Resolved
Comment 5 JBoss JIRA Server 2012-10-18 15:07:01 EDT
Tom Cunningham <tcunning@redhat.com> made a comment on jira JBESB-3862

Only register the handlers once - we had been registering handlers every time a process instance was started.
Comment 6 JBoss JIRA Server 2012-10-18 15:07:08 EDT
Tom Cunningham <tcunning@redhat.com> updated the status of jira JBESB-3862 to Closed
Comment 7 Rick Wagner 2012-11-13 12:38:11 EST
This BZ is for 5.3.1.  There is a 5.3_2 Roll up BZ that matches it 876280.
Comment 8 Marek Baluch 2012-11-22 05:49:44 EST
Created attachment 649687 [details]
Server Log
Comment 9 Marek Baluch 2012-11-22 05:50:29 EST
Created attachment 649688 [details]
Reproducer
Comment 10 Marek Baluch 2012-11-22 05:50:50 EST
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.
Comment 11 Rick Wagner 2012-12-12 12:41:28 EST
*** Bug 881925 has been marked as a duplicate of this bug. ***
Comment 12 JBoss JIRA Server 2013-01-15 15:13:20 EST
Tom Cunningham <tcunning@redhat.com> updated the status of jira JBESB-3862 to Reopened
Comment 13 tcunning 2013-02-11 10:22:10 EST
*** Bug 904952 has been marked as a duplicate of this bug. ***

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