[asterisk-dev] Queue retry value
Sean Bright
sean.bright at gmail.com
Thu Jul 19 07:25:43 CDT 2007
And just think... with all the effort you just put into that e-mail, you
could have helped countless others ;-)
On 7/19/07, Steve Totaro <stotaro at totarotechnologies.com> wrote:
>
> Sean,
>
> I am here to help when I can but am certainly not a Dev guy, I was
> waiting for one of the multitude of smarter people than myself on the
> list to answer your question. When I saw your post being ignored and
> followed up with the self reply "Awesome. Thanks a bunch.", I felt your
> frustration.
>
> My first post was directing you to bugtracker/Mantis (where you would
> have found your answer). I believe that searching/opening a bug will
> certainly get more feedback than posting questions like this to the Dev
> list. Bugs get opened and then assigned to someone who provides
> feedback before closing or acting on it.
>
> The suggestion in my first post would have been very helpful if taken
> for what it was.
>
> In addition, you will find that taking the time to search
> bugtracker/mantis will often provide the answer or at least a discussion
> of your issue. There are thousands of people using Asterisk for
> countless purposes, most likely, someone has the same thought, issue, or
> idea.
>
> Google is your friend. With the search terms "retry queues.conf" on
> page four of the search results, half way down the page, you would have
> found your answer on your own. It took me less than three minutes.
>
> Finally, simple logic would dictate that constantly banging on
> unavailable Agents with no backingoff is not a good idea and would
> quickly bring a system to it's knees in a large scale, high call volume
> setup. It would probably not cause any issues with a few agents and a
> couple tens of callers though.
>
> Thanks,
> Steve
>
> Sean Bright wrote:
> > 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
> > <mailto: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>
> > > <mailto: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>>
> > > > <mailto: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
> > <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
> > <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
>
>
> _______________________________________________
> --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/64207e47/attachment-0001.htm
More information about the asterisk-dev
mailing list