Hi Stipe,
Thanks for this patch. By the way David Schneider sent a patch to the devel
group on Tue, 31 Mar 2015 11:49:47 +0200.
When you are committing your code, please consider reviewing his patch as
well and commit it if you think it's necessary.
If developer's patches are ignored they will
Hi list,
when having a high IO scenario, i.e. a lot of DLRs coming in from the
upstream SMSC side, and the smsbox connection vanished, then the thread
gw/bb_box.c:sms_to_smsboxes() is most likely in the gwthread_sleep()
loop captured. If we SIGTERM bearerbox it will iterate one more time,
server module accepts
HTTP reuqests, they are processed and queued in the internal gwlist struct for
the upstream (bearerbox).
So, we either need to make that queue persistant, aka store-file, spool-dir
usage, or as a first punch, make sure we handle the internal thread shutdown
logic in smsbox
would be stopping to
accept new HTTP connections in the smsbox.
I've implemented this behaviour, but is this wanted?
My way:
1) Send a (new) HTTP Shutdown message to smsbox, making it shutting down the
HTTP ports (currently brute force, I'd prefer to implement this in a
way only shutting
implemented this behaviour, but is this wanted?
My way:
1) Send a (new) HTTP Shutdown message to smsbox, making it shutting down the
HTTP ports (currently brute force, I'd prefer to implement this in a
way only shutting
down idle connections).
2) Terminate SMSC connections
3) Really shut
Rodrigo Cremaschi schrieb:
Hi Georg,
Maybe you already tried this:
1) Set Kannel to 'isolated' state.
2) Set Kannel to 'suspended' state.
3) Set Kannel to 'shutdown' state.
Hi, thanks for this!
However, I want to protect messages from the smsbox HTTP interface to be
protected from
If you do kill bearerbox twice in a row, SMSbox looses its
connection and kills itself pretty immediately. And when SMSbox gets
killed, then theres for sure no one to accept any http connections.
in other words, when you kill SMSBox first, there is no way any
messages will be delivered.
