[asterisk-dev] Queue retry value
Steve Totaro
stotaro at totarotechnologies.com
Thu Jul 19 06:47:10 CDT 2007
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
More information about the asterisk-dev
mailing list