Concurrent steps
The concurrent step is used to run parts of your Gloop code in separate threads. It behaves
differently depending on whether your service is being debugged
and whether the Asynchronous
property of the step is true
or false
.
When Gloop is debugging a service, nothing happens concurrently. This is to make debugging services easier.
When Gloop is running (not debugging) and Asynchronous
is false
, then all children of the
step will run in separate threads, but the concurrent step will wait for all of its children to complete. This is
particularly useful if you have some long running parts in your code. A good example of this is an integration which
needs to make multiple HTTP or database calls. By putting them together under a concurrent step, they can all run at the
same time, and Gloop will continue once they're all done. Output variables from the steps that are run concurrently in
this mode are accessible in steps after the concurrent step (since the concurrent step waits for them all to complete).
The last exception that is thrown (if any are thrown at all) in any of the children will be caught, and the concurrent
step will re-throw it.
In the example code above, Gloop will execute lines 4-7 in separate threads, and then continue to line 8 after all the steps in lines 4-7 have completed.
When Gloop is running (not debugging) and Asynchronous
is true
, then all children of the step will run in sequence
in a separate thread, and the concurrent step will not wait for all of its children to complete. Outputs from the
children of the concurrent step cannot be used (since Gloop doesn't wait for them to complete). Exceptions that are
thrown by any of the children of the concurrent step are logged, but not thrown.
In the example code above, Gloop will execute lines 4-7 in a separate thread, and then continue to line 8 instantly.
Asynchronous badge icon
When a concurrent step has an Asynchronous
value of true
, the icon will have a small green thread badge.