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.

Job Table Lines deleted When process reaches one of multiple ends

eransinger

Hello.
I'm trying to implement a mechanism that shows each activiti task and it's state (before running/ while/ after/ failed)
The failed activities are those which are active but has 0 retries.
I retrieve this information using management service -
managementService.createJobQuery().processInstanceId(<processInstanceId>).withException();

I tested it on several scenarios with parallel execution:
1.start-> parallel gateway ->two parallel scripts(good script and bad script)->end
2.start-> parallel gateway ->two parallel scripts (good script and bad script)->parallel gateway ->end
3.start-> parallel gateway ->two parallel scripts (good script and bad script)->each script reaches different end

The result is not what i expected:
scenario 2 is good (i can retrieve the failed jobs) but 1 and 3 shows no data in the job table.

according to the documentation process finishes when all executions reach the all ends.

The question is:
does any one have an explanation for that?
Is this an activiti bug?

Thanks.

Find more posts tagged with

Comments

vasile_dirla

Do you have a JUnit test for that ?
if so please upload it here.

eransinger

No. unfortunately no

trademak

Hi Eran,

At what moment are you executing the job query?
Did you check if the process instance was ended completely as well?

Best regards,

eransinger

I did some more testing:
After eliminating a lot of the factors i discovered what i think is a regression:
i'm wrote a basic process with start->parallel gateway-> two identical "hello world" script -> two ends
i'm deploying two different processes: one is a untouched and on the other i'm adding the parameter: activiti:async="true"
this parameter is absent when i create a process through the activiti-explorer, although i marked async as true on the gui.
The results are that the one with the async parameter get's stuck on one of the scripts. It's job is deleted from the table.
THIS HAPPENS on activiti 5.17.0 but not with activiti 5.12
So it looks like a regression.
Am I correct or is there some change I'm missing?

I'm attaching both processes - with and without the async parameter

async.bpmn20.xml_.txt.zip

noAsync.bpmn20.xml_.txt.zip

jbarrez

> The results are that the one with the async parameter get's stuck on one of the scripts. It's job is deleted from the table.

What do you mean with 'stuck'?

Are you sure the job executor is enabled? That Groovy is on the classpath?

eransinger

yes, JobExecutore is enabled and active.
groovy is not the issue - you can see if you try running the examples that both scripts are identical and without the "async" parameter scripts are working.
from what i see, when you try running the workflow with the "async" param- once one of the executions reaches an end task - all jobs that are related to the process are deleted (although process still exist).
it reproduces easily with the examples attached earlier

barkukesh

Indeed I could reproduce Eran's problem. It is quite easy to reproduce. Just deploy the async.bpmn20.xml_.txt (after you rename the file). Then start a new instance. You will see that both scripts indeed ended but from some reason the instance is not completed. Can you explain this?

jbarrez

The problem is that the job executor is 'too fast', both the scripts are executed and there is no check in the end event … from a threading point of view both happen 'at the same time'. Adding a parallelway gateway (with async=true to be sure) that joins resolves the problem.

barkukesh

Indeed I found out that adding the gateway solve the problem. But from BPMN perspective this is a definite bug. It is certainly legal to use two none end event (not terminate end event) and expect the process instance to complete. Should we report a bug?

trademak

Although the process definition is valid bpmn, the best practice is to always add a join parallel gateway. But I agree it should not happen. The priority of this issue is not high though, because it's not best practice BPMN.

Best regards,