I think this issue should be escalated to the bug tracker because it's quite serious.
Could you post all details here - http://redmine.kannel.org/projects/kannel Queue on one of the binds shouldnt affect queue of other ones at all. We experienced something similar when there were problems with one of our binds. 2012/12/14 Nick Mahilani <[email protected]> > I had tried setting the sms-outgoing-queue-limit = 0 but I still saw > messages getting enqueued to the outgoing_sms queue. Also, in my load tests > with SMPP simulator binds connected to kannel, I saw a lot of full_found > queue full error with this setting set to 0.. Having a small buffer ~10 > helped avoid most of the errors, but setting the limit to 10 caused retries > for all binds going to the global outgoing_sms queue and hit the > sum(#queues) limit condition in smsc2_rout(), which is what I wanted to > avoid.. Since one saturated bind can affect traffic on other binds.. > > On Thu, Dec 13, 2012 at 12:00 PM, Rene Kluwen <[email protected]>wrote: > >> 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]<[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 (max_outgoing_sms_qlength >> <http://doxygen.kannel.org/d5/d27/bb__smscconn_8c.html#a8> > 0 && !resend >> <http://doxygen.kannel.org/d6/d9f/wtp__init_8h.html#a33a30> &&**** >> >> 01091 queue_length > gwlist_len >> <http://doxygen.kannel.org/da/d23/list_8h.html#a6>(smsc_list) * >> max_outgoing_sms_qlength) {**** >> >> 01092 gw_rwlock_unlock >> <http://doxygen.kannel.org/d2/dbd/gw-rwlock_8h.html#a4>(&smsc_list_lock);**** >> >> 01093 debug >> <http://doxygen.kannel.org/d7/d7f/log_8h.html#a14>("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**** >> >> ** ** >> > >
