Re: [rules-users] Blocking Call to startProcess()

Kris, thanks for the quick reply. It makes perfect sense what you're saying about the implementation issues on the task level. Did I get it right that e.g. a specific task for (asynchronous) web service invocation would be implemented very similar to the WorkItemHandler http://www.mail-archive.com/rules-users@lists.jboss.org/msg09450.html? I didn't however understand yet why startProcess() has to block at all. Naively, this would rather be the semantics of a method like "executeProcess()". From my current understanding, even when launching concurrent instances from different threads using startProcess(), the required return value (ProcessInstance) I was aiming at is obtained earliest at the first wait state or termination of the process, right? Thanks so far! Best Markus -----Ursprüngliche Nachricht----- Von: Kris Verlaenen [mailto:kris.verlaenen@cs.kuleuven.be] Gesendet: Dienstag, 3. November 2009 16:11 An: Rules Users List; mardo Betreff: Re: [rules-users] Blocking Call to startProcess() Markus, You should not block the execution thread using long-running tasks (like sleep()) in actions, as this will actively lock the resources of the engine. You should use wait states, event nodes and/or work item nodes if you want to perform long-running tasks. Even when implementing a work item handler, the work performed there should either be quick and synchronous or performed asynchronously (acting as a wait state). As a result, startProcess() will block only until the process has reached a wait state, but this should almost be instantaneously (and if you don't have any asynchronous behaviour, this could already be the completion of your process). This allows concurrent execution of process instances if they contain asynchronous tasks (which is usually sufficient). You could also invoke the engine non-blocking (in a separate thread) if you want true concurrency. Kris Quoting mardo <mardo(a)abicola.de&gt;: Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm