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 <arga...@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 > arga...@gmail.com > > > > On Fri, Jun 22, 2012 at 2:46 PM, Mauricio Salatino <sala...@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 <arga...@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 >>> arga...@gmail.com >>> >>> >>> >>> On Fri, Jun 22, 2012 at 2:15 PM, Mauricio Salatino <sala...@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 <arga...@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 >>>>> arga...@gmail.com >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> rules-users mailing list >>>>> rules-users@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > _______________________________________________ > rules-users mailing list > rules-users@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users