Indeed, it was that easy. ;-)

We were aware of the I/O blocking issues and we were running our operations inside workers on their own threads but were suffering problems when trying to communicate with the database in our handler as there wasn't a connection attached in that thread when calling completeWorkItem() ... we didn't realize that we should be able to complete workitems using the bound WorkItemManager attached to the knowledge session instead.

Thanks!

Alberto R. Galdo
argaldo@gmail.com


On Wed, Oct 17, 2012 at 6:52 PM, Mauricio Salatino <salaboy@gmail.com> wrote:
Hi Alberto,
yes you can, the only thing that you need to do is deal with those I/O blocking operations as external and Async Tasks. Instead of making your Task sync (which will block by definition until your operations are done) just make them async by removing the completeWorkItem() method call from inside the workItemHandler. Then when you I/O's are done, you will need to call the completeWorkItem using ksession.getWorkItemManager().completeWorkItem() method.

Cheers

On Wed, Oct 17, 2012 at 1:35 PM, Alberto R. Galdo <argaldo@gmail.com> wrote:
Hi All, 

   We have an application where we are using JBPM for our processes. In our application there's a strong requirement to maintain the same KnowledgeSession between restarts even though that we are not using rules at all, just BPMN 2.0 processes ( we are aware that JBPM needs it to maintain process state, workitem state and so on ...  but don't need neither rules nor ReteOO loops in our app ).

   Now we got to the tricky task handling part, were we have several handlers that depend on I/O which blocks the entire execution of the processes. And just because all our application depends on the *same* shared stored knowledge session, all our other parallel processes that need to execute processes are waiting ( like in a queue ) for the I/O to finish and execute themselves whenever the execution of JBPM gets blocked by I/O.

   We've tried to execute our handlers in different threads, but as we are running inside a persisted environment JBPM looses the JTA transaction as it is not bound to the current thread. Seems not a solution. We tried then to implement thread communication mechanisms, yield() and notify() and just made the problem worse.

   Any insights on the subject? How can we execute parallel non-blocking processes inside a shared and persisted KnowlegdeSession with JBPM?

Greets,  

Alberto R. Galdo
argaldo@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