The file spool store writes, reads and deletes a large number of small files in
rapid succession, which is very inefficient in journaled file systems. You can
increase the performance of the file store by using a separate partition
formatted as ext2. You don’t need a lot of space, a few gigs are
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
m
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
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 e
