[rules-users] Workitems doesn't get persisted when completing a task after rehydrating a knowledge session is some circumstances.

[Mauricio Salatino]

  "We are unable to complete a human task after rehydrating a Drools
knowledge session because in some circunstances the generated Drools'
workitems don't get persisted in the database after the completion of a
previous task"

They are never persisted, they are runtime information that you must
re-register after rehydrating the session. Are you doing that?
Cheers

On Fri, Jun 22, 2012 at 7:34 AM, Alberto R. Galdo <argaldo at gmail.com> wrote:

> Hi,
>
>    We have a fairly large BPMN process running inside a JPA persisted
> StatefulKnowledgeSession using Drools 5.4 & JBPM 5.3. Our process involves
> timers, automated tasks, human tasks .... most of them are long-running
> processes, so a fault-tolerant scenario is a must.
>
>     We've found what seems to be a weird, weird bug in JBPM-Drools
> regarding the execution of BPMN processes. This is by best to summarize the
> problem:
>
>      "We are unable to complete a human task after rehydrating a Drools
> knowledge session because in some circunstances the generated Drools'
> workitems don't get persisted in the database after the completion of a
> previous task"
>
>     So, as the workitem is not in the database, when a human task client
> completes a task that is related to that non-existent workitem, the process
> doesn't get restarted. And the process fails.
>
>     ¿Why does this happens? Lets see:
>
>      When the processs is executed, different workitems get created,
> updated and eventually deleted during the execution of a process up until a
> human task is created ( in our process ). When living in a persistet
> knowledge session, the transaction that is associated to Drools' thread is
> commited right after the human task is created in the human task server ...
> as it is a "safe point". Nothing here. Everithing is consistent, if you
> look at the database you will see your session instance, your process
> instance, and the final human task workitem as it is the only workitem
> survivor after the execution ( whatever hadler-managed automated task that
> were executed before the human task are deleted and the human task workitem
> needs to survive as it's completion depends on asyncronous client
> interaction ).
>
>      Now, if you connect to the human task server and complete that human
> task, a message is sent to the Drools session to update the state of the
> work item. The workitem gets updated, the process get restarted and the
> flow continues ... maybe generating a new human task ( which is our case ).
> At this very moment, if you take a look at the database, there are no
> automated-handled-task workitems ( as expected ) but there isn't any human
> task related work item, even worse, the task at the human task server is
> created, persisted and has a reference to the non-existant workitem.
>
>     Days of debugging led us to what we think is the source of the
> problem:
>
>     We found that the execution of the process after completing a task is
> being executed in the same thread as the one that receives the mina message
> that the human task server sends whenever a task is completed. This thread
> is not the same thread that executes the knowledgesession ( where the
> reteoo lives ) and so it doesn't have a transaction. By the way, we found
> that for  workitem persistence the JPAWorkitemManager never joins an active
> transaction. :(
>
>     That's why invoking the persistence of a workitem as a consequence of
> restarting the execution of a process inside the thread that receives the
> mina messages makes the database inconsistent, and so invalidating all
> means to make JBPM fault tolerant by making Drools session persistent.
>
>     We found a way to circunvent this problem, making all our human task
> nodes be followed by a event timer. That way, when the timer gets completed
> we force the execution of the process to live in the same thread that the
> reteoo session lives where a transaction is available and things get back
> to normal. But this is really dirty and wrong.
>
>     Any thoughts?
>
>     We are really eager to be wrong whith this. :'(
>
> Greets,
>
>
>
> Alberto R. Galdo
> argaldo at gmail.com
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>


-- 
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar

 - Salatino "Salaboy" Mauricio -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120622/4f8d8609/attachment-0001.html