8 Replies Latest reply on Jul 11, 2012 9:10 AM by r3vans

Resuming processes revisited

r3vans Jun 29, 2012 10:48 AM

Firstly apologies for creating a new thread on an oft-discussed topic. This is partly because I want to make sure I get up-to-date info and partly because there is a new question in here.

JBPM 5.3

I have a number of processes with 100% async service handlers. Many of the processes have handlers that poll a back-end for data, driven by a timer (delay=30s).

I am trying to resume after halt. By default I use a kSession created in in a spring context using the <drools:> namespace. As the config is fairly complex I use this to help me restore the session as follows. If I restore the session, I don't use the default session

kSession = JPAKnowledgeService.loadStatefulKnowledgeSession(id,

kSession.getKnowledgeBase(),

kSession.getSessionConfiguration(),

kSession.getEnvironment());

//?kSession.signalEvent("Trigger", null); //Seen this in one post?

Q1. Is there any reason I should NOT initialise from a prev ksession like this? I don’t want to have to create env and config in code as well as spring config

Q2. Should processes resume without further action (they don’t, even if not timers)

Q3. Should timers resume in 5.3? I know that this has been a subject of hot debate in the past.

Q4. If not, any suggestions on how to

- EITHER resume processes stuck on timers
- OR implement polling without timers (e.g. halt processes awaiting an a signal from an externally scheduled call to kSession.signalEvent())

Thanks in anticipation.

1. Re: Resuming processes revisited

salaboy21 Jun 29, 2012 11:02 AM (in response to r3vans)

Hi Richard,
A1: it looks ok, are you having any trouble with that?

A2: the process will not be automatically resumed.. unless you keep the session alive

A3: I'm not up to date with those discussions, but I can imagine how to create the mechanisms for "long running timers"

A4: a) you can use an external quarts which a handler that load the session and do something with it, b) same as 'a', I think that you get it right, just get an external source
that notifies you when the timer is due and reload the session and some something like signal an event or insert a fact.

Cheers
Actions
2. Re: Resuming processes revisited

r3vans Jun 29, 2012 6:54 PM (in response to salaboy21)

Hello Mauricio,
A1+ Only that processes are not resumed
A2+ What does "keep the session alive" mean? My scenario is: loads of processes running fine, tin fails, restart on new tin some time later, start container, loadStatefulKnowledgeSession..... then what?
A3 & 4+ I'll look further into these. The quartz (or equivant) is not my problem. I'm a learner on jbpm so don't know I can a) stop a process to wait signal and then b) handle a signal to move on to next state & resume the process.
Actions
3. Re: Resuming processes revisited

swiderski.maciej Jul 2, 2012 9:03 AM (in response to r3vans)

Regarding alternative approach to timers - why not utilize intermediate signal catch events? That is kind of wait state until some external trigger will move it further - using ksession.signalEvent....

HTH
Actions
4. Re: Resuming processes revisited

r3vans Jul 4, 2012 12:51 PM (in response to swiderski.maciej)

Hello again. Thanks for your reply. Sorry I was drawn into something else for a couple of days...

Let me try to understand. I understand how I can have something in my process that fields a signal. I am not sure how I get that to move my process forward only if it is in certain places in the flow (where I used to have the timers.

Consider a flow like this:

[Call external API1 SR] ==> (timer1) ==> [Get API1Response] ==>[Call extenal API2] ==> (timer2) ==> [Get API2Response] ==> (END)

If the timers don't trigger when I resume the session, can I replace this with something like ...

[Call external API1 SR] ==> (SignalHandler) ==> [Get API1Response] ==>[Call extenal API2] ==> (SignalHandler) ==> [Get API2Response] ==> (END)

... and have an external signal generator that will cause any (SignalHandler) node to resume execution at the next step? I have lots of processes with many timers so I'd not want to have a separate signal to replace each timer in each process. I obviously don't want the signal to divert the line of execution unless it was at the handler.

Regards,
Richard
Actions
5. Re: Resuming processes revisited

swiderski.maciej Jul 4, 2012 1:43 PM (in response to r3vans)

Yes, you can do what you described with signal events and in my opinion it is more suitable than timers. In fact both timer and signal are events (in your case intermediate catch events) so only event definition needs to change.

Signals have types (signalRef in bpmn2) that is used to distinguish between different signals so you could have different types for given places in your process. You can also pass data when signaling so it could be an alternative for you to send back the response from external api if you signal generator will have it. You can either signal via session which will signal all process instances that awaits given type of signal or signal dedicated process instance.

HTH
Actions
6. Re: Resuming processes revisited

r3vans Jul 10, 2012 2:08 PM (in response to swiderski.maciej)

Me again.
I was really looking forward to picking this up again but .... not good news. My external timer events are not getting handled.

I am still digging but I thought I'd float the problem in case anyone can volunteer advice.

The first time I call kSession.signalEvent I see

- DefaultSignalManager.addEventListener is called OK
- DefaultSignalManager.removeEventListener is called before
- DefaultSignalManager.internalSignalEvent is gets called but by then no registered listeners
- DefaultSignalManager.removeEventListener is called some more

All of this is down below kSession.signalEvent. When removeEventListener is called, the stack tells me that this is inside a commit. I have NO transaction runningw when I call kSession.signalEvent.

The second time I see no addEventListeners calls.

Any ideas?
Thanks for your continuing help.

Richard
Actions
7. Re: Resuming processes revisited

swiderski.maciej Jul 11, 2012 7:14 AM (in response to r3vans)

I am not sure I follow you on what you're trying to do now. Do you use timers and then would like to trigger them manually? If so, that is not what I had in mind. I suggested to use signal event definitions )with corresponding type) instead of timers. Then as soon as you enter the signal node events will be registered.

In addition what could simplify discussion here is to have an example (process) with test case if possible.

HTH
Actions
8. Re: Resuming processes revisited

r3vans Jul 11, 2012 9:10 AM (in response to swiderski.maciej)

I am generating events periodically. Sorry for the bad choice of terms. Every so oftern I call kSession.signalEvent ("xxx", null).

The process looks like this.

[Call external API1 SR] ==> (SignalEvent) ==> [Get API1Response] ==>[Call extenal API2] ==> (SignalEvent) ==> [Get API2Response] ==> (END)

Interestingly I have found that the code works if I enumerate the process instances and iterate around calling kSession.signalEvent ("xxx", null, processInstanceId).

(Yep - if I get stuck again I will abstract a but of code.)

Richard
Actions

Go to original post