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