andrew-regan
commented
7 years ago Capturing some comments from Slack related to this from @m4dcoder:
"in current implementation, there's a soft FIFO queue. on completion of the last action instance, if there's any delayed execution, st2 policy engine will look for the earliest delayed from the DB. but from the log entries, here's what i can deduce. there's already an instance of the action running at 2017-01-17 07:49:31 so 587dcc8bb4eaa909d5ce0ebf was put on delay. at 2017-01-17 07:49:41,413, the previous action execution already finished and while the policy engine is still getting ready, 587dcc94b4eaa909d8bcc212 was in the queue and scheduled. at 2017-01-17 07:49:41,708, 587dcc8bb4eaa909d5ce0ebf was evaluated again and it was cut in line by milliseconds..."
"there's a separate queue for actions being requested and those that are delayed atm."
bigmstone
LindsayHill
zsmanjot
nzlosh
I have an Action with a concurrency policy that only allows 1 instance of the Action to run at a time. We’re intermittently seeing cases where multiple triggers are dispatched that lead to this Action being invoked close to each other. Strangely the Actions are not being invoked in the order I’d expect. I was under the impression that there’s a FIFO queue that controls how Actions are dispatched to runners that would cause the Actions to run in order? The snippet bellow shows the logs for 2 executions of this Action. In the snippet you can see that the logs indicate 587dcc8bb4eaa909d5ce0ebf was requested first, but it eventually gets delayed and 587dcc94b4eaa909d8bcc212 gets dispatched to a runner first.
This is seen in 2.1.1.