[rules-users] Possibly race condition in a persisted Drools + JBPM during a StatefulKnowledgeSession

[Alberto R. Galdo]

Hi all,

   We've been for long time now developing a complex event processing
system that ( simplified version ahead !! ) involves a set of rules that in
turn activates a set processes that fulfill human tasks and other kind of
tasks.. This all is running in a StatefulKnowledgeSession with JPA
persistence configured both for Drools and JBPM. We are running an stack of
Drools, JBPM, Drools Integration, Drools fussion, etc..

   We've been able to persist Drools sessions & JBPM processes in the same
Persistence Context  ( not without pain :( ) using different JTA
implementations including ( but not limited to ) Bitronix & Atomikos.

    What we are observing here is what seems to be some kind of race
condition between Drools and JBPM when running the knowledge session when
JPA&JTA persistence is configured. Very often, as soon as after 2-3
processes get created as rule's consequences are fired in response of
events inside the session we see how JBPM finds its instance nullified by
Drools when it tries to end a process and persist it.

   We've been able to find where Drools decides to delete an instance of
the process ... at a given time Drools executes
JPAProcessInstanceManager.clearProcessInstances() [1] when it finalizes a
SingleSessionCommand wich in turn calls disconnect() for *all* the
local-stored processinstances ( wich gets populated with instances of
processes every time a process is started in the knowledge session ):

    public void clearProcessInstances() {

        for (ProcessInstance processInstance: new
ArrayList<ProcessInstance>(processInstances.values())) {
            ((ProcessInstanceImpl) processInstance).disconnect();
        }
    }


    So, Drools decides to disconnect all process instances in it's JPA
context without taking in account the state the process is in, and when an
processinstance that is not stopped gets removed then JBPM finds it's
NullPointerException...

    We've modified the code to make Drools aware of the state of the
process before wiping it from the context   ( no problem here, there will
be no leak as a running processinstance will be removed in future calls of
"clearProcessInstances" given the process is closed ). But unfortunatelly
this seems to resolve this problem, but lots of other problems ( wich seems
also race conditions arise :  for instance: Drools closes connections to
the database and JBPM finds the connection closed,


    So, we are really worried about using Drools & JBPM in a persisted
environment. Maybe our asumptions are wrong...  Is it possible to have an
scenario like ours given the current Drools & JBPM integration status for a
persistent statefulKnowledge Session?  Did anyone build a complex event
processing system like ours in a unaltered persistence environment such as
provided in Drools and JBPM by default?


Greets,

[1]
https://github.com/droolsjbpm/jbpm/blob/master/jbpm-persistence-jpa/src/main/java/org/jbpm/persistence/processinstance/JPAProcessInstanceManager.java






Alberto R. Galdo
argaldo at gmail.co <argaldo at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120529/7cdac7e8/attachment.html