[asterisk-dev] [Code Review] Make sure the member count is correct after a reload

[rmudgett]

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

Ship it!


Other than the minor point below, the changes are doing what you said.  It is nice to see the code simplified as a result of this change.


/branches/1.8/apps/app_queue.c
<https://reviewboard.asterisk.org/r/1541/#comment8759>

    I think you should have a local variable holding the returned container count so the value used will be guaranteed consistent.


- rmudgett


On Oct. 25, 2011, 1:46 p.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1541/
> -----------------------------------------------------------
> 
> (Updated Oct. 25, 2011, 1:46 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> With the situation:
> queues.conf
> [test]
> strategy=ringall
> member => Local/queue1 at default,1
> member => Local/queue2 at default,1
> member => Local/queue3 at default,1
> 
> extensions.conf
> [default]
> exten => 100,1,Queue(test)
> exten => _queueX,1,NoOp(Called ${EXTEN})
> same => n,Ringing
> same => n,Wait(5)
> same => n,Hangup
> 
> Dialing 100 will ring all queue members. Changing the penalty of two of the members and doing a 'module reload app_queue.so' and redialing would still ring all of the members on the first try instead of just the lowest penalty member. This was because a reload would set the membercount to 0 and then only increase the membercount for *new* members and not reloaded members. Then, since the penaltymemberlimit = 0 and the membercount = 0, we ignored the penalties and would dial all members.  This patch increases the member count for both reloaded and added members since we set the member count to zero on reloads anyway.
> 
> 
> This addresses bug AST-676.
>     https://issues.asterisk.org/jira/browse/AST-676
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/apps/app_queue.c 342327 
> 
> Diff: https://reviewboard.asterisk.org/r/1541/diff
> 
> 
> Testing
> -------
> 
> Fixes the above scenario.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111025/bdd1647f/attachment.htm>