We have encountered this very situation. The solution I settled on has multiple kannel servers configured with transmit binds. So a load balancer can hit any instance for sending MT messages. However, only ONE instance is configured with receive binds. My logic was that the SMSC will queue MO and DLR messages if this one kannel instance goes down. So we really don't need to load balance for receiving messages. Since all MOs are coming in to the same server, long messages will be properly concatinated. This works fine for us because the volume of MT messages we send is significantly higher than MOs. We queue the DLRs and process them asynchronously at our own pace so the one kannel server with receive binds doesn't get bogged down.
Hope this helps. Jeff Thorn CEO Thorn Technologies, LLC https://www.thorntech.com On Sun, Mar 29, 2020, 3:49 PM Antony Stone < antony.st...@kannel.open.source.it> wrote: > On Sunday 29 March 2020 at 18:42:12, Alexander Malysh wrote: > > > Hi, > > > > unfortunately you mixed two things together. > > Very probably. I didn't find the documentation too clear on this topic. > > > 1. Store support. > > It’s a snapshot of messages that Kannel has in his memory (RAM) > stored > > either on disk (spool, file) or in Redis. This store is used for a case > if > > Kannel crashes, then messages are not lost. This is _NOT_ shared between > > Kannel instances, but different instance can read store if first instance > > gone for long time. > > So, is this where the first-received part of a multi-part message gets > stored, > so that it can be combined with the second part when that arrives? > > You say that this is not shared between kannel instances - what happens if > two > instances are pointing at the same redis database, and each receives one > part > of the multi-part message? > > > 2. DLR support. > > It’s temp. DLR storage to storing messages where Kannel still > waiting for > > a DLR to arrive. DLR storage can be shared (like same MySQL DB and table) > > and if one instance receive DLR for the message sent via second instance, > > DLR will be mapped and processed (please set same SMSC-IDs for both > > instances/binds). > > Yes, this is working fine for me. DLRs are processed successfully even > when > kannel instance A sent the message and kannel instance B gets the DLR. > > > DBPool is just internal Kannel Database Pool that supports multiple > > databases and is used for all database accesses in kannel. > > So, if that's used for "all database accesses in kannel", why can't I use > the > MySQL connection which works for DLR, as the message store (which seems > only > to know about redis)? > > > I hope it’s a little bit clearer now. > > In some ways, yes, but I'm still wondering what is the solution for a load- > balanced pair of kannel servers where each receives a different part of a > multi-part SMS from the upstream SMSC. > > I don't see any way in which either of my servers could know that the > other > one has already seen the other part of the message, and therefore either: > > a) reject the subsequent part so that the remote SMSC delivers it instead > to > the "first" server, or > > b) forward the second part itself to the "first" server. > > So, what do other people do in such a situation? > > > Thanks, > > > Antony. > > -- > There are 10 types of people in the world: > those who understand binary notation, > and those who don't. > > Please reply to the > list; > please *don't* CC > me. > >
