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.

Best way to handle looping service tasks to avoid StackOverflowError

jdp

Hi,

I have a workflow as displayed in below link for a specific requirement :
Design : https://www.dropbox.com/s/t3k6tsmnanaziub/ServiceTaskLooping.png?dl=0
Definition : attached
Test Class : attached

here when 'status' is other than 1 or 2, workflow goes in infinite loop and throws a StackOverflowError ::

Caused by: java.lang.StackOverflowError
        at org.activiti.engine.impl.context.Context.getStack(Context.java:91)
        at org.activiti.engine.impl.context.Context.getProcessEngineConfiguration(Context.java:58)
        at org.activiti.engine.impl.el.JuelExpression.getValue(JuelExpression.java:45)
        at org.activiti.engine.impl.bpmn.behavior.ServiceTaskExpressionActivityBehavior.execute(ServiceTaskExpressionActivityBehavior.java:68)

Can anyone please suggest how to handle such scenario or which is the best way to handle this.

Thanks,
JDP

MyUnitTest_2.txt.zip

statusprocess.bpmn20.txt.zip

Find more posts tagged with

Comments

jdp

Hi,

As I am not able to edit the title of this post, please consider title as "which is the best way to handle looping service tasks to avoid StackOverflowError"

I have following options to avoid this problem :
1. Restrict service task input flow, every service task should have max one in flow.
2. Add executionCounter variable for each service task and if it reach at max limit, suspend/cancel workflow.

please suggest if these are the only valid solutions or there are other ways provided by activiti itself ?

Thanks,
JDP

jbarrez

This is a known problem in v5 and has been fixed in v6 (by fundamentally changing the exection algorithm)

A workaround is to make the stack size of the JVM larger.
A more code-wise solution is to split up processing of such iterations and add async points to make sure the process instance state is persisted in between.

jdp

Hi Joram,

Thanks for the reply. actually I want to restrict such workflow's infinite execution somehow.

Option one is, my app should validate such loops in workflow design and do not allow such workflows to be deployed. Is there any already available validation code through which I can add this type of validation or can find such loops in workflow design ?

Another option is point 2, I had mentioned in my above comment.

Please suggest.

Thanks,
JDP

martin_grofcik

Hi JDP,

if you use async task in the loop it should avoid stack overflow exception.

Regards
Martin

jdp

Hi Martin,

Appreciate your suggestion. As I had mentioned, I don’t want this type of workflows executes infinite times. I want to restrict such workflows to be deployed.

Is there any validation framework already available with which I can find and validate such loops in workflows and stop deployment of the same, if not, can you please suggest some approach to do the same ?

I am thinking to implement such validation by workflow paths traversal mechanism.

Thanks,
JDP

martin_grofcik

Hi JDP,

Is there any validation framework already available with which I can find and validate such loops in workflows and stop deployment of the same, if not, can you please suggest some approach to do the same ?

You can validate model before export from modeler (not enough - non validated model can fail again) http://activiti.org/userguide/index.html#_validating_diagrams_and_exporting_to_custom_output_formats

You can create your own deployer to check this condition. (somebody can change definition directly in the DB and make this loop)

Hook into the process definition parsing (http://activiti.org/userguide/index.html#_hooking_into_process_parsing) and do not allow such a definition to be parsed into memory

Regards
Martin

jdp

Hi Martin,

Thanks for the suggestion, it is really helpful. I will try to add my custom validator in same way.

Regards,
JDP