IMHO, the whole dlr approach should be refactored to work in a dual
"memory/storage" mode.
On my hypothetic view, DLR's would be looked at in memory first, and
if it's not found it would be looked at the storage.
With an approach like this, if the storage fails, DLR's would be still
kept in memory. The DB connection would be retried of course, but
DLR's wouldn't fail (they'd be lost if kannel is shutdown and the DB
is failing of course).
An option for a file-based storage would be possible as well, avoiding
the dependency on an external DB engine for DLR's.
Opinions?
Regards,
--
Alejandro Guerrieri
[email protected]
On 28/07/2009, at 16:31, Mathieu Bruneau wrote:
On Tue, Jul 28, 2009 at 3:32 AM, Alexander Malysh
<[email protected]> wrote:
Hi,
I don't think there is something to fix. Kannel checks connection
before using it and then try to reconnect if needed.
If your mysql instance is not allowing to connect anymore then
kannel has only 2 options:
1) panic, this is what we doing now
2) try to connect in a loop with some timeout and if reconnect was
not successfull panic.
timeout should not be too big becuase otherwise SMSC will
timeout PDU and try to resend it.
If you would like to fix this somehow then option (2) is to go.
Thanks,
Alex
Interesting, if you can't store the DLR, maybe you should time it
out and so that the SMSC try it again later ? Just like a mail
server would do... However I see it coming, that some people would
want to ignore DLR and just accept the messages anyway.
--
Math
aka ROunofF
[email protected]
