[asterisk-dev] Queue retry value

[Sean Bright]

Hi Steve,

If only you had been more helpful in your first e-mail!

I've already taken care of this, but thanks!

Sean

On 7/18/07, Steve Totaro <stotaro at totarotechnologies.com> wrote:
>
> 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
>
>
> _______________________________________________
> --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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070719/c411c950/attachment.htm