Just confirming if this behavior is by design/desired.
When a static member queue is created, the rrordered strategy works great. However, if you create a queue with ringall then switch it to rrordered and then “reload queue all”, the order is not honored.
If you switch the order of the members after changing the strategy, the member does move in the list (queue show whateverq) but the list does not reflect what’s in the config file.
Only removing the queue, then “reload queue all”, then recreating the queue starting with “rrordered”, and “reload queue all” again, everything falls into place and you can modify the order and it honors the configuration file on subsequent reloads and subsequent changes.
So Asterisk appears to be holding on to something from the original ringall strategy.
I noted that when using ringall the members are always appear in the queue backwards from queues.conf.
Looking for advice, confirmation, or my 3rd cup of coffee
I tested with callers in the queue and when I remove the queue the caller still stayed in the now non-existent queue and still continued as expected based on the removed queue’s settings.
When the queue is recreated, the caller isn’t in the queue, which makes sense.
Curious, is this safe behavior? To remove a queue while there are active callers still in the queue?
It’s a long time since I looked at the implementation in details and it is possible the introduction of stasis has changed this but where there might be a risk is in the logic that attempts to decide whether an agent is really available. If this goes wrong, it can result in a low weight queue stealing agents from a high weight one, but not cause a fatal problem.
I can’t remember now how the potentially conflicting high weight queues were found. If there was a link through the agent, there shouldn’t be a problem, but if iterates over the whole set of queues, it would only find queues that hadn’t been removed, as I assume removal results in the removal from the master list of queues, whilst leaving the queue structure still linked to members and to and from callers.
Wnat happened was that the queue application looked to see if a higher weight queue shared the same agent, and if it did, it would only allow the low weight queue to use the agent, if the high weight one had enough available agents to cover all the entries in that queue, (Queue logic is funny because callers try to find an agent, rather than agents trying to find a call, so an agent can become free with more than one call that they could take, but won’t take that all immediately. You have to weight for one of the calls to poll for an agent. The first one to do so might not be the one that properly respects the weighting system.)
