Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(engine): non-recursive execution of BPMN Activities #171

Closed
wants to merge 1 commit into from

Conversation

@meyerdan
Copy link
Member

meyerdan commented Aug 22, 2015

Before this commit atomic operations were executed recursively.
This caused the problem that if a BPMN process had many activities
that were executed sequentially, the stack grew very large until the
execution failed with a StackOverflowException.

This commit changes that behavior. It introduces an operation loop
and list of queued operations in the CommandContext.

Implementation Considerations:

  • The implementation tries to change the execution oder as little as
    possible: concurrency is still depth-first, operations are executed
    in the same order as before as much as possible. This way, users
    are affected by this internal change as little as possible.
  • This also means that not all atomic operations are executed
    using the loop: a majority of the operations are executed
    recursively but without growing the stack. Inuitively, operations
    "within" a given activity are executed recursively but the
    recursion is broken after the activity.
  • This fixes the problem with as little impact on user code as
    possible.

fixes #CAM-4172

@meyerdan meyerdan force-pushed the CAM-4172 branch from dcc43e1 to 7cfa956 Aug 22, 2015
@buildhive

This comment has been minimized.

@buildhive

This comment has been minimized.

@meyerdan meyerdan force-pushed the CAM-4172 branch from 7cfa956 to 5283e1b Aug 23, 2015
@buildhive

This comment has been minimized.

Before this commit atomic operations were executed recursively.
This caused the problem that if a BPMN process had many activities
that were executed sequentially, the stack grew very large until the
execution failed with a StackOverflowException.

This commit changes that behavior. It introduces an operation loop
and list of queued operations in the CommandContext.

Implementation Considerations:
- The implementation tries to change the execution oder as little as
  possible: concurrency is still depth-first, operations are executed
  in the same order as before as much as possible. This way, users
  are affected by this internal change as little as possible.

- This also means that not all atomic operations are executed
  using the loop: a majority of the operations are executed
  recursively but without growing the stack. Inuitively, operations
  "within" a given activity are executed recursively but the
  recursion is broken after the activity.

- This fixes the problem with as little impact on user code as
  possible.

fixes #CAM-4172
@meyerdan meyerdan force-pushed the CAM-4172 branch from 5283e1b to f0fb514 Aug 30, 2015
@buildhive

This comment has been minimized.

Copy link

buildhive commented Aug 30, 2015

camunda BPM » camunda-bpm-platform #1637 UNSTABLE
Looks like there's a problem with this pull request
(what's this?)

@meyerdan meyerdan closed this Sep 29, 2015
@meyerdan

This comment has been minimized.

Copy link
Member Author

meyerdan commented Sep 29, 2015

merged with c6f4e19

@hawky-4s- hawky-4s- deleted the CAM-4172 branch May 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.