[asterisk-dev] Queue retry value

[Steve Totaro]

Sean,

I see what you mean.  Maybe this will help?

Consider what would happen in a large scale deployment with hundreds of 
agents and hundreds more callers.  All the agents are on calls and there 
is no delay in retry.  It sounds like the equivalent to a very tight 
loop or packet storm and does not sound like a good idea.

Try removing or commenting the retry entry and see if the one second 
delay is still an issue.

* apps/app_queue.c: Setting a retry of 0 is generally not a good
      idea and shouldn't be allowed. (#7574 - reported by regin)

http://bugs.digium.com/view.php?id=7574

Hope that helps.  It looks like maybe B.J. Weschke could clarify this 
more if needed since he is the one that introduced the code that does 
not allow 0.

Thanks,
Steve Totaro

Maybe in a

Sean Bright wrote:
> Hi Steve,
>
> Thank you for the tips, but I think you may have misunderstood my 
> original e-mail.
>
> My original question had nothing to do with not liking the rationale 
> behind why that design decision was made, but simply not actually 
> _knowing_ the reason behind that decision.
>
> Obviously, I have already changed app_queue to allow the 'retry' value 
> to be 0, and have tested it successfully in my local development 
> environment (If you'd like a patch against trunk or one of the release 
> branches, I would be happy to share.  Its just a one-liner.).  So far, 
> I have experienced no notable side effects.  That being said, it _is_ 
> simply a development environment that isn't under any significant 
> load, so I can't be sure without testing in a production environment.
>
> And that is the reason I asked here.  There was a reason that the 
> original author decided not to allow 'retry' values of 0, and that may 
> be because it causes problems elsewhere in the PBX.  That is the 
> information I was after, so I can avoid pushing code into production 
> that might bring the PBX down.
>
> Once I get that information (or I am at least satisfied that my change 
> will not adversely affect the production environment) I will be happy 
> to submit a patch to the bug tracker.  My disclaimer has been on file 
> for months, so that won't be a problem.
>
> Thanks again for your response!
> Sean
>
> On 7/18/07, *Steve Totaro* <stotaro at totarotechnologies.com 
> <mailto:stotaro at totarotechnologies.com>> wrote:
>
>     Sean,
>
>     The beauty of open source software is the ability to change it.  
>     If you
>     do not like the "rationale", you can sign a disclaimer and submit a
>     patch to bugtracker for consideration of inclusion.
>
>     I am sure you will get much more feedback in that forum from
>     developers
>     and bug marshals (unless of course they just close it with no
>     explanation ;-)
>
>     Thanks,
>     Steve Totaro
>
>     Sean Bright wrote:
>     > Awesome.  Thanks a bunch.
>     >
>     > On 7/17/07, *Sean Bright* <sean.bright at gmail.com
>     <mailto:sean.bright at gmail.com>
>     > <mailto:sean.bright at gmail.com <mailto:sean.bright at gmail.com>>>
>     wrote:
>     >
>     >     Hey guys,
>     >
>     >     I know this is the "wrong" list, but I'm more interested in the
>     >     rationale behind this decision...
>     >
>     >     Why is the 'retry' value in queues.conf limited to values >
>     0?  I
>     >     am using rrmemory with a queue, and I am forced to wait at
>     least 1
>     >     second between attempts to contact the next agent in
>     line.  I can
>     >     take this question to the -users list if necessary, but I doubt
>     >     I'll get a satisfactory response there.
>     >
>     >     Thanks,
>     >     Sean
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > --Bandwidth and Colocation Provided by http://www.api-digital.com--
>     >
>     > asterisk-dev mailing list
>     > To UNSUBSCRIBE or update options visit:
>     >     http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>     _______________________________________________
>     --Bandwidth and Colocation Provided by
>     http://www.api-digital.com-- <http://www.api-digital.com-->
>
>     asterisk-dev mailing list
>     To UNSUBSCRIBE or update options visit:
>        http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev