I've notice this in the past as well. In our case it seems to occur when we send a large number of messages in "batch A" which causes messages to queue in the local file store. We use the kannel status monitor web interface quite often. When this occurs, the status page shows the number of queued messages increasing. At the same time, the sending rate of outgoing MT messages goes down. My guess is that kannel is spending more time writing to disk vs sending directly to the smsc.
When "batch B" starts, it appears that some of these messages are sent immediately instead of being cached in the local file store, which would resemble the LIFO scenario you described. I've been very curious about the logic kannel implements to decide when to cache messages locally and when not to. For what it's worth, this started happening less frequently for us when we began using redis for the dlr store. It is much faster than the mysql db we where using. Now this doesn't happen until we exceed 400 messages per second on a single kannel server. When we load balance multie kannel instances, we can reach nearly 1000 messages per second before this occurs. Hope this helps. Maybe someone can elaborate on that local caching logic. Jeff Thorn CEO Thorn Technologies, LLC https://www.thorntech.com On Sat, Oct 19, 2019, 12:15 PM Rene Kluwen <rene.klu...@chimit.nl> wrote: > Your observaction is a bit “odd” in the sense that by nature, Kannel > should send messages FIFO. > > > > The smpp smsc handles things differently as it takes the priority field > into account. The http smsc does not. > > > > Apart from that SMS in general is store-and-forward and a particular order > is not guaranteed so you cannot rely and that either. Even though that > wasn’t your question. > > > > You can consider this as a background – I know it’s not a definitive > answer, but maybe it helps. > > > > == Rene > > > > > > *Van:* users <users-boun...@kannel.org> *Namens *Louis Rouxel > *Verzonden:* zaterdag 19 oktober 2019 16:06 > *Aan:* users@kannel.org > *Onderwerp:* Kannel delivering MT in LIFO > > > > Hello there, > > > > > > I'm currently having issues with Kannel delivering MTs in LIFO (last in > first out) priority mode. > > > > I'm using Kannel 1.4.4 and filesystem directory spool storage (Debian > jessie, ext4). > > > > I'm submitting large amounts of messages (let's call them "batch A)" for > via cgi-bin/sendsms http endpoint; they all get ingested in the store. > > > > One hour later, some messages are still in queue, and I'm submitting a > large amount of another message (let's call them "batch B"), the same way. > > > > Both messages are sent without any priority defined. > > > > > > What I'm observing, in such situations, is that delivery of messages from > batch A are interrupted when batch B starts, Kannel is now only delivering > messages from batch B. > > Deliveries for batch A will only resume when batch B is finished. > > > > I've been trying to understand if Kannel "officially" working in LIFO or > FIFO, but can't really get a proper understanding. > > > > 9 years ago, Nikos seemed to indicate the queue should work in FIFO > > https://www.kannel.org/pipermail/users/2010-July/011951.html > > > > But that's really not what I'm observing. > > Also, I found someone suggesting a patch to make Kannel work in FIFO > instead of LIFO (that would confirm my supposition) > > https://stackoverflow.com/questions/37461349/kannel-queue-type > > > > But unfortunately this does not get a lot of attention, and I'm not very > comfortable changing the source code as I have no experience in C. > > > > > > What do you guys think? > > Can anyone confirm if Kannel is operating in LIFO and the behaviour I'm > observing is normal? > > Would anyone have a recommendation to achieve a FIFO behaviour without > taking too many risks? > > > > > > Thanks a lot, > > > > -- > > Louis >
