Re: [PATCH] emi2 reconnection behaviour

"Bruno Rodrigues" <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <02d101c25b8d$0ad9afb0$6e01290a@davikayak>
I was not aware that the other smsc modules do retry by default.

emi2 and AT2 (the ones I use) don't do it, so if you want to patch it to
have
them defaulted to retry=true, I'm voting ++1 :)


----- Original Message -----
From: "Angel Fradejas" <[email protected]>
To: "Kannel Developers" <[email protected]>
Sent: Monday, September 09, 2002 10:30 AM
Subject: [PATCH] emi2 reconnection behaviour


Hi all,

Attached is a patch to change the current behaviour of EMI2 driver when
handling connection errors.
I'm making EMI2 driver consistent with SMPP and SM/ASI behaviour and
configuration directives, while trying to fix a couple of things.

This is what the patch changes:

1) Removes "retry" smsc config directive for EMI2. It always assumes
reconnection, as the rest of drivers.
2) Adds a "reconnect-delay" directive, as SMPP and SM/ASI drivers: optional
time between attemps in seconds. It defaults to 10 seconds.

The reason for this changes (apart from making all drivers consistent), is
that current EMI2 handling of reconnection attempts is a mess.
Let me explain why:

1) It defaults to not retrying reconnection. That means that when you start
bearerbox, if a single EMI2 driver fails, the whole bearerbox refuses to
start. This is not acceptable for production use.

2) When it tries a reconnection (other than first time remember), it doubles
the time between attempts, until it reaches a fixed value. If you have
retry=yes it will grow until 64 minutes (!!!) and then settles on 60 minutes
(too much for production use).
Weirdly, if you have retry=no, it will also try to reconnect, but the time
between attemps grows only until 10 minutes.

Please, let me know comments and votes on this patch.

Thank you all.

Angel Fradejas
Mediafusión España, S.A.
[email protected]
www.mediafusion.es
Tel. +34 91 252 32 00
Fax  +34 91 572 27 08
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.