And just think... with all the effort you just put into that e-mail, you could have helped countless others ;-)<br><br><div><span class="gmail_quote">On 7/19/07, <b class="gmail_sendername">Steve Totaro</b> <<a href="mailto:stotaro@totarotechnologies.com">
stotaro@totarotechnologies.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sean,<br><br>I am here to help when I can but am certainly not a Dev guy, I was
<br>waiting for one of the multitude of smarter people than myself on the<br>list to answer your question. When I saw your post being ignored and<br>followed up with the self reply "Awesome. Thanks a bunch.", I felt your
<br>frustration.<br><br>My first post was directing you to bugtracker/Mantis (where you would<br>have found your answer). I believe that searching/opening a bug will<br>certainly get more feedback than posting questions like this to the Dev
<br>list. Bugs get opened and then assigned to someone who provides<br>feedback before closing or acting on it.<br><br>The suggestion in my first post would have been very helpful if taken<br>for what it was.<br><br>In addition, you will find that taking the time to search
<br>bugtracker/mantis will often provide the answer or at least a discussion<br>of your issue. There are thousands of people using Asterisk for<br>countless purposes, most likely, someone has the same thought, issue, or<br>
idea.<br><br>Google is your friend. With the search terms "retry queues.conf" on<br>page four of the search results, half way down the page, you would have<br>found your answer on your own. It took me less than three minutes.
<br><br>Finally, simple logic would dictate that constantly banging on<br>unavailable Agents with no backingoff is not a good idea and would<br>quickly bring a system to it's knees in a large scale, high call volume<br>
setup. It would probably not cause any issues with a few agents and a<br>couple tens of callers though.<br><br>Thanks,<br>Steve<br><br>Sean Bright wrote:<br>> Hi Steve,<br>><br>> If only you had been more helpful in your first e-mail!
<br>><br>> I've already taken care of this, but thanks!<br>><br>> Sean<br>><br>> On 7/18/07, *Steve Totaro * <<a href="mailto:stotaro@totarotechnologies.com">stotaro@totarotechnologies.com</a><br>
> <mailto:<a href="mailto:stotaro@totarotechnologies.com">stotaro@totarotechnologies.com</a>>> wrote:<br>><br>> Sean,<br>><br>> I see what you mean. Maybe this will help?<br>><br>> Consider what would happen in a large scale deployment with
<br>> hundreds of<br>> agents and hundreds more callers. All the agents are on calls and<br>> there<br>> is no delay in retry. It sounds like the equivalent to a very tight<br>> loop or packet storm and does not sound like a good idea.
<br>><br>> Try removing or commenting the retry entry and see if the one second<br>> delay is still an issue.<br>><br>> * apps/app_queue.c: Setting a retry of 0 is generally not a good<br>> idea and shouldn't be allowed. (#7574 - reported by regin)
<br>><br>> <a href="http://bugs.digium.com/view.php?id=7574">http://bugs.digium.com/view.php?id=7574</a><br>><br>> Hope that helps. It looks like maybe B.J . Weschke could clarify this<br>> more if needed since he is the one that introduced the code that does
<br>> not allow 0.<br>><br>> Thanks,<br>> Steve Totaro<br>><br>> Maybe in a<br>><br>> Sean Bright wrote:<br>> > Hi Steve,<br>> ><br>> > Thank you for the tips, but I think you may have misunderstood my
<br>> > original e-mail.<br>> ><br>> > My original question had nothing to do with not liking the rationale<br>> > behind why that design decision was made, but simply not actually<br>
> > _knowing_ the reason behind that decision.<br>> ><br>> > Obviously, I have already changed app_queue to allow the 'retry'<br>> value<br>> > to be 0, and have tested it successfully in my local development
<br>> > environment (If you'd like a patch against trunk or one of the<br>> release<br>> > branches, I would be happy to share. Its just a<br>> one-liner.). So far,<br>> > I have experienced no notable side effects. That being said, it
<br>> _is_<br>> > simply a development environment that isn't under any significant<br>> > load, so I can't be sure without testing in a production<br>> environment.<br>> >
<br>> > And that is the reason I asked here. There was a reason that the<br>> > original author decided not to allow 'retry' values of 0, and<br>> that may<br>> > be because it causes problems elsewhere in the PBX. That is the
<br>> > information I was after, so I can avoid pushing code into<br>> production<br>> > that might bring the PBX down.<br>> ><br>> > Once I get that information (or I am at least satisfied that my
<br>> change<br>> > will not adversely affect the production environment) I will be<br>> happy<br>> > to submit a patch to the bug tracker. My disclaimer has been on<br>> file<br>
> > for months, so that won't be a problem.<br>> ><br>> > Thanks again for your response!<br>> > Sean<br>> ><br>> > On 7/18/07, *Steve Totaro* <<a href="mailto:stotaro@totarotechnologies.com">
stotaro@totarotechnologies.com</a><br>> <mailto:<a href="mailto:stotaro@totarotechnologies.com">stotaro@totarotechnologies.com</a>><br>> > <mailto:<a href="mailto:stotaro@totarotechnologies.com">
stotaro@totarotechnologies.com</a><br>> <mailto:<a href="mailto:stotaro@totarotechnologies.com">stotaro@totarotechnologies.com</a>>>> wrote:<br>> ><br>> > Sean,<br>> ><br>
> > The beauty of open source software is the ability to change it.<br>> > If you<br>> > do not like the "rationale", you can sign a disclaimer and<br>> submit a<br>
> > patch to bugtracker for consideration of inclusion.<br>> ><br>> > I am sure you will get much more feedback in that forum from<br>> > developers<br>> > and bug marshals (unless of course they just close it with no
<br>> > explanation ;-)<br>> ><br>> > Thanks,<br>> > Steve Totaro<br>> ><br>> > Sean Bright wrote:<br>> > > Awesome. Thanks a bunch.
<br>> > ><br>> > > On 7/17/07, *Sean Bright* <<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a><br>> <mailto:<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com
</a>><br>> > <mailto: <a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a> <mailto:<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a>>><br>> > > <mailto:
<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a><br>> <mailto:<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a>> <mailto:<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com
</a><br>> <mailto:<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a>>>>><br>> > wrote:<br>> > ><br>> > > Hey guys,<br>> > >
<br>> > > I know this is the "wrong" list, but I'm more<br>> interested in the<br>> > > rationale behind this decision...<br>> > ><br>> > > Why is the 'retry' value in
queues.conf limited to<br>> values ><br>> > 0? I<br>> > > am using rrmemory with a queue, and I am forced to wait at<br>> > least 1<br>> > > second between attempts to contact the next agent in
<br>> > line. I can<br>> > > take this question to the -users list if necessary,<br>> but I doubt<br>> > > I'll get a satisfactory response there.<br>> > >
<br>> > > Thanks,<br>> > > Sean<br>> > ><br>> > ><br>> > ><br>> ><br>> ------------------------------------------------------------------------
<br>> > ><br>> > > _______________________________________________<br>> > > --Bandwidth and Colocation Provided by<br>> <a href="http://www.api-digital.com--">http://www.api-digital.com--
</a><br>> > ><br>> > > asterisk-dev mailing list<br>> > > To UNSUBSCRIBE or update options visit:<br>> > > <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">
http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>> ><br>> ><br>> > _______________________________________________<br>> > --Bandwidth and Colocation Provided by<br>
> > <a href="http://www.api-digital.com--">http://www.api-digital.com--</a> <<a href="http://www.api-digital.com--">http://www.api-digital.com--</a>><br>> ><br>> > asterisk-dev mailing list
<br>> > To UNSUBSCRIBE or update options visit:<br>> > <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>> <
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>><br>> ><br>> ><br>> ><br>> ------------------------------------------------------------------------
<br>> ><br>> > _______________________________________________<br>> > --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br>> >
<br>> > asterisk-dev mailing list<br>> > To UNSUBSCRIBE or update options visit:<br>> > <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev
</a><br>> <<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>><br>><br>><br>> _______________________________________________
<br>> --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br>><br>> asterisk-dev mailing list<br>> To UNSUBSCRIBE or update options visit:
<br>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>><br>><br>> ------------------------------------------------------------------------
<br>><br>> _______________________________________________<br>> --Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br>><br>> asterisk-dev mailing list
<br>> To UNSUBSCRIBE or update options visit:<br>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br><br><br>_______________________________________________
<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--">http://www.api-digital.com--</a><br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">
http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br>