Am 07.08.2012 23:43, schrieb Alan McNatty:
Hi Stipe,
Sounds great - as you say being able to use disk based replication
techniques would be good but also providing persistence as a default
option is also very valuable. I'll be keen to do some tests on IO
performance - my biggest concern for larger installs (as often disk
choice is not necessarily under our control).
If anyone cooks up any test scripts to analyse please feel free to share
(as I will). I'm just trying to think of an easy way to generate several
thousand in the DLR store and have them all expire (identical validity
period or similar).
Thanks again Stipe - nice work!
Hi Alan,
thanks a lot.
In fact I'm also providing a patch to the mailing list shortly that
includes 2 new methods for the DLR abstraction modules, implementing the
functions:
- size_t dlr_purge(time_t t) : removing all entries that are older then
t seconds, and providing the ammount of removed entries. This can be
used via the HTTP admin interface to "purge" all zombie DLRs from the
storage. Normally people need to do this via external logic, i.e.
scripts calling DELETE something calls for their DB storages. Via the
HTTP interface making the method homogenate for all DLR storage
implementation is a much cleaner approach IMO.
- size_t dlr_clean(time_t) : the same logic as above, BUT in addition it
sends a DLR event 2 (delivery failed) DLR to the smsbox. Which means we
provide a callback mechanism for any smsbox connection that wants to
ensure the back-end ESMEs (HTTP or SMPP EMSE) get informed about the
"final state" that the DLR was never confirmed from the upstream SMSC
and we (Kannel) consider it as not delivered.
Cheers,
Stipe
--
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
