Mysql with short wait_timeout

Alexander Malysh amalysh at
Tue Jul 28 18:03:03 CEST 2009

just add store support to inmemory DLR and you are done...

but I'm --1 to keep DLRs in memory _and_ in storage. You choosed to  
use external storage to keep
memory footprint low...

If you say: I will keep DLRs in memory while DB not available then you  
should start thread to check DB availability
and add DLRs to DB. What will you do if kannel will told to shutdown  
but some DLRs still in memory and DB not available?

This will be tooo compilcated for nothing. IMHO if you told kannel use  
DB storage then DB storage _must_ be there. It's the same
as with any DB based applications (DB not available -> application  
doesn't run).

Kannel could send temp errorcode in case of DLR DB failure but not all  
SMSCs support this and there is a risk that this DLR will neverever
arrive again. And if kannel panic then you at least see that there  
something wrong with your DB ;)


Am 28.07.2009 um 17:05 schrieb Alejandro Guerrieri:

> 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
> aguerrieri at
> On 28/07/2009, at 16:31, Mathieu Bruneau wrote:
>> On Tue, Jul 28, 2009 at 3:32 AM, Alexander Malysh  
>> <amalysh at> 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
>> rounoff at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list