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><div><span class="gmail_quote">On 7/18/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 see what you mean. Maybe this will help?<br><br>Consider what would happen in a large scale deployment with hundreds of<br>agents and hundreds more callers. All the agents are on calls and 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' 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 release<br>> branches, I would be happy to share. Its just a one-liner.). So far,<br>> I have experienced no notable side effects. That being said, it _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 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 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 production
<br>> that might bring the PBX down.<br>><br>> Once I get that information (or I am at least satisfied that my change<br>> will not adversely affect the production environment) I will be happy<br>> to submit a patch to the bug tracker. My disclaimer has been on 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>>> 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 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>> wrote:
<br>> ><br>> > Hey guys,<br>> ><br>> > I know this is the "wrong" list, but I'm more interested in the<br>> > rationale behind this decision...<br>
> ><br>> > Why is the 'retry' value in queues.conf limited to 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, but I doubt<br>> > I'll get a satisfactory response there.
<br>> ><br>> > Thanks,<br>> > Sean<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>><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>><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>