Bug 826578 - Work item handler is lost after session reloading
Work item handler is lost after session reloading
Status: NEW
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: jBPM 5 (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Kris Verlaenen
Radovan Synek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-30 10:41 EDT by Radovan Synek
Modified: 2012-07-03 18:57 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
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)

  None (edit)
Description Radovan Synek 2012-05-30 10:41:22 EDT
Description of problem:
This problem was revealed with adhoc subprocess, but I think it is more general. For example when the session is reloaded during task execution, after its completing the next task in the flow ends with the exception.

In this case, when the adhoc process is started, it waits for signalling each process fragment (or single task). If the knowledge session is reloaded from DB and the task (which needs work item handler) is signalled, org.drools.WorkItemHandlerNotFoundException is thrown.

How reproducible:
Please, take a look at org.jbpm.bpmn2.SimpleBPMNProcessTest.testAdHocProcessDynamicTask(). First, persistence needs to be enabled in the SimpleBPMNProcessTest. 
  
Actual results:
org.drools.WorkItemHandlerNotFoundException when the task is triggered after the session reloading. I don't think this is user friendly behavior.

Expected results:
Work item handler should be reloaded with the session.
Comment 1 Kris Verlaenen 2012-06-01 18:39:27 EDT
This behavior is as designed.

Work item handlers act as a connection between the engine and some external service.  Whenever a session is disposed and restored later from database, these handlers typically need to be reinitialized (for example, imagine the system went down completely, in that case the handler needs to relocate and reconnect to the external services).  These handlers typically also reference other systems, so they can't just be serialized.  Handlers also shouldn't be maintaining any state themselves, so not sure why they need to be persisted.

Work item handler registration is a normal part of session initialization, so whenever a session needs to be restored, registering the necessary handlers could be considered as part of the normal session initialization.

If the user would like to avoid having to manually register handlers whenever a session is created, a configuration file can be used to load service handlers from that.
Comment 2 Radovan Synek 2012-06-04 09:52:18 EDT
Hi Kris, 

thanks for the clarification, you are right - but I still wonder if it would be possible to provide some helper class / method which copies registered listeners and work item handlers from the given session to the newly loaded session. And when user provides no session to copy from, well - it's his job. This copying might save a lot of lines of code.

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