3 Replies Latest reply on Jan 22, 2008 3:35 AM by soumya_in

Strange Asynchronous Behaviour of JBPM(3.2.2)

soumya_in Jan 18, 2008 7:06 AM

Hi all,
I have deployed the jbpm-enterprise.ear into my existing jpm-jpdl-suite 3.2.2.The ear got successfully deployed.
However when I am trying to achieve asynchronous execution by declaring one node as asynch="true" which I tried with the following code:

<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="synch-process">
 <start-state name="start-state1">
 <task name="task-1"></task>
 <transition to="node1"></transition>
 </start-state>
 <node name="node1" async="true">
 <action name="action-1" class="CustomerActionHandler1"></action>
 <transition to="node2"></transition>
 </node>
 <node name="node2">
 <action name="actio-2" class="CustomActionHandler2"></action>
 <transition to="end-state1"></transition>
 </node>
 <end-state name="end-state1"></end-state>
</process-definition>

I turned on SOPs in the following classes :-JmsMessageServiceImpl.java,JobListenerBean.java,ExecuteJobCommand.java,CommandServiceBean.java,CommandListenerBean.java and redployed the ear.
The classes generated the SOPs properly stating the job message was dumped into the jbpm job queue and command was executed from the command service bean:
Following is the trace-

17:27:45,053 INFO [STDOUT] ****************Connection***************org.jboss.resource.adapter.jms.JmsSessionFactoryImpl@1bbf341
17:27:45,053 INFO [STDOUT] ****************Session***************org.jboss.resource.adapter.jms.JmsSession@1680bc6
17:27:45,053 INFO [STDOUT] ****************Destination***************QUEUE.JbpmJobQueue
17:27:45,069 INFO [STDOUT] **********************JOB Session*******************org.jbpm.db.JobSession@25997c
17:27:45,085 INFO [STDOUT] **********************JOB ID*******************3884
17:27:45,085 INFO [STDOUT] ****************Message sent successfully to QUEUE.JbpmJobQueue
17:27:45,225 INFO [STDOUT] ^^^^^^^^^^^^^^^^^JOB LISTENER BEAN IS CALLED^^^^^^^^^^^^^^
17:27:45,225 INFO [STDOUT] getting job id from jms message...
17:27:45,225 INFO [STDOUT] retrieved jobId '3884' via jms message
17:27:45,225 INFO [STDOUT] looking up local command service
17:27:45,240 INFO [STDOUT] executing command with local command service
17:27:45,349 INFO [STDOUT] Action class of asynch node is executed
17:27:45,381 INFO [STDOUT] Action class of synchronous node is called
.
However in the action class attached with the asynch node I had to write the following code snippet so that the process continued to the next node:-

executionContext.getNode().leave(executionContext);

1. Re: Strange Asynchronous Behaviour of JBPM(3.2.2)

soumya_in Jan 18, 2008 7:07 AM (in response to soumya_in)

In connection to my previuos post.
Now my point is that if at all the command had reached to the asynch node then why do i have to add the leave code in my action class explicitly?
If I don't add this code to the one with aynch=true then any other new project with a synchronous node goes blocking.
Why is this strange behaviour?
Please advice.
Thanks,
Actions
2. Re: Strange Asynchronous Behaviour of JBPM(3.2.2)

kukeltje Jan 21, 2008 8:05 AM (in response to soumya_in)

What I make from your posts:

If you have an async node without an actionhandler that explicitly make it leave the specific node, all sync nodes go blocking.

Correct?
Actions
3. Re: Strange Asynchronous Behaviour of JBPM(3.2.2)

soumya_in Jan 22, 2008 3:35 AM (in response to soumya_in)

Yes...Asynchronous means a non-blocking.I have a requirement like this. e.g. CreditValidation.My main process validate a credit card no which will be validated in a subprocess.At that point customer registration will be done in the main process.Now at all a customer entered a wrong credit card no i.e. irrelevant to the customer registration process.Untill or unless a customer purchase for something,useful credit validation is not required.Now the scenario is looking bit difficult.Since to invoke a subprocess within a main process I used a process-state and made it asynch="true".

Now the two scenario is possible
1) I will use executionContext.getNode().leave(executionContext);
If I do this subprocess will not be invoked.Token traverses to the next activity of the main process.

2)If i do not do this all previous activities before process-state go blocking
Actions

Go to original post