| Summary: | ASTERISK-18688: Reloads with large dialplan cause peers to go lagged | ||
| Reporter: | JoshE (n8ideas) | Labels: | |
| Date Opened: | 2011-10-06 16:20:00 | Date Closed: | 2016-04-21 14:34:52 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | 1.8.7.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | When doing 'module reload's with a fairly large dialplan (700k) and sip.conf (250k), peers will erroneously report as lagged after the reload is complete. This clutters my logs and makes it difficult to troubleshoot legitimately lagged devices. | ||
| Comments: | By: rsw686 (rsw686) 2011-10-08 13:22:37.052-0500 I've experienced this same issue running sip reload with 1.8.7. Right now I have 284 online peers and 376 offline peers. I was previously running 1.6.1.18 and had no issues with reloading. When reloading for a few seconds calls will go to voicemail as Asterisk thinks the peer is unavailable. I also see hundreds of Peer xxx is now Lagged and Peer xxx is now Reachable messages on the console and in the logs. This is a major regression as I can't reload during business hours. By: Leif Madsen (lmadsen) 2011-11-01 09:01:39.052-0500 Are you logging to the console screen or a logfile when doing this? I've experienced this same thing all the way back to 1.2 as when you output the large dialplan to the console, it takes a lot longer to reload (and there is locking going on when the reload happens). By: Leif Madsen (lmadsen) 2011-11-01 09:02:07.656-0500 Can you provide an overly large dialplan and sip.conf file that would experience this? How else do you have logger.conf configured? By: Leif Madsen (lmadsen) 2011-11-21 14:12:40.270-0600 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines By: Matt Jordan (mjordan) 2012-05-11 16:45:27.959-0500 n8ideas requested that the issue be reopened and would provide a sip.conf, extensions.conf, logger.conf, and a DEBUG log illustrating the problem. By: JoshE (n8ideas) 2012-05-11 17:08:36.426-0500 So a few updates. The total dialplan, including inserts, is around 1.5-2 MB. I have around 1200 peers on this box, with around 800 or so online at any given time. The logging is set up as follows: logger.conf: console => notice,warning,error messages => notice,warning,error full => notice,warning,error,debug,verbose When issuing a reload via AMI, a number of my extensions will always go lagged. In addition, if I have subscriptions to affected devices, they go Unavailable for a period of time when the peer is lagged. As a note, the reload takes a few seconds to complete. It appears that qualifies that happen while the reload is being processed prevent any of the QUALIFY messages from being processed. By: JoshE (n8ideas) 2012-05-11 19:38:08.319-0500 As a further note, it appears that this issue only occurs when reloads are done via AMI. Reloads that happen via the CLI directly don't exhibit the issue. By: Leif Madsen (lmadsen) 2016-04-21 14:34:53.023-0500 Closing this (again...) due to age and lack of feedback. CC: @rnewton | ||