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

Fri Jun 22 08:55:46 EDT 2012

Sure, WorkItemHandlers are never persisted. I re-register those handlers
before staring the session, just because I want my tasks to be properly
executed.

:(

Alberto R. Galdo
argaldo at gmail.com

On Fri, Jun 22, 2012 at 2:46 PM, Mauricio Salatino <salaboy at gmail.com>wrote:

> 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 -
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120622/3dea6042/attachment.html 