a little more digging shows that if I alter process definition and remove Signal Event and converge gateway, everything works OK!??
I don't get it: this should always work regardless of the process elements, and it seems that in this particular scenario it does not work.
Also, I see that I did not load DRL file, but this is irrelevant (you can alter method readKnowledgeBase() and add sample.drl into a knowledge builder).
I have tried to use Janino compiler, set JPA placeholder resolver transaction strategy (according to Variable Persistence Strategy, set JPAPlaceholderResolverStrategy into Environment) but that did not help.
1 of 1 people found this helpful
I just look at your case and I think that it is very strange behavior. I debug it a bit and it turned out that the issue is in fact related to the signal event. It is stored under externalEventListeners map of WorkflowProcessInstanceImpl which is a super class for RuleflowProcessInstance.
I made very quick change in that class to make this map transient - after that your process completed successfully with firing of the rule - since the process instance was found in the session.
I made yet another test to verify if that did brake anything (as far as I could test it) so I made your process run in two steps:
1. create process instance and dispose the session
2. load the session, load the process instance and signal it
all steps went fine, no exception whatsoever.
So question is why that map is not serialized and should it be serialized? I thought events are kept in DB...
what do you think about it?
thanks a lot for the effort!
As for the events, my personal opinion is that events should be persisted with all other artefacts that comprise process.
That is, because a process could be serialized into database in any "safe point" of its execution, and after its deserialization all connections between process elements and its listeners should be re-created.
If you open JIRA issue, you'll see that Kris had already marked it as solved, with the explanation that the signal was registering a non-serializable listener. But I don't see the solution...
Yeah, you're right it is solved. It is already commited to github and in fact you can grab a nightly build that contains that fix from Jenkins: https://hudson.jboss.org/jenkins/job/jBPM/785/artifact/jbpm-distribution/target/