David Ritchie wrote:
Hello all. A scenario I'm experiencing at the moment involves a large
(several thousand) number of MT messages being pushed through Kannel,
during which it looks like MO messages (and the routing of them to the
appropriate URLs) gets relegated to a "back seat"; that is, a delay of
several minutes can take place between Kannel receiving the MO message,
and it getting around to pushing it to the correct URL:
smsbox.log:2006-07-15 12:52:13 [8487] [4] INFO: Starting to service
<Test> from <HANDSET> to <SHORTCODE>
smsbox.log:2006-07-15 12:53:08 [8487] [4] INFO: Starting to service
<Test> from <HANDSET> to <SHORTCODE>
smsbox.log:2006-07-15 12:55:10 [8487] [9] DEBUG: Parsing URL
`http://URL/?source=HANDSET&destination=SHORTCODE&message=Test':
smsbox.log:2006-07-15 12:55:10 [8487] [9] DEBUG: Query:
source=HANDSET&destination=SHORTCODE&message=Test
smsbox.log:2006-07-15 13:01:22 [8487] [9] DEBUG: Parsing URL
`http://URL/?source=HANDSET&destination=SHORTCODE&message=Test':
smsbox.log:2006-07-15 13:01:22 [8487] [9] DEBUG: Query:
source=HANDSET&destination=SHORTCODE&message=Test
As the log above displays, I sent in two messages (both saying "Test")
to the shortcode, 1 minute apart. I was some minutes (between 3 and 8)
minutes before either of those messages were routed to the URL for that
shortcode. During this time we were successfully sending 100s of MT
messages (pushed using the HTTP interface) to handsets to the same SMSC
as I would have sent the above message from (i.e there's only one for
that carrier), but on a different shortcode and from a different server
(i.e. an entirely different service!).
ok, this seems to be the issue when you load the MT side heavily, and the HTTP
calling thread inside smsbox is set to "pending", since resources (cpu time)
have to be shared.
I agree that a heavy loading of one side (MT) should not "block" fully the other
side (MO).
We currently don't handle this extreme situation.
One solution is to use several smsbox'es connected to the same bearerbox. This
can balance out the load on the single smsbox.
It appears that restarting Kannel wipes the queue of messages, as any
sent between restarts are happily accepted but never routed. I have
started using the store file to see whether that makes a difference.
correct, smsbox's internal HTTP calling queue is _NOT_ persistant. Which means
if you restart the box while in heavy load, the waiting messages to be called
will get lost.
We need to addapt store file mechanism to smsbo too. Some guys have such
versions in private branches (namely Alex and me). But this needs to get merged
into the official tree.
It's also worth noting that the service with the MT messages also
requests DLRs (down to deliver to handset), so for every MT message
there are 1 - 2 MO messages with DLR information. These also apparently
get queued, in favour of the outgoing MT messages.
yep, MO and/or DLR HTTP calls are the "same" for smsbox.
Is there a way of prioritising MT messages to be a lower priority to MO
messages? Or even prioritising services one over another? Or perhaps
this is a file descriptor problem -- would increasing the number of FDs
allow more messages to be sent during a given time? Have you any other
ideas / experience?
no, there is no current way in setting priority policy. You'll need to use more
smsboxs connected to the bearerbox and let the system balance over them.
Stipe
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
