| Summary: | ASTERISK-10154: Queue members "disappear" when none are available. | ||
| Reporter: | alric (alric) | Labels: | |
| Date Opened: | 2007-08-23 13:38:56 | Date Closed: | 2007-08-29 10:59:01 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/app_queue |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 10541_debug.patch ( 1) 10541_fix.patch ( 2) PostPatch1.txt ( 3) QueueCLIConfig.txt ( 4) RealCoreDebug.txt | |
| Description: | Attached is a CLI log that shows what problem I'm having, and my queue configuration from queues.conf. I have a queue with two members, both defined via the Local/ channel (but this will happen with SIP/ interfaces as well.) When I call into this queue and all members are busy or unavailable, and the queue tries a second pass, all of the members are gone. I do a queue show <queue> before and after the call which shows the members missing after the call. On the 1.4.9 release my configuration was working just fine. Since 1.4.10 it has not worked as expected. | ||
| Comments: | By: Mark Michelson (mmichelson) 2007-08-23 15:43:40 This problem has come about due to my patch I uploaded for issue ASTERISK-9992. The short version of what's wrong is that if you have a static queue with static members, then if any realtime member data is found (even if you just have an empty member table), then all the static members will be removed from the queue after a call is attempted to be made. In this particular case, Alric has a table defined for realtime queue members since he eventually will be migrating to using them, but still is using static members for the time being. The fix for now is just to not have Asterisk know about that table until he is fully migrated to realtime. Prior to the commit in issue ASTERISK-9992, any checks regarding realtime queue members were predicated on the fact that the queues themselves must also be realtime. The patch for ASTERISK-9992 does NOT check if the queue in question is a realtime queue before attempting to load realtime members. What complicates things more is that the direction we're going at this point is to fully allow realtime members in static queues. So the answer is to allow for both static and realtime members to be in static queues. I will have a patch which allows for this shortly. By: Mark Michelson (mmichelson) 2007-08-23 16:13:31 After trying to make sense of the code a bit more, I realized that what queues need are a way of distinguishing realtime members from non-realtime members. The patch 10451_fix.patch should fix this problem. I have no doubts that things will work correctly for Alric, however I would like someone who has realtime queue members set up to give this a whirl as well since it would be nice to know if they work, too. By: alric (alric) 2007-08-24 16:09:22 Patch works for me :) By: Mark Michelson (mmichelson) 2007-08-29 10:59:01 I tested this out with realtime and it worked great! This issue is closed. 1.4: Fixed with revision 81340 trunk: Fixed with revision 81341 | ||