Alex,
Are you sure about that? AFAIK DLRs are saved to store, like any other MO,
until bb receives an ACK from upstream (smsbox, sqlbox, smppbox).
BR,
Nikos
----- Original Message -----
From: Alejandro Guerrieri
To: Konstantin Vayner
Cc: Users
Sent: Sunday, August 08, 2010 12:56 PM
Subject: Re: Large and growing number of queued DLR
Well, that poses some problems.
DLR's are a different animal than regular messages, they're not hold on the
message store. DLR's are by default held in memory or, if you wish to
persist them across restarts, you use DB storage. When you use a DB storage
DLR's are no longer held in memory.
Now, in order to reuse validity period, you'd need to have all DLR's in
memory at all times and that's only true for in-memory DLR's. For DB-stored
DLR's, since they're no longer in memory, all the operations are done over
SQL queries so you don't longer have the ability of traversing them in
memory.
The approach with DB-based DLR's is to run a query like this:
DELETE FROM dlr WHERE stamp < (NOW()-INTERVAL 5 DAY)
Now, if you use MySQL's MyISAM storage, that query locks the whole table, so
you need to be very careful when running it (we do it at low traffic hours
and we run it repeatedly with a LIMIT clause to make it return faster and
allow for the rest of the queries to unlock.
In other words, I wouldn't put that kind of query on a thread to execute
repeatedly unattended.
A possible approach would be to load all DLR's in memory when the service
starts, the same way it's done with the regular messages and the file store.
Once that's done, we'd be able to traverse the old DLR's without locking the
system.
Now, from a higher level perspective, this poses the question of the reason
why DLR's are treated different than the rest of the messages that pass thru
Kannel, but that's for another thread I guess ;)
Regards,
Alex
On Sun, Aug 8, 2010 at 7:56 AM, Konstantin Vayner <[email protected]>
wrote:
Alejandro,
Actually, kannel can reuse validity period and automatically issue (perhapse
configurable?) expiration dlr + wipe a message when a message is past that
period by some good value (lets say + 1 day - this should be more than
enough).
In fact we could issue another kind of dlr even - maybe "unknown" or smth...
this would both solve a problem with bb building up queue of dlrs that will
never be matched and aid external application logic imho
Regards,
Konstantin
On Fri, Aug 6, 2010 at 6:36 PM, Alejandro Guerrieri
<[email protected]> wrote:
Dlr's are far from perfect. Many carriers don't return it on all cases, so
it's logical that it'll eventually grow over time.
Check with your carriers what's the expected lifetime of SMS on their
network and run a query to clean records older than that period (if they
hold it for 3 days, you shouldn't be expecting any DLR's after that period).
If you don't know/can't answer, 5-7 days should be a safe ballpark figure.
Regards,
Alex
On Fri, Aug 6, 2010 at 4:09 PM, brett skinner <[email protected]>
wrote:
Hi
Sorry forgot to add that I am using mysql storage
---------- Forwarded message ----------
From: brett skinner <[email protected]>
Date: Fri, Aug 6, 2010 at 4:06 PM
Subject: Large and growing number of queued DLR
To: Users <[email protected]>
Hi
We have been sending sms successfully and receiving the DLRs. As far as I
can tell we have been processing them correctly and all the logs in the web
application point to no failures. I had a look at the logs for smsbox and
there were a couple of URLs that it could not fetch but those have already
been fixed and read in from the log file. However the DLR storage number is
still growing and there have been no further errors in the logs.
Is there a rate at which Kannel tries to post the DLR to the specified URL?
Is it perhaps because Kannel may have been restarted and now it has no
knowledge of those DLR because the information that it needs to do the look
up is now gone?
Regards
