Impact of Setting Priority on Queue and Driver
Consider the example of a flow with:
In this example, orders from the batch driver should be processed with a lower priority than those from the primary driver, and the resubmit queue should have a higher priority than any driver. (A Fulfillment Provisioning flow should generally give priority to outbound messages instead of accumulating messages inside the flow.)
Here is an example of what the flow controller configuration file should look like:
# First, the primary driver: # (note that we set the StopOnMemoryFreeing back to true here, this is # mandatory for drivers). # ElementName:MyDriverPrimary StopOnMemoryFreeing:true Priority:3 # Then, the batch driver: # (same remark, StopOnMemoryFreeing is set back to true) # ElementName:MyBatchDriver StopOnMemoryFreeing:true Priority:1 # Finally, the resubmit queue: # ElementName:MyResubmitQueue Priority:5
When the flow controller is able to inject a new message into the flow, this configuration ensures that messages are dequeued in this order:
...if all three have pending service orders ready to inject into the flow.
Moreover, the flow controller has an anti-starvation system: elements that have pending service orders to process are put inside a sorted list, based on priority and time of arrival. The attribute FlowController::m_priorityWeight controls the weight of priority of an element against its time of arrival inside the flow controller's sorted list of elements, allowing low priority elements to get pumped as well after some time.
Also note that for each pumped service order, the time of arrival inside the sorted list of the flow controller is reset.