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

Fri Jun 22 08:46:49 EDT 2012

There are two concepts here:
1) WorkItem -> Persist the state of the activity
2) WorkItemHandlers -> Never Persisted

Are you re-registering the WorkItemHandlers at rehydratation?
WorkItemHandlers are part of the runtime status and don't get persisted.
Cheers

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

> No, I'm not registering pending workitems at rehydration. That's why I'm
> using Drools & JBPM persistence ;-). I don't want to write my own state
> persistence, as I am a mere user of JBPM & Drools services.
>
> >> "They are never persisted"
>
> This several methods in org.drools.persitence.jpa.JPAPersistenceContext
> seem to say just the opposite:
>
> public void persist(WorkItemInfo workItemInfo)
> public void remove(WorkItemInfo workItemInfo)
> public WorkItemInfo merge(WorkItemInfo workItemInfo)
>
> The fact that lots of workitems get created, persisted, merged and finally
> removed during the life of the process doesn't hide the fact that they're
> in fact, .... well, persisted.
>
> If you take a look at the changes in the database whenever a human task is
> involved in a BPMN process that is executed inside a Drools & JBPM JPA
> persisted environment you will realize that indeed the human task are
> *persisted* and like so, rehydrated when loading the session in Drools.  In
> fact, those human task related workitems are never removed from the
> database, but that's another bug ... :(
>
> Any insight?
>
> Alberto R. Galdo
> argaldo at gmail.com
>
>
>
> On Fri, Jun 22, 2012 at 2:15 PM, Mauricio Salatino <salaboy at gmail.com>wrote:
>
>>   "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 -
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
> _______________________________________________
> 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/24171156/attachment.html 