Re: [PATCH] Kannel bearerbox graceful restart support (via SIGHUP or HTTP admin command)

Am 20.10.2012 17:58, schrieb spameden:
>
> Just did small portion from my another e-mail.

thanks. Though, a lot more people should be doing this. Seems I will 
need to make a big announcement for it, after releasing Kannel 1.5.1 
devel. ;)

> Thanks, will test this. What If I have smsc1 with queue of 1k sms
> (queued already) and I'm gonna change it's ID to smsc2, will it continue
> or message queue gonna be broken on smsc1?

ok, let's play through the example:

If smsc-id = A has a queue because the upstream connection is slower 
then the MT stream coming ahead. And then you change the smsc-id = A to 
B in the config, and cause a graceful restart.

Now, the logic goes like this: bearerbox reads in the new smsc groups 
and iterates over all smsc groups. When we reach smsc-id = B now, then 
we first try to detect if this is a group that didn't change at all. We 
do this via the pre-computed md5 hash checksum. Obviously this can't be 
the case, so we go on. Now we look for any smsc-id = B in the existing 
(running) config. If it is present, then it's marked to be shutdown. And 
in any case smsc-id = B is started.

Ok, and now we need to keep track of the "left ones" from the existing 
config. I.e. if in the new config there is no smsc-id = A, which we 
assume, since we changed only the smsc-id from A to B, then the smsc-id 
= A must be shutdown too, due that it is not present in the new config.

And what does this mean effectively? It means smsc-id = A is shutdown. 
This ensures that all MTs in the smsc scope queue are reverted back to 
the main abstraction layer queue of bearerbox, (for the routing step 
again). And smsc-id = B is started.

IF the allowed-smsc-id config scope of smsc-id = B allows the messages 
that have been re-queued into the abstracter layer, then bearerbox can 
route them again into B.

I hope this clears the question.

Another usage example: "Re-direct already routed MTs in a queue to an 
other route"

Ok, let's assume your smsc groups are "hard-wired", which is a term I 
like for the case that:

   group = smsc
   smsc-id = A
   ...
   allowed-smsc-id = A

   group = smsc
   smsc-id = B
   ...
   allowed-smsc-id = B

   (...etc...)

and you have a queue in A, i.e. because something is going on in the 
SMSC of A and the throughput is slowed down drastically. Let's assume 
you would like to revert all pending queued MTs from A to B, because B 
has enough capacity right now.

How would the config change look? It would look like this:

   (removing smsc-id = A)

   group = smsc
   smsc-id = B
   ...
   allowed-smsc-id = "B;A"

   (...etc..)

Effectively, A is shutdown, MTs in the queue are setup to be routed 
again. B has changed, so B is shutdown, but also started again. And then 
all MTs from A can go to B.

B has to restart here, even while there is no real need, so this leads 
us to a new idea:

We split the md5 hash into 2 parts, one is for the pure "logical 
connection", hence incorporating the host, port, username, password, any 
SMSC relevant options etc. The other one are the "routing parameters" of 
bearerbox, so, allowed-smsc-id, denied-smsc-id, etc.

This allows us to detect if the "logical connection setup" changed, 
or/and the "routing setup". If it is "only" the routing setup, then we 
can "move in" the new values from the reloaded group, rather then really 
having to shutdown, destroy, create the smsc instance again.

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
-------------------------------------------------------------------