|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-0600||Date Closed:|
|Versions:||1.8.4 13.18.4||Frequency of|
|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 18.104.22.168. 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 22.214.171.124
By: Vadim Mikhnevych (vmikhnevych) 2011-09-26 07:16:55.151-0500
I've applied the patch (app_queue_linear_17049) to 126.96.36.199 (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 188.8.131.52.
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 184.108.40.206
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
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.