I have the same problem. I tested against exactly the same process flow that you have. Tried restoring the session as well which doesn't help - process instances won't continue executing after server restart.
You may want to take a look here: https://community.jboss.org/thread/200708.
There is an answer:
at the moment of the "crash", the processes has been persisted? A process is persisted when it reaches a "wait state". I catching signal event is a wait state.
If so, you can simply do,
ksession = JPAKnowledgeService.loadStatefulKnowledgeSession(sessionId, kbase, null, env);
as the processes are already persisted in db.
I don't get the answer at all and I don't know what ksession.signalEvent("Trigger", null); is supposed to do here. Anyway, I tried it, didn't work, but maybe you can
get something usefull out of this topic.
I'm also still looking for a solution to this problem.
Ok it seems I found the solution. The problem is described here http://drools.46999.n3.nabble.com/rules-users-JBPM-fails-to-resume-a-rehydrated-active-process-instance-td4017746.html and there's a solution here https://community.jboss.org/thread/167105.
Thanks for the reply, but it doesn't resolve my problem.
I started to debug the code in detail and I managed to find the cause and resolve the problem. It turned out that the cause was as follows the state of ProcessInstanceInfo was not often saved in the database after process moved to the next task. Thus, old state of process instance was read after server reboot and process instance couldn't go on to the next node/task properly.
For entity mapping of ProcessInstanceInfo I used JBPMorm-JPA2.xml that I had found in jbpm-persistence-jpa-5.3.0.Final.jar. It turned out that the mapping of fields of type date was incorrect, because these fields were marked with DATE but should have been marked with TIMESTAMP.
This resulted in not updating state of ProcessInstanceInfo in database. Updates are made only when value of any field (except of clob column) of the ProcessInstanceInfo is changed, but often only lastReadDate is changed during process instance execution. Thus, when many human tasks of the same process instance is executed on the same day, value of lastReadDate field doesn't change because it ignores the time part of the current timestamp.
When I changed in date fields mapping from DATE to TIMESTAMP, all process instances are executed properly after server restart.