Summary:	ASTERISK-12216: Queue() uses cached information to determine whether queue is empty or not
Reporter:	Nick Barnes (bcnit)	Labels:
Date Opened:	2008-06-18 02:24:24	Date Closed:	2008-07-08 11:17:21
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 12880.patch ( 1) 12880v2.patch
Description:	If I have a queue which is driven by realtime and Asterisk is not aware of the queue (i.e. 'queue show' shows nothing), then if the queue is set with 'joinempty=no', when you try to queue a call to it, Asterisk bounces the call out with QUEUESTATUS as JOINEMPTY. Once Asterisk knows of the queue's existance, then realtime is checked to see if the queue is empty or not and all works fine. The only way I can get around this is to run a script when Asterisk starts which interrogates the database to get the list of all queues run by realtime and then issue an 'asterisk -rx "queue show QUEUE"' for each one to populate the cache. Please see bug report ASTERISK-12195 to which this is probably related.
Comments:	By: Mark Michelson (mmichelson) 2008-06-19 18:54:27 When a caller joins a queue, app_queue does not use cached information. It will attempt to load the queue and member information from realtime every time a caller joins a realtime queue. In fact, the code when a caller joins a queue uses the same function to get the realtime information that queue show <queuename> does. It doesn't really make sense that one would work properly and the other would not. I tried to reproduce this issue myself but could not. Everything worked as expected. Unfortunately, there are lots of possible reasons why the scenario could be failing for you. To make matters worse, asking for console output isn't going to do any good because there are no decent debug messages that get printed at that point. What I will do for this issue is to upload a patch which does not change app_queue's behavior but adds a lot of console messages so that I can see exactly what is happening when this failure occurs. The patch will most likely be ready by tomorrow. By: Mark Michelson (mmichelson) 2008-06-20 10:09:48 I have uploaded a patch to this issue which will log what is going on in the scenario when the failure occurs. I have made the log messages NOTICEs so that you don't have to turn on any extra debugging. If you can show what is output when you place a test call to the queue, that would be very helpful. Thanks! By: Mark Michelson (mmichelson) 2008-07-01 11:31:41 I have a sneaking suspicion that this issue is actually the same as what's happening in ASTERISK-12220. That, coupled with the fact that I haven't heard any feedback on the patch, is prompting me to suspend this. By: Nick Barnes (bcnit) 2008-07-01 11:35:40 Sorry - I have been busy and not able to spend any time on any of the bugs recently reported. I have allocated time tomorrow and will update everything then. By: Nick Barnes (bcnit) 2008-07-03 10:30:30 After having had a play with this, I agree that this is the same underlying issue as 0012884 - just experienced under a different set of circumstances! By: Mark Michelson (mmichelson) 2008-07-08 11:17:16 Closing this issue since it turns out that ASTERISK-12220 is actually the real issue causing this. Since 12884 more accurately describes the issue and has patches attached, I am closing this in favor of the newer issue.