Thank you all for your replays, We will switch to DB store in order not to lose any more DLRs from potential restarts!
But what about the second problem we have faced? BRs Justin 2010/7/4 Nikos Balkanas <[email protected]>: > Hi, > > DLRs are stored in the store-location, until further processed. However, > that's not enough. DLRs need to be matched to a dlr_entry created by bb when > SMS is sent out. Otherwise bb doesn't know to which SMS they are referring > to. If that dlr_entry is in memory and you restart bb, that memory is lost, > and therefore incoming DLRs, whose dlr_entry is missing are discraded. > > User's guide explains that. It also says to use DB dlr-storage if you want > your dlr-entries to be preserved across restarts. Else, you shouldn't > restart bb. > > BR, > Nikos > ----- Original Message ----- From: "Justin Cater" <[email protected]> > To: "users" <[email protected]> > Sent: Sunday, July 04, 2010 1:28 PM > Subject: Lost DLRs > > >> Hello all, >> >> We are using Kannel 1.4.3 Stable release in a major installation of >> one of our clients. Everything is working as expected except SMS >> delivery report handling (we are using "internal" delivery storage >> type - for performance reasons). We are facing two problems : >> >> --> After a graceful restart of bearerbox and smsbox all incoming >> delivery reports, for SMS messages sent before the graceful restart, >> cannot be handled . The error log is clear "DLR from SMSC<....> for >> DST<....> not found." Kannel latest documentation (Table 3-1. Core >> Group Variables) clearly states : >> >> "store-type filename Kannel can use store subsystem that means storing >> messages on hard disk until they are successfully handled. By using >> this subsystem, no SMS messages are lost in Kannel even by crash, but >> theoretically some messages can duplicate when system is taken down >> violently. This variable defines a type of backend used for store >> subsystem. Now two types are supported: a) file: writes store into one >> single file b) spool: writes store into spool directory (one file for >> each message) >> >> store-location filename Depends on store-type option used, it is ether >> file or spool directory. >> >> store-dump-freq seconds Approximated frequency how often the memory >> dump of current pending messages are stored to store-file, providing >> something has happened. Defaults to 10 seconds if not set." >> >> We are using "file" store type. After monitoring the specific file we >> noticed that records are written for every MT SMS we send, but >> immediately after sending the SMS (and before the delivery report is >> received) the relevant record is deleted! >> >> It seams like the "store-type" functionality Kannel provides is only >> for sending MT SMS messages and not for DLRs and DLR information is >> stored in memory only. Can you clarify that please? >> >> --> In some cases DLRs cannot be handled - with no obvious reason, as >> no WARN, ERROR, FATAL logs are recorded - (no restart of bearerbox >> and/or smsbox is performed here). We have monitored the log files and >> pinpoint that the issue is located in "dlr_find" method of "dlr.c" >> class. >> >> In particular for the same worker thread we see the >> >> "DLR[%s]: Looking for DLR smsc=%s, ts=%s, dst=%s, type=%d" >> >> but never see the >> >> "DLR[%s]: created DLR message for URL <%s>" >> >> although neither >> >> "DLR[%s]: DLR from SMSC<%s> for DST<%s> not found." >> >> or >> >> "DLR[%s]: Ignoring DLR message because of mask type=%d dlr->mask=%d" >> >> are recorded. >> >> It seams like the DLR is found but something happens while Kannel >> trying to create the DLR message for the callback URL! >> >> Due to the fact that this is an abnormal case and is not happening for >> all DLRs, can you please elaborate on the issue and clarify what can >> go wrong in the creation of the DLR callback URL? >> >> >> Thanx in advance >> >> Justin >> > >
