[asterisk-dev] Queue retry value
Sean Bright
sean.bright at gmail.com
Fri Jul 20 10:25:17 CDT 2007
:-)
On 7/20/07, Steve Totaro <stotaro at totarotechnologies.com> wrote:
>
> I type fast. Besides, I like to help out newbies that seem promising
> and do a little hand holding until they find their legs ;-)
>
> Thanks,
> Steve Totaro
>
> Sean Bright wrote:
> > 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
> > <mailto: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>
> > > <mailto: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>>
> > > > <mailto: 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>>>
> > > > > <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 <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-- <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>
> > > <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
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > --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/20070720/a941115e/attachment-0001.htm
More information about the asterisk-dev
mailing list