Multiple instances of BPM service ?

[calvinchu101]

Hi,

I have a SOAP > BPM service created in SwitchYard and the BPM workflow invokes fine. However, I found that SwitchYard only allow one BPM instance running. (i.e. If I send multiple SOAP messages to my SwitchYard deployment, there are only one BPM workflow executed at a time. And other messages are pending.)

To show my problem  I created a void method as my service interface as I want the web service reply immediate without waiting for the service to complete. I have attached my sources and my service interface as below,

public interface HelloService {
     void sayHello(String helloString);
}

My SwitchYard xml as below,

<sca:composite xmlns:sca="http://docs.oasis-open.org/ns/opencsa/sca/200912" name="switchyard-example" targetNamespace="urn:com.example.switchyard:switchyard-example:0.0.1-SNAPSHOT">
    <sca:service name="HelloServicePortType" promote="HelloServiceBean/HelloService">
        <sca:interface.wsdl interface="META-INF/HelloService.wsdl#wsdl.porttype(HelloServicePortType)"/>
        <soap:binding.soap xmlns:soap="urn:switchyard-component-soap:config:1.0">
            <soap:contextMapper/>
            <soap:wsdl>META-INF/HelloService.wsdl</soap:wsdl>
            <soap:socketAddr>:18001</soap:socketAddr>
            <soap:contextPath>switchyard-example</soap:contextPath>
        </soap:binding.soap>
    </sca:service>
      
    <sca:component name="HelloServiceBean">
        <bean:implementation.bean xmlns:bean="urn:switchyard-component-bean:config:1.0" class="com.example.switchyard.switchyard_example.HelloServiceBean"/>
        <sca:service name="HelloService">
            <sca:interface.java interface="com.example.switchyard.switchyard_example.HelloService"/>
        </sca:service>
    </sca:component>
    <!-- 
    <sca:component name="HelloServiceBean">
        <bpm:implementation.bpm processDefinition="META-INF/HelloService.bpmn"
            processId="HelloService" messageContentInName="input"
            messageContentOutName="output">
            <bpm:taskHandler name="SwitchYard Service"
                class="org.switchyard.component.bpm.task.work.SwitchYardServiceTaskHandler" />
        </bpm:implementation.bpm>
        <sca:service name="HelloService">
            <sca:interface.java interface="com.example.switchyard.switchyard_example.HelloService"/>
        </sca:service>
    </sca:component>
    -->
</sca:composite>

I have a simple implementation to print start and end of the service, and a sleep to simulate my application logic,

@Service(HelloService.class)
public class HelloServiceBean implements HelloService {

    @Override
    public void sayHello(String helloString) {
        System.out.println("start: " + helloString);
        try {
            Thread.sleep(10000) ;
        } catch (InterruptedException e) {
            System.out.println(e) ;
        }
        
        System.out.println("Hello: " + helloString);
        System.out.println("end: " + helloString);        
    }

}

And it is the result when I make 3 concurrent call to my web service (helloString = 1,2 and 3 respectively), it shows that with Bean service implementation, requests are processed in parallel,

16:56:56,943 INFO  [stdout] (default-workqueue-1) start: 1

16:56:57,930 INFO  [stdout] (default-workqueue-2) start: 2

16:56:59,545 INFO  [stdout] (default-workqueue-3) start: 3

16:57:06,943 INFO  [stdout] (default-workqueue-1) Hello: 1

16:57:06,943 INFO  [stdout] (default-workqueue-1) end: 1

16:57:07,931 INFO  [stdout] (default-workqueue-2) Hello: 2

16:57:07,931 INFO  [stdout] (default-workqueue-2) end: 2

16:57:09,545 INFO  [stdout] (default-workqueue-3) Hello: 3

16:57:09,545 INFO  [stdout] (default-workqueue-3) end: 3

When I switch my implementation to META-INF/HelloService.bpmn (use Script task to print and sleep), I found that only one request is processed at a time.

16:58:39,896 INFO  [stdout] (default-workqueue-1) started:1

16:58:49,897 INFO  [stdout] (default-workqueue-1) Hello:1

16:58:49,897 INFO  [stdout] (default-workqueue-1) End :1

16:58:49,899 INFO  [stdout] (default-workqueue-2) started:2

16:58:59,899 INFO  [stdout] (default-workqueue-2) Hello:2

16:58:59,899 INFO  [stdout] (default-workqueue-2) End :2

16:58:59,900 INFO  [stdout] (default-workqueue-3) started:3

16:59:09,901 INFO  [stdout] (default-workqueue-3) Hello:3

16:59:09,901 INFO  [stdout] (default-workqueue-3) End :3

How can I configure SwitchYard to create a separate BPM instances per incoming request ? My business requirements involve tasks which take days to finish, having a single BPM instance is not practical in my case. Thank you very much!

[kcbabo]

I'm guessing this is due to the synchronous nature of the task itself - Thread.sleep() is going to block until the counter is exhausted.  Might be a good idea to have any long-lived interaction within a process execute asynchronously and signal the process when completed vs. blocking inside the process itself.  I can't say with certainty what the default behavior of jBPM 5 is, but I seem to remember that process execution for a given instance is both synchronous and serialized, which would produce this kind of behavior with tasks which take a long time to complete.  I also noticed we lock around process start inside our BPM component, which is going to serialize process execution as well.

[kcbabo]

Small clarification to my last statement.  You should be able to start multiple instances in parallel for a given process id, so it might just be the lock in our BPM component that is serializing the processing (each invocation of the process is synchronous, IIRC).  I'm sure David will chime in here shortly.

[dward]

I believe it is indeed the process lock in our BPM component.  I've filed a jira here: SWITCHYARD-1134.  Note: This is not going to change in 0.6.

Thanks for bringing this up, Calvin!  You can "watch" the jira above for notifications on it's progress.

[calvinchu101]

Thank's for your help. I am trying to use jBPM signal to get around this but I ran into other issues. I will post another thread to further discuss on it. Thanks again.