[asterisk-dev] [Code Review]: Fix behavior of queue set penalty so that it properly handles 'queue set penalty <penalty> on <interface>' instead of crashing caused by r325483

[jrose]

> On Dec. 6, 2011, 10:48 a.m., mjordan wrote:
> > The only issue that I have is this appears to introduce two different behaviors with how penalties are set, based on whether or not you have the queues stored in realtime.
> > * If realtime is not being used, then you can either specify a queue name or not.  If you specify a queue name, it will update the specified queue, otherwise it will update all queues
> > * If realtime is being used, you have to specify a queue name, and there is no way to update the penalty on all queues at once
> > 
> > I'm not sure if this behavior should be different.

Well, really it shouldn't be different, but irroot's patch broke the documented behavior of being able to not specify a queue to use all the queues at once getting it to work with realtime in the first place.  I could attempt to fix it, but then I'll need to setup realtime queues, figure out how to iterate through all the queues in realtime, and continually test while working on this... It'll take more time anyway.


> On Dec. 6, 2011, 10:48 a.m., mjordan wrote:
> > /branches/10/apps/app_queue.c, line 5442
> > <https://reviewboard.asterisk.org/r/1609/diff/1/?file=22116#file22116line5442>
> >
> >     You may want to consider structuring this a bit differently, as right now if a user specifies a queue name, you have to iterate over every queue in the container instead of using the hash lookup.  You may want to go with something more like the following:
> >     
> >     if the queue name is specified:
> >       use ao2_find and update the queue, or error if no queue found
> >     otherwise:
> >       update all queues
> >     
> >     Since this may introduce some code duplication with the realtime method below, you may want to defer some of the actual work of updating the penalty and sending out the manager event to a private method.

Yeah, I found this a little odd myself.  This is just how it was handled before the patch that broke this behavior in the first place.  I could probably fix this up fairly quickly though.


- jrose


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1609/#review4930
-----------------------------------------------------------


On Dec. 6, 2011, 10:06 a.m., jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1609/
> -----------------------------------------------------------
> 
> (Updated Dec. 6, 2011, 10:06 a.m.)
> 
> 
> Review request for Asterisk Developers and irroot.
> 
> 
> Summary
> -------
> 
> r325483 caused Asterisk to lose the ability to set penalty on an interface without specifying the queue, and worse than that also introduces a segfault from trying to.  The segfault only occurs when penalty is set using the queue set penalty command in CLI and not when using QueuePenalty from the manager, however the manager action wouldn't work without specifying a queue either, it just wouldn't crash Asterisk.
> 
> This patch attempts to fix that by changing irroot's realtime patch so that the new method for picking the queue being acted on is only employed if the method used prior to that can't find a queue to work on.  If no queuename is specified, this is fine since the crash would only occur if there was a queue attached to the interface anyway.  This doesn't seem to cause any problems in normal queues, but I haven't tested it with realtime queues.
> 
> 
> Diffs
> -----
> 
>   /branches/10/apps/app_queue.c 346971 
> 
> Diff: https://reviewboard.asterisk.org/r/1609/diff
> 
> 
> Testing
> -------
> 
> Various uses of queue set penalty and QueuePenalty from manager.  Also, I'm currently working on an automated test for this within the Asterisk testsuite.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111206/06053db5/attachment-0001.htm>