Activiti

StackOverflowError with large MultiInstance

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Won't Fix
  • Affects Version/s: 5.9
  • Fix Version/s: None
  • Component/s: Engine
  • Labels:
    None
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

Attached Testcase fails with a StackOverflowError.
It consists solely of a Task (here a ScriptTask doing nothing) that is MultiInstance with a large cardinality.

It seems that BPMN Activities are interpreted recursively instead of sequencially.

I've also attached a possible solution (see class CustomCommandContext as a replacement for CommandContext), but I don't know if that implementation might have implications I'm not aware of (asynchronous continuation, transactions, etc).

Issue Links

duplicates

Bug - A problem which impairs or prevents the functions of the product. ACT-685 Executing processes can cause StackOverflows

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Bernd Ruecker (camunda) added a comment -

Hi Florian.

What is the real life use case for this? Would be good to know.

Cheers
Bernd

Show
Bernd Ruecker (camunda) added a comment - Hi Florian. What is the real life use case for this? Would be good to know. Cheers Bernd
Hide
Permalink
saeid mirzaei added a comment -

Hi
Just to mention, in my computer limit is something around 250.
I think also, this might be a serious limitation, for example in batch processing scenarios

Show
saeid mirzaei added a comment - Hi Just to mention, in my computer limit is something around 250. I think also, this might be a serious limitation, for example in batch processing scenarios
Hide
Permalink
Bernd Ruecker (camunda) added a comment -

Still waiting for the real life use case. We know of the limitation due to the call stack bat never tackled a real life problem where it caused serious trouble and no workaround existed (e.g. introducing asynchronous continuation, see https://app.camunda.com/confluence/display/foxUserGuide/Thread+and+Transaction+Management#ThreadandTransactionManagement-AsynchronousContinuation).
So I tend to close this case with "won't fix"

Show
Bernd Ruecker (camunda) added a comment - Still waiting for the real life use case. We know of the limitation due to the call stack bat never tackled a real life problem where it caused serious trouble and no workaround existed (e.g. introducing asynchronous continuation, see https://app.camunda.com/confluence/display/foxUserGuide/Thread+and+Transaction+Management#ThreadandTransactionManagement-AsynchronousContinuation ). So I tend to close this case with "won't fix"
Hide
Permalink
Daniel Meyer (camunda) added a comment -

This is usually not a problem. Use activiti:async="true", as Bernd suggests.

We could try changing this, this would require some serious hacking in the core engine, however. I am reluctant about changing it now since it is usually not a problem, also not in batch processes.

Show
Daniel Meyer (camunda) added a comment - This is usually not a problem. Use activiti:async="true", as Bernd suggests. We could try changing this, this would require some serious hacking in the core engine, however. I am reluctant about changing it now since it is usually not a problem, also not in batch processes.
Hide
Permalink
Daniel Meyer (camunda) added a comment -

I am closing this with won't fix since it is a duplicate of ACT-685 and we closed that as well.

Show
Daniel Meyer (camunda) added a comment - I am closing this with won't fix since it is a duplicate of ACT-685 and we closed that as well.
Hide
Permalink
Florian Lieb added a comment -

The real-life scenario was the processing of a List of objects with about 1000 entries in a B2B scenario. This couldn't be done async because the transaction boundary was critical.
I stripped down to the process so that the problem gets obvious.
Unfortunatelly i don't have the original process anymore, we switched to another solution.

Show
Florian Lieb added a comment - The real-life scenario was the processing of a List of objects with about 1000 entries in a B2B scenario. This couldn't be done async because the transaction boundary was critical. I stripped down to the process so that the problem gets obvious. Unfortunatelly i don't have the original process anymore, we switched to another solution.
Hide
Permalink
Robert McKinnon added a comment -

This should be reopened and fixed. We just got burnt with this because we had 50+ instances in a multi-instance process.

Show
Robert McKinnon added a comment - This should be reopened and fixed. We just got burnt with this because we had 50+ instances in a multi-instance process.

People

  • Assignee:
    Unassigned
    Reporter:
    Florian Lieb
Vote (1)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved: