Summary:ASTERISK-17049: [patch] Setting linear queue strategy requires asterisk restart
Reporter:Vadim Mikhnevych (vmikhnevych)Labels:patch
Date Opened:2010-12-01 06:15:31.000-0600Date Closed:
Versions:1.8.4 13.18.4 Frequency of
is duplicated byASTERISK-22864 Queue agent order when changing to linear strategy not correct on reload
is duplicated byASTERISK-30410 Queues doesn't load members according to the configuration files
Environment:Attachments:( 0) app_queue_linear_v2.patch
( 1) linear_rrordered_update_11.21.patch
( 2) linear_update_11.5.patch
Description:According to app_queue.c sources, this message occurs only for realtime. And, actually, one can't see this message if queue strategy was changed in queues.conf.
But, after altering queues config file and invoking either "config reload /etc/asterisk/queues.conf" or "queues reload all", members order in queue is not the same as in .conf file, and incoming calls are routed to queue members also in wrong order.
PS If used strategy is set to "linear" and asterisk is restarted, order of members in queue and config file is the same, and the bug doesn't reproduce.

Of course, adding a message "Please, restart asterisk" for static configuration reload wouldn't be a best solution. I'd prefer not to restart asterisk at all.
Comments:By: Filip Jenicek (phill) 2011-07-20 08:34:08.842-0500

I can confirm the behaviour on Asterisk It's pretty annoying.

By: Filip Jenicek (phill) 2011-07-21 02:19:41.412-0500

This patch converts the ao2 container to a linear one.

Fixes the described issue when "module reload" is executed.

By: Vadim Mikhnevych (vmikhnevych) 2011-09-26 06:12:47.739-0500

Still exists in

By: Vadim Mikhnevych (vmikhnevych) 2011-09-26 07:16:55.151-0500

I've applied the patch (app_queue_linear_17049) to (adjusting line numbers according to the code), and it seems to fix the issue.

By: Gregory Hinton Nietsky (irroot) 2011-11-09 06:32:22.067-0600

There are valid reasons for this as it requires destroying and recreating the queue container
this is not ideal there is a way i could do this safely now without impacting the running

im busy working on the Queue application at the momment and will take this into account.

By: Vlad Povorozniuc (vpp) 2011-11-14 11:59:30.510-0600

I have seen this behavior in asterisk-10 r344216

By: Etienne Lessard (hexanol) 2012-05-15 10:26:32.327-0500

We are also affected by this issue on our asterisk

By: Mark Petersen (roadkill) 2012-05-16 07:46:16.212-0500

Hi Filip can you sign the Licens agreement
as we can not use the patch until it is signed

By: Filip Jenicek (phill) 2012-09-10 03:22:24.447-0500

updated app_queue patch, should work with

By: JoshE (n8ideas) 2013-08-11 17:14:50.219-0500

I have updated this patch for Asterisk 11.5.  Haven't fully tested all scenarios, but seems to resolve the issue as far as I can see.

File is attached.

By: Diego Kappa (dcapape) 2015-03-04 09:41:40.853-0600

Created: 01/Dec/10 6:15 AM and it still opened?

Of course you can't say this is a bug because of the weak restart log message, but I really think this must be solved.
At least you can edit to allow to use a FLAG on compiling time to choose between all these free memory you get when you don't keep the order, or keep order and change strategies without restarts

Is anyone following this thread?

I love who made the patch, but I'm really interested to make official this patch.
I'm using Asterisk 13 and it still the same issue

By: Robert Mordec (veilen) 2016-03-11 02:48:37.569-0600

It seems rrordered queue strategy uses queuepos field and not the ao2 container order to determine who to call next. Since the linear_update_11.5.patch fixes only the ao2 container I updated it with a simple fix.

File linear_rrordered_update_11.21.patch contains both mine and previous modifications.

By: Lev Borodin (faunris) 2016-06-26 21:38:47.931-0500

Hmm, recreate container in init_queue is very bad idea for realtime queue, i think. Because asterisk call init_queue every 0.5 s.

By: wushumasters (wushumasters) 2017-01-24 17:39:47.917-0600

I use asterisk 13 and have same problem


By: Luke Escude (lukeescude) 2017-05-25 14:22:00.036-0500


By: Luke Escude (lukeescude) 2018-04-20 14:52:56.906-0500

Double bump.

This issue is still present in 15.3, 14.6, and 13+

By: Juan Martin (jmartin) 2019-07-03 04:42:12.595-0500

It's still present on 16.4.0

By: David Brillert (aragon) 2020-10-22 08:49:28.114-0500

I see there is a patch. Patches should be submitted to https://gerrit.asterisk.org/q/status:open for review

By: Yury Kirsanov (lt_flash) 2021-03-11 07:08:14.398-0600

This is still an issue with all recent versions of Asterisk, we will try to deploy patch for Asterisk 16, 17 and 18 and I will report here if it helps.

By: Yury Kirsanov (lt_flash) 2021-03-21 14:35:22.479-0500

This far patch works fine for us, when we do changes to configuration files they're reflected in the actual queue. Notices from this patch are a bit confusing as they're saying 'Moving DYNAMIC members of the queue' while we're using only static members, like SIP devices, not Agents who can log in/out to/from the queue. Also we're still testing this as usually for some reason this incorrect behaviour was appearing not immediately after restart but a week or even more later. Asterisk used is 16.15.0. Thanks.