What if you just set the queue-limit to 0. Won't that have the same effect?
== Rene From: [email protected] [mailto:[email protected]] On Behalf Of Nick Mahilani Sent: donderdag 13 december 2012 19:04 To: Amin Mukhaimer Cc: [email protected] Subject: Re: outgoing queue limit in bearbox Thanks Amin ! While this approach works it is not very scalable if we have more operators in the future. As an alternative, I have defined a configurable in kannel config to bypass retries using the outgoing_sms queue. When turned on, this option disables queuing any messages to the 'outgoing_sms' queue and sends back a DLR NACK for any messages that fail for any reason(QFULL or submit_sm_resp with error from SMSC). This essentially moves the retry logic from kannel to the application using kannel and gives the application more control of the retry logic. This also avoids one saturated bind from affecting other binds. I wanted to get some feedback and if you see any potential problems with this approach. I have attached a diff for this change. Please review. -Nick Hi, I am using kannel with multiple SMSCs in my org and we often see that high load on one of the binds impacts the traffic on the other binds. After looking at the code, I see that the outgoing_sms queue is used as a global retry queue and if high load is directed to one of the binds, this fills up the outgoing_sms queue and causes 503 for the other sms traffic going through other binds.. As a potential fix, I have defined a configurable in kannel config to bypass retries using the outgoing_sms queue. When turned on, this option disables queuing any messages to the 'outgoing_sms' queue and sends back a DLR NACK for any messages that fail due to QFULL conditions or other cases that would otherwise enqueue to the 'outgoing_sms' queue. This essentially moves the retry logic from kannel to the application using kannel.. I wanted to get some feedback on if you see any potential problems with this approach. I can forward a diff if someone could review the diff and provide feedback. thanks, Nick On Wed, Nov 21, 2012 at 11:01 PM, Amin Mukhaimer <[email protected]> wrote: Yes of course, just make different config files for each and run an instance for each, like bearerbox operator1_config smsbox operator1_config bearerbox operator2_config smsbox operator2_config make sure they have different ports/spool directory/database tables/ log files. and good luck Amin From: Nick Mahilani [mailto:[email protected]] Sent: Wednesday, November 21, 2012 7:00 PM To: [email protected] Cc: [email protected] Subject: RE: outgoing queue limit in bearbox Thanks Amin for your suggestion... Can we run multiple kannel instances on the same box? Amin Mukhaimer <[email protected]> wrote: I had a somewhat similar problem is that it tends to get slow when sending high amounts of SMSs to specific SMSC, and SMSs sent to other SMSCs are delayed for a while, so I decided to run multiple Kannels, one for each operator, hopping that would increase overall performance. I don't know if that helps, but good luck. From: [email protected] [mailto:[email protected]] On Behalf Of Nick Mahilani Sent: Wednesday, November 21, 2012 1:16 AM To: [email protected] Subject: outgoing queue limit in bearbox Hi, I have an application which is using Kannel to send outgoing sms via multiple SMSC's. However, there is an insane volume of messages that needs to go through one of the SMSC which is impacting the other binds due to the global outgoing queue limit check in the code. if ( <http://doxygen.kannel.org/d5/d27/bb__smscconn_8c.html#a8> max_outgoing_sms_qlength > 0 && ! <http://doxygen.kannel.org/d6/d9f/wtp__init_8h.html#a33a30> resend && 01091 queue_length > <http://doxygen.kannel.org/da/d23/list_8h.html#a6> gwlist_len(smsc_list) * max_outgoing_sms_qlength) { 01092 <http://doxygen.kannel.org/d2/dbd/gw-rwlock_8h.html#a4> gw_rwlock_unlock(&smsc_list_lock); 01093 <http://doxygen.kannel.org/d7/d7f/log_8h.html#a14> debug("bb.sms", 0, "sum(#queues) limit"); 01094 return SMSCCONN_FAILED_QFULL; 01095 } I am very new to the kannel codebase so wanted to get some input on how complicated is the fix to isolate the queue limits to each bind/SMSC. I would like the other binds to not get affected by high volume of traffic on one of the binds. So if one smsc queue is backed up, it does not impact the messages sent to other SMSC's. Also, what is recommended outgoing queue limit value in terms of messages per second being sent through Kannel? thanks, Nick
