nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

BoundaryTimer sometimes not working

dokmatik

Activiti version is 5.10.

Hello everyone,

I have a strange issue which itches me lately.

Being unable to upload an appropriate image I will try to illustrate my issue with the following (primitive) drawing

|————|
receiveTask ————>[ex gateway]
|————|
[boundaryTimer]———–^

There is this receive task having a boundary timer attached to it.
The boundary timer itself is configured with a time duration = PT1S.
From both elements receiveTask and boundaryTimer outgoing flows lead to the same exlusive gateway.
(I know this is some workaround for the TimerCatching Event, but the time I started modeling the process the designer did not provide the TimerCatchingEvent).

In about 99% of my process instances this works without any flaws.
But from time to time somehow the execution flow stops at the [receiveTask] and does not continue. In ACT_RU_JOB I see a corresponding entry too but which has been updated in a manner when jobs are usually picked up by the engine giving the impression of proper continous execution.
Having looked in ACT_HI_ACTINST I find a corrsponding entry for the [receiveTask] activity with an exact time duration of 2 days. 2 days is exactly my timeout period I configured for the application. So after 2 days the job gets reiniatiaed and the execution flows as expected.

I have run out of ideas where to look to narrow down the cause of this problem ?
My latest suspicion is that I run into some kind of concurrency issue in a manner that updating the entry in ACT_RU_JOB and selecting for available jobs are not synchronized properly. But this may be a long shot.

So any hints are appreciated.

Thanks
dokmatik

Find more posts tagged with

Comments

frederikherema1

A bit more details needed:
- Does the boundary-event cancel the activity?
- Do you actually signal the receiveTask, before it goes wrong?

dokmatik

A bit more details needed:
- Does the boundary-event cancel the activity?
Yes, it does.
- Do you actually signal the receiveTask, before it goes wrong? -
Well, there is some probability a user has signalled the process instance via its frontend. But I havent found anything in my logs and could not find appropriate entries in ACT_HI_ACTINST for activities following [receiveTask] either indicating that the process instance has been continued.

jbarrez

What happens after the signal? Does the process ends? Are there automatic steps following?

dokmatik

After the receiveTask an exclusiveGateway follows as shown in the sketch.
The exGateway has 2 outgoing flows
- one which leads to more activities (but that path is not taken because of failing the given condition)
- second one leading to the process end event (no condition defined for this one)

Since the current instance is called from an outside CallActivity element we should return to the enclosing process instance finally leading to an end event.

Having had a look at my process model again I know realize that my aforementioned ex-gateway does not contain a "Default flow"-setting.
This actually used to be a problem with other exGateways of my process models. I had observed that without a "Default flow"-setting and having set a condition only on single outgoing flow only the instance mysteriously "stopped".
That could be here the case too.

I will fill in the "Default flow"-setting of the exlusive gateway and see what happens.

What do you say ?

jbarrez

It could be that it is indeed the case you need to use a default flow … but if it happens so rarely, it really shouldn't be the default 😉