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())

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.

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....

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.

... 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.

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.

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.