I have some questions about performance aspect of BPEL processes running on the jbpm engine.
For background infos: I'm analysing performance prediction of business processes with the jbpm engine. I have found out a mathematical model to
compute and predicte the process execution time that i can apply on the Messanging service of jbpm (I'm using jBPM as orchestration engine for BPEL process).
But i still have doubts if i have understand well how the JMS service works in the jbpm context.
The purpose of this mathematical model is to be able to predict the execution time of runnning process instances depending on the arrival rate
of messages in the Process queues(destination) and depending on how much messages are already in the queue.
But i'm not sure if this approach can be applied wiht the jpbm Messaging service.
Please correct me if i'm wrong:
As soon as the business process run as web service on the jbpm-Engine, clients can connect to the Service by sending SOAP Messages to the
service endpoint. With the JMS API a JMS Session is opened and The soap message is transformed in JMS message and sended to the processqueue.
After processing the request the process instance sends the answer back to the queue attached to the client as JMS Response. The JMS response is
transformed back to SOAP Message and the client becomes the soap response.
I'm a little bit confused hier with clients requests. Each client request generate a JMS new Session right? It may be possible that in one jms session
more soap messages are sended.
Is it true that each client request gererates its own JMS Session? If we have k-clients accessing the service there will be k-destinations(Queues)
generated wright? In this case the message processing time is constant but little bit variable due to the overhead of the jms service
(creating and converting SOAP Messages in JMS messages and managing this). If enought ressource is avialable on the machine how big is the inpact
on performance of maintining k-connnections on the Engine.
I'll appreciate your help in my investigation and any recommendation.
Thanks in advance
I'll gladly give as much detail as I can, provided you publish the results of your investigation. Is that fair?
Each client request creates a separate JMS session, yet they share a single connection per BPEL process. I am unfamiliar with the JBossMQ implementation details, but the JMS spec suggests the JMS connection encapsulates an open socket and sessions take turns to use the transport. Therefore, the impact of mantaining k-sessions is constant in resources (1 socket) and linear in time (k sessions trying to use the transport simultaneously). In practice, even tough you have k active sessions, only a fraction of them will be contending to use the transport. Some of them will be busy preparing the message or waiting for a response.
In a jBPM BPEL process, message producers and consumers coexist in the web application where the web services are deployed. Hence, there is no reason for using a socket-based invocation layer. By using the in-JVM layer, sessions do not take turns to use the transport; they deposit messages on the queues directly.
When you use a single queue, there will be significant overhead in filtering the messages. jBPM BPEL allows for assigning a separate queue to each partner link in order to alleviate the filtering load.
Hope this helps.
Hallo community, hi Alex,
i'm back once again. First thanks a lot for your contribuation and explainations. Its help a lot.
Now i still have questions about the implementation details of the jBPM BPEL extention. May be you or someone else in the forum can help me answering this important question.
So what i need to know concerns the number off process instances running on a BPEL Engines in generall and particulary the jBPM engine:
1) - Is there always one process instance running on a bpel engine (generally) when client requests are being processed? This means if i have k-client requests only one process instance processes all incomming requests for those clients or this fact depends on the implementation details of each bpel engine
2) - how this fact is implemented in the jBPM engine? Is there only one process instance processing all client requests or the jPBM engine can have more instances of a BPEL process processing incomming requests.
Please is there some one who can help me answering the above questions. Any documentation or engine Source code reference will help a lot in my investigation.
Thanks in advance once again.
1) Well, as you know, endpoints backed by a BPEL process are stateful. In general, you will have a process instance per request, unless two or more requests correlate to the same process instance. In this case these requests will execute the same instance.
This is a consequence of the design of the BPEL language. You can expect performance similar to stateful session beans in the EJB domain.
2) In jBPM, a process instance is composed of one or more tokens. Each token represents a path of execution. Initially, a process instance contains a single token which represents the main path. When the process logic encounters an activity with more than one path of execution (the flow activity, a scope with event handlers, etc) the engine spaws one token per path.
jBPM runs these paths serially to avoid starting new threads because this is forbidden in a Java EE environment. This might look bad, but in practice it is not: jBPM stops executing a path of execution when it encounters a blocking activity (these include inbound message and time-driven activities).
When jBPM stops executing a path, a separate server thread must resume the execution of that path. This is where JMS is critical to the BPEL runtime: it allows for executing more than one path of the same process instance in parallel, while fully adhering to Java EE guidelines.
To illustrate, consider the following example:
<sequence> <receive name="a" createInstance="yes"/> <flow> <sequence name="b"> <invoke name="b1"/> <receive name="b2"/> </sequence> <sequence name="c"> <assign name="c1 /> <receive name="c2" /> </sequence> </flow> <reply name="d"/> </sequence>
The order of execution is:
a, b1, c1
Note that d executes in either thread-2 or thread-3 depending on what request arrives first, b2 or c2
1000 times thanks Alex for your contribution - . This make more than one thinks clear for me.