:-)<br><br><div><span class="gmail_quote">On 7/20/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;">
I type fast.  Besides, I like to help out newbies that seem promising<br>and do a little hand holding until they find their legs ;-)<br><br>Thanks,<br>Steve Totaro<br><br>Sean Bright wrote:<br>> And just think... with all the effort you just put into that e-mail,
<br>> you could have helped countless others ;-)<br>><br>> On 7/19/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 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<br>>     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
<br>>     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<br>>     discussion<br>>     of your issue.  There are thousands of people using Asterisk for
<br>>     countless purposes, most likely, someone has the same thought,<br>>     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
<br>>     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<br>>     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>><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>>     >     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<br>>     calls and
<br>>     >     there<br>>     >     is no delay in retry.  It sounds like the equivalent to a<br>>     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<br>>     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<br>>     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<br>>     clarify this<br>>     >     more if needed since he is the one that introduced the code<br>>     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<br>>     misunderstood my<br>>     >     > original e-mail.<br>>     >     >
<br>>     >     > My original question had nothing to do with not liking the<br>>     rationale<br>>     >     > behind why that design decision was made, but simply not<br>>     actually<br>>     >     > _knowing_ the reason behind that decision.
<br>>     >     ><br>>     >     > Obviously, I have already changed app_queue to allow the<br>>     'retry'<br>>     >     value<br>>     >     > to be 0, and have tested it successfully in my local
<br>>     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<br>>     said, it<br>>     >     _is_<br>>     >     > simply a development environment that isn't under any
<br>>     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
<br>>     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
<br>>     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<br>>     that my<br>>     >     change<br>>     >     > will not adversely affect the production environment) I<br>>     will be
<br>>     >     happy<br>>     >     > to submit a patch to the bug tracker.  My disclaimer has<br>>     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* <<br>>     <a href="mailto:stotaro@totarotechnologies.com">
stotaro@totarotechnologies.com</a> <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>>><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><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<br>>     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<br>
>     forum from<br>>     >     >     developers<br>>     >     >     and bug marshals (unless of course they just close it<br>>     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>>     >     >     > <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><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>>     >     >     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<br>>     to wait at<br>>     >     >     least 1<br>>     >     >     >     second between attempts to contact the next
<br>>     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>>     >     >     ><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>>     >     >     ><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><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>>     >     < <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>>     >     >
<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>>     <<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<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>>     ------------------------------------------------------------------------
<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>><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>