M Arnold [
https://community.jboss.org/people/m_arnold123] created the discussion
"Re: jBPM5 - Can't Scale, Won't Scale"
To view the discussion, visit:
https://community.jboss.org/message/771858#771858
--------------------------------------------------------------
Thanks Mauricio.
I can't answer your 'why would you want...' questions because I don't want
any particular configuration of sessions and processes. I just want advice as to a
configuration of sessions and processes that will scale. Sorry if that wasn't clear.
2. When using BPMN2 events, jBPM5 only allows you to send events to the process instances
within a single session at a time. You need to maintain a list of all the sessions which
have incompleted process instances(*), and loop through them all to send events.
Therefore:
2a. you should execute all processes in as few sessions as possible, to lessen the number
of iterations through this loop.
*Or you can use a ESB or an lightweight integration framework to do that job like for
example apache camel or Switchyard.*
We happen to already be using Camel. But I'm not sure I understand how it would
help. Can you explain further?
If you mean that I should route the event to exactly the sessions that may be waiting for
that event, then that implies I must maintain a reference between all events that process
instances are waiting on and the session in which they are executing. This seems like
something jBPM should do. How would I get this information using jBPM5's API to allow
me to build such a thing?
3. jBPM5 persists BPMN2 timer info in the session info, but the session must be active
(ie. loaded from persistence) in order for the timers to activate. Therefore:
3a. when your application starts, you must load all sessions that have active process
instances that have timers(**).
*You can create a set of session with process that contains timers and a different set of
sessions with the rest of the processes. I have an alternative solution for this kind of
issues, which is to delegate those timers to an external component.*
Are you able to delegate timers to an external component and still use the BPMN2 timer
constructs? Can you please explain how? I would like to use the Java EE Timer service.
As it's persistent, it avoids the problems inherent in using jBPM5's timers
(removes assumption #3).
4. If you start a process instance in a session, that process instance must always be
executed in that session.
4a. when a node wishes to resume a process instance that was persisted, it must first (due
to 3b) ask all other nodes if they have the session active, and if so instruct them to
dispose it. It can then load the session, load and resume the process. All while
preventing race conditions.
*Why do you want to have the session in multiple nodes? you should think in a different
scheme where a retry mechanisms kicks in if something goes wrong. That retrying mechanisms
can be an external component that keeps track of the sessions and know where and how to
load them.*
I need to have the session active so that its timers expire. So the session must be
active in exactly one node.
We have a retry mechanism. It is incumbent on all jBPM5 users to have a retry mechanism
to deal with optimistic locking exceptions. I'm afraid I lack the imagination to see
how this would avoid the problem I outlined above. Can you please explain further?
It might be easier to present a specific use-case, rather than looking at the problem in
general terms. Suppose (use-case 1): application has a single process definition.
Process definition contains a BPMN2 receive task and a BPMN2 timer. I want to deploy this
on a cluster for high availability and horizontal scalability. How can I do this with
jBPM5?
All process have timers, so I can't use one set of sessions for processes with timers
and one set of sessions with for processes without. All sessions with one or more
incomplete process instances must be loaded from persistence for their timers to expire -
exactly once across the cluster. The incoming message for the BPMN2 receive task could
arrive at any node of the cluster. Therefore, when this occurs, the application must:
loop through all sessions that have incomplete process instances; instruct the node that
has that session loaded to dispose it; load the session; fire the event to the session.
When completed this process all sessions will be loaded on one node, so will need to
rebalance sessions. This obviously unworkable... can you suggest an alternative?
Some specific questions:
Is it possible through the jBPM5 API to know if a session has incompleted process
instances?
Is it possible through the jBPM5 API to know if a session has active timers?
You didn't say any of my assumptions 1-4 were wrong. Does that mean they were all
correct?
--------------------------------------------------------------
Reply to this message by going to Community
[
https://community.jboss.org/message/771858#771858]
Start a new discussion in jBPM at Community
[
https://community.jboss.org/choose-container!input.jspa?contentType=1&...]