Queue instruction – run an activity asynchronously
The Queue instruction uses a Java thread from a limited thread pool. If using the
queue instruction, set the agent/threadpoolsize value in the
file or dynamic system settings appropriately based on concurrency needs.
Use the Queue instruction:
- To start asynchronous execution of a second activity. The Queue instruction provides an alternative to the Call instruction, in situations where there is no need to wait for completion of the second activity, or where processing in parallel is feasible and beneficial.
- Only when appropriate, where the queued activity can operate in a "fire-and-forget" style.
Do not use the Queue instruction:
If you have disabled batch requestor processing by setting the agent/threadpoolsize value to 0 in the
prconfig.xmlfile or dynamic system settings.
- If parallel execution of the activity may introduce locking issues, deadlocks, race conditions or other concurrency risks into your application. Use the Call instruction instead.
- To allow a background agent, operating as a separate process, to execute an activity asynchronously from the foreground processing, especially when locking is involved. Use the Queue-for-Agent instruction instead.
Refer to Parameters for the Queue instruction for information about the activity parameters you can set for the Queue instruction.
At runtime, the system uses rule resolution to locate and start the activity.
The activity does not receive a step page or a primary page.
Execution of the queued activity occurs asynchronously, in a batch requestor. The execution progress of the two activities is not predictable and may vary from execution to execution.
Checking the method status
This method updates the pxMethodStatus property only if it fails. See How to test method results using a transition.
Previous topic Use of Java in an activity step Next topic Connect-Cassandra method