[rules-users] Workitems doesn't get persisted when completing a task after rehydrating a knowledge session is some circumstances.
Mauricio Salatino
salaboy at gmail.com
Fri Jun 22 09:03:58 EDT 2012
So, can you create an isolated test where you reproduce:
"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"
And I can take a look on that.. Please create Jira issue for that.
Without a concrete situation it's very difficult to analyze.. Did you check
your transactions not being rolledback.. That's the only situation where I
think that the workItem information will not be persisted.
Cheers
On Fri, Jun 22, 2012 at 9:55 AM, Alberto R. Galdo <argaldo at gmail.com> wrote:
>
> 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
>>
>>
>
> _______________________________________________
> 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/add910c0/attachment.html
More information about the rules-users
mailing list