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 <rene.klu...@chimit.nl> wrote: > What if you just set the queue-limit to 0. Won’t that have the same effect? > **** > > ** ** > > == Rene**** > > ** ** > > ** ** > > *From:* devel-boun...@vm1.kannel.org [mailto:devel-boun...@vm1.kannel.org] > *On Behalf Of *Nick Mahilani > *Sent:* donderdag 13 december 2012 19:04 > *To:* Amin Mukhaimer > *Cc:* de...@vm1.kannel.org > *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 < > ami...@arabmobilecontent.com> 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:nicky.mahil...@gmail.com] > *Sent:* Wednesday, November 21, 2012 7:00 PM > *To:* ami...@arabmobilecontent.com > *Cc:* devel@kannel.org > *Subject:* RE: outgoing queue limit in bearbox**** > > **** > > Thanks Amin for your suggestion...**** > > Can we run multiple kannel instances on the same box?**** > > > Amin Mukhaimer <ami...@arabmobilecontent.com> 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:* devel-boun...@kannel.org > [mailto:devel-boun...@kannel.org<devel-boun...@kannel.org>] > *On Behalf Of *Nick Mahilani > *Sent:* Wednesday, November 21, 2012 1:16 AM > *To:* devel@kannel.org > *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**** > > ** ** >
