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

This is awesome.

I'm looking fwd into testing this as soon as i have time.

2012/10/21 Stipe Tolj <[email protected]>

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