could you provide an more concrete example as that should work assuming completeWorkItem finishes without an error.
The case is:
1. Procesess is started
StatefulKnowledgeSession ksession = (StatefulKnowledgeSession) deploymentService.getDeployedUnit(JBPM_PROCESSES_DEPLOYMENT_ID) .getRuntimeManager().getRuntimeEngine(ProcessInstanceIdContext.get()).getKieSession(); ksession.startProcess(processName, params);
Each workitem is handled by a same type of WorkItemHandler
2. WorkItemHandler sends a message with neede info plus process instance ID via JMS to a custom event processor
3. Processor processes the message (does some logic) and sends a similar response via JMS to response handler
4. This Response handler completes the workitem
StatefulKnowledgeSession ksession = (StatefulKnowledgeSession) deploymentService.getDeployedUnit(JBPM_PROCESSES_DEPLOYMENT_ID).getRuntimeManager() .getRuntimeEngine(ProcessInstanceIdContext.get(gateActionResponseMessage.getProcessId())).getKieSession(); ksession.getWorkItemManager().completeWorkItem(gateActionResponseMessage.getWorkItemId(), results);
5. Next workItem is handled in a similar way (pt. 2 - 4)
After all workitems are completed, i assume the process must complete also. But is does not.
1 of 1 people found this helpful
exactly, that should make the process instance completed if there are not other nodes in line. Things to verify:
- does processId is correct process instance id?
- does the work item id points to the correct work item?
- how do you verify if process instance is active?
to trace it you could register DebugProcessEventListener to see what is invoked and in what order.
- process ID and workitem ID are correct.
- the signs that process is still alive are:
- it is under "Active" tab in the console
- there is still respective record in SESSIONINFO (i use PER_PROCESS_INSTANCE strategy)
- there are no records of EndEvent for the process in NODEINSTANCELOG
would it be possible to get a reproducer to see what can be the issue?
Actualy, issue has gone today on it's own. I agree with you that there should be no flaws from jbpm side in the scenario I described above.
I guess the reason was in distributed tx management in our app, which was fixed.
I really have no idea what caused and solved this issue)
Thank you for your advice. It helped to understand deeply what's going on.
Consider this solved.