Summary:	ASTERISK-00970: [patch] Start/stop messages on cli 'sip reload'
Reporter:	Olle Johansson (oej)	Labels:
Date Opened:	2004-02-02 02:15:00.000-0600	Date Closed:	2011-06-07 14:11:57
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sipreload.txt
Description:	Print out messages before starting a reload and after finishing up. When you have over 1000 users, it takes time and the CLI becomes non-responsive. Better to warn the user that something is going on even if you have the CLI prompt active.
Comments:	By: Brian West (bkw918) 2004-02-04 00:51:10.000-0600 Do we really need to thank them? :P By: Tilghman Lesher (tilghman) 2004-03-29 13:36:06.000-0600 We should probably add a timer here and only thank them if the reload takes longer than a minute.  We can also use that timer to tell someone issuing a 'sip reload' which is blocked just how long the previous reload has been executing. By: slepp (slepp) 2004-04-02 02:58:55.000-0600 I agree with Corydon on that one. By: twisted (twisted) 2004-04-02 23:46:44.000-0600 That would make sense.  If the reload takes less than a minute, hopefully it would be transparent to the user/operator.  If it's going to take longer, we should let them know that when it's done, and if they try to execute again, let them know it's already in progress.  I agree with Corydon76. By: James Golovich (jamesgolovich) 2004-04-04 20:14:58 None of the other reload functions do this, so do we want to set precedent on this where anything taking longer than X prints a message? Worse than sip.conf is a large extensions.conf By: slepp (slepp) 2004-04-04 20:45:10 I think it's not a bad precedent to set. Or maybe it's just time to begin rewriting parts of the configuration handlers to not be quite so slow (strcasecmp() isn't the fast thing in the world), by perhaps implementing hashing or such. Is that the problem with this SIP reload? It takes longer to parse the config than anything, or is it a problem that cannot be optimized by configuration design? By: Olle Johansson (oej) 2004-04-05 03:19:12 Very good suggestion, but over my head. Any coders? By: James Golovich (jamesgolovich) 2004-04-05 03:35:30 The current solution to that is to use something like the mysql_friends type stuff.  I would expect that sometime in the future we will have a better alternative. By: Mark Spencer (markster) 2004-04-26 09:30:01 I don't think this is that big a deal.  The "real" asterisk console won't give you the CLI prompt back until it finishes.  Maybe that's what we should do with asterisk -r as well. By: Olle Johansson (oej) 2004-04-26 09:56:56 Being stubborn... With over 1000 SIP clients with voicemail boxes, this is a big deal. Running asterisk -r Asterisk seems dead non-responsive for a long time. We need to tell the user to wait and greet him somehow when Asterisk is listening again. Agreed, this is "asterisk -r", but it's a problem. By: Brian West (bkw918) 2004-05-01 01:19:33 Does asterisk really need to say thank you ? :P haha bkw By: Brian West (bkw918) 2004-05-01 01:41:54 WE all took a vote and agree with james...  Why sip reload when the rest of the comands don't print anything similar.