Boundary timer vs intermediate timer

1

I have a subprocess with a start event, call activity (A) and end event; A boundary timer event (Tparent) is attached to this subprocess with time set to 30minutes to interrupt activity.

Inside this call activity (A) there is a start event, service task B, exclusive gateway where if the expected output from B is received it will be connected to an end event and if its not we connect to a timer (Tchild) that waits for a minute and retries service task B and this goes on a loop.

Tchild is an intermediate timer event which is checked for Exclusive (it is an exclusive job)

What happens when the Tparent expires the same time Tchild is on the timer. Since both are exclusive jobs does the parent retry for 3 times when the Tchild is waiting on the timer and then goes to a dead letter queue table?

Question-2: For instance timer is set to expire at May 22 12:00:00 PM, but for some reason the job goes to dead letter queue and its past set time. Does the boundary timer job become ineffective and useless?

Question-3: Once any job is in dead letter queue table, how often does it retry or is stuck until we manually take a step to retry?

2

  1. If both jobs are exclusive, they will be executed one by one. If I understand the use case, this means that either the loop gets restarted or the boundary fires, or the other way around. In both cases this will lead to the correct behavior, no?

  2. No, the boundary timer job is independent from the. intermediate

  3. It needs to be moved programmatically through the API.

3

@joram Thanks for your reply. No, the child timer works everytime but the parent timer becomes ineffective. The reason for having parent timer is to cancel the activity if there is no update within 30mins but that’s not happening for few runs once in a while and the process goes on to an infinite loop.

4

Can you share a picture of your model(s)? Not sure I’m following yet.

When it is triggered first? Not sure I follow it yet - hopefully the model will help to explain the use case.