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:
Priority:	Minor	Regression?	No
Status:	Open/New	Components:	Applications/app_queue
Versions:	1.8.4 13.18.4	Frequency of Occurrence	Frequent
Related Issues:	is duplicated by ASTERISK-22864 Queue agent order when changing to linear strategy not correct on reload is duplicated by ASTERISK-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 1.8.4.3. 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 1.8.7.0 By: Vadim Mikhnevych (vmikhnevych) 2011-09-26 07:16:55.151-0500 I've applied the patch (app_queue_linear_17049) to 1.8.7.0 (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 queues. 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 1.8.12.0. 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 https://issues.asterisk.org/jira/secure/DigiumLicense.jspa By: Filip Jenicek (phill) 2012-09-10 03:22:24.447-0500 updated app_queue patch, should work with 1.8.11.1 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 @veilen 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 Thanks By: Luke Escude (lukeescude) 2017-05-25 14:22:00.036-0500 Bump. 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.