RE: Bearerbox is not shutting down on command.

[Oded Arbel]

 

-----Original Message-----
From: Nisan Bloch [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 4:04 PM
To: Oded Arbel; Kannel-devel (E-mail)
Subject: Re: Bearerbox is not shutting down on command.

Hi
At 12:41 PM 8/19/02 +0300, Oded Arbel wrote:

yup, we have had this problem at times as well, it happens more if we try and shut bearerbox down from the console (with a break if running in foreground, or a kill).. We  never get it happening when we shut bearerbox down via the http interface. When this does happen with us we generally have messages or acks queued in bbox or the smsc modules.

Nisan

Hi list.
 
I have this problem , that from time to time, bearerbox does not shutdown when receiving a signal or the command to shutdown from the HTTP interface. I think I tracked it down to smsboxc_run(), which is doing this :
<snip>
wait_for_connections(fd, run_smsbox, incoming_sms);
</snip>
 
now, wait for connections is doing this :
<snip>
 /* XXX: if we are being shutdowned, as long as there is
  * messages in incoming list allow new connections, but when
  * list is empty, exit
  */
 if (bb_status == BB_SHUTDOWN) {
     ret = list_wait_until_nonempty(waited);
     if (ret == -1) break;
 }
</snip>
 
which basicly means that ig the incoming_sms list, for some reason, has a message in it, but no procuders, and bearerbox has been called to shutdown, and so closed all the threads that consume from that list, the smsboxc_run() will look endlessly waiting for someone to extract messages from that list, and thereby cause bearerbox not to shut down.
 
I'm still not clear on how to resolve this. comments anyone ?
  

Well - what do you suppose should be done ? We have a workaround for that (the init script gives the boxes enough time to shutdown and then kill -9 them), but the problem still should be fixed.

 

If I understand whats going on here, then something like this happens : the bearerbox waits for sms/wap boxes to connect to it - firing a handler thread for each box connecting. all handler threads of the same type share a single message queue (incoming_sms in case of an smsbox). now, since the bearerbox creates handler threads with abandon and does not collect their ids or anything, there is never a notion of "all handler threads have terminated". so if there's a message in the queue but nobody is alive that extracts messages from the queue - the message will stay in the queue forever and none will be the wiser. If we had a "consumer" count on a list as we have a "producer", it would be easy to work around - when the consumer count drops to 0 , and we are in shutdown state - clear the queue and go home.

 

--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]

 

+972-9-9581711 (116)
+972-67-340014

 

::..
The Key to life is 'fast forward'. there are some bad parts in life, and the trick is to 'fast forward' through them to the good parts.
 -- Fishizm