Re: Kannel HTTP MO delivery failing under load

Just on a side-note, might there be some work-around for this issue, by 
throttling the rate at which MOs are accepted into Kannel? (thereby 
reducing the rate of MOs delivered from Kannel via HTTP) What about 
throttling the outgoing MO delivery rate, and queuing inside Kannel? I'm 
only aware of MT delivery rate throttling, at the SMPP adapters...

A work-around would be useful as a 'plan B', in addition to getting a 
proper patch for the issue.

Giulio Harding wrote:
> Alexander Malysh wrote:
>> It's a bug in smsbox that it didn't limit max allowed http 
>> connections. The same bug is present in HTTP SMSC module. HTTP was 
>> fixed by me as I was at Centrium/Wapme but unfortunately I didn't 
>> merged it and don't have modifications anymore but it was really 
>> simple to fix. I will try to provide patch this/next week.
> 
> That would be great! Once this issue is resolved, Kannel will 
> effectively be working 'perfectly' for us :)
> 
>> as for the fact that MO messages are not retransmitted in smsbox: did 
>> you enable retry in smsbox?
> 
> As per the config I attached to my original email, http-request-retry 
> was set to 0, so no - the smsbox wasn't set to retry.
> 
> However, when I re-ran the test with http-request-retry = 10, I didn't 
> see any difference in behaviour - the log messages were the same 
> (indicating that http requests failed because of too many open files), 
> and I didn't see any indication that a retry was being attempted. The 
> Kannel docs seem to suggest that setting that parameter to a non-zero 
> value is all that's required to enable retransmits - am I missing 
> something else?
> 
>> Thanks,
>> Alex
>>
>> Am 03.08.2006, 09:25 Uhr, schrieb Giulio Harding 
>> <[email protected]>:
>>
>>> Hillel wrote:
>>>> Hi,
>>>>  Are you using as a OpenSMPP SMSC simulator the 
>>>> http://opensmpp.logica.com/
>>>> or as another version?
>>>>  Please email back the version you are using, so others can confirm 
>>>> your
>>>> results.
>>>>  Rgds
>>>
>>> Sorry, it turns out the version of OpenSMPP we're using has been 
>>> heavily modified from the original - however, I have been able to 
>>> reproduce the problem using the latest version of SMPPSim, with the 
>>> following configuration options (modified only slightly from the 
>>> stock configuration):
>>>
>>> SMPP_PORT=7011
>>> SMPP_CONNECTION_HANDLERS=2
>>>
>>> CONNECTION_HANDLER_CLASS=com.seleniumsoftware.SMPPSim.StandardConnectionHandler 
>>>
>>> PROTOCOL_HANDLER_CLASS=com.seleniumsoftware.SMPPSim.StandardProtocolHandler 
>>>
>>>
>>> LIFE_CYCLE_MANAGER=com.seleniumsoftware.SMPPSim.LifeCycleManager
>>>
>>> MESSAGE_STATE_CHECK_FREQUENCY=5000
>>>
>>> MAX_TIME_ENROUTE=10000
>>>
>>> PERCENTAGE_THAT_TRANSITION=75
>>>
>>> PERCENTAGE_DELIVERED=100
>>> PERCENTAGE_UNDELIVERABLE=0
>>> PERCENTAGE_ACCEPTED=0
>>> PERCENTAGE_REJECTED=0
>>>
>>> DISCARD_FROM_QUEUE_AFTER=60000
>>>
>>> HTTP_PORT=8081
>>> HTTP_THREADS=1
>>> DOCROOT=www
>>> AUTHORISED_FILES=/css/style.css,/index.htm,/inject_mo.htm,/favicon.ico,/images/logo.gif,/images/dots.gif,/user-guide.htm,/images/homepage.gif,/images/inject_mo.gif 
>>>
>>> INJECT_MO_PAGE=/inject_mo.htm
>>>
>>> SYSTEM_ID=test
>>> PASSWORD=test
>>>
>>> DELIVERY_MESSAGES_PER_MINUTE=12000
>>> DELIVER_MESSAGES_FILE=deliver_messages.csv
>>>
>>> LOOPBACK=FALSE
>>>
>>> OUTBOUND_QUEUE_MAX_SIZE=500000
>>> INBOUND_QUEUE_MAX_SIZE=500000
>>>
>>> DECODE_PDUS_IN_LOG=false
>>>
>>> CAPTURE_SME_BINARY=false
>>> CAPTURE_SME_BINARY_TO_FILE=sme_binary.capture
>>> CAPTURE_SMPPSIM_BINARY=false
>>> CAPTURE_SMPPSIM_BINARY_TO_FILE=smppsim_binary.capture
>>> CAPTURE_SME_DECODED=false
>>> CAPTURE_SME_DECODED_TO_FILE=sme_decoded.capture
>>> CAPTURE_SMPPSIM_DECODED=false
>>> CAPTURE_SMPPSIM_DECODED_TO_FILE=smppsim_decoded.capture
>>>
>>> CALLBACK=false
>>> CALLBACK_ID=SIM1
>>> CALLBACK_TARGET_HOST=localhost
>>> CALLBACK_PORT=3333
>>>
>>> SMSCID=SMPPSim
>>>
>>>
>>> However, SMPPSim isn't as fast as OpenSMPP, so I had to run 4 
>>> instances on separate servers (with additional SMSC configurations in 
>>> Kannel accordingly) to reach an MO injection rate of ~600 MOs/sec (no 
>>> MTs), in order to trigger the problem.
>>>
>>> At rates of ~450 MOs/sec, with no MTs, or ~350 MOs/sec + ~320 
>>> MTs/sec, the problem did not surface.
>>>
>>> Regardless of the SMSC simulator being used, MO injection rates of 
>>> around 600 MOs/sec (on the hardware I described before) triggers the 
>>> problem. Has anyone been able to reproduce this yet, or does anyone 
>>> have an idea why this might happen?
>>>
>>> Cheers,
>>>
>>
>>
>>
>> --Thanks,
>> Alex
>>
>>
>>
> 
> 


-- 
Giulio Harding
Systems Administrator

m.Net Corporation
Level 13, 99 Gawler Place
Adelaide SA 5000, Australia

Tel: +61 8 8210 2041
Fax: +61 8 8211 9620
Mobile: 0432 876 733
MSN: [email protected]

http://www.mnetcorporation.com