[rules-users] Task Handler blocking

[Alberto R. Galdo]

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 at gmail.com


On Wed, Oct 17, 2012 at 6:52 PM, Mauricio Salatino <salaboy at 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 at 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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20121018/4e9ee873/attachment.html