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