Bug 826578

Summary:	Work item handler is lost after session reloading
Product:	[JBoss] JBoss Enterprise BRMS Platform 5	Reporter:	Radovan Synek <rsynek>
Component:	jBPM 5	Assignee:	Kris Verlaenen <kverlaen>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	BRMS 5.3.0.GA
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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:	---	Target Upstream Version:
Embargoed:

Description Radovan Synek 2012-05-30 14:41:22 UTC

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 22:39:27 UTC

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 13:52:18 UTC

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.