[asterisk-dev] [Code Review] Provide means to notify manager sessions that all modules have finished loading

[Terry Wilson]

> On 2010-05-01 15:35:09, Russell Bryant wrote:
> > Can you think of a reason why we shouldn't just not accept AMI connections until Asterisk is fully loaded?
> 
> Terry Wilson wrote:
>     I thought about this before posting and actually tried it out and didn't notice any problems, but worried about what would happen if a module tried to fire an event before the manager was actually initialized. Although since the sessions container would be null, I don't *think* it would cause a problem. I'm just always wary of making a change like that in releases just in case I'm wrong. Although I suppose we could make that optional as well by putting an asterisk.conf option and calling init_manager where it is if it isn't set, and calling it later if it is.
> 
> raarts wrote:
>     I can think of only one reason why you'd want to connect earlier: diagnostics/logging. But if you want to do that, you need to make sure to be connected from the start, and how could you ensure that?
>     
>     And if modules want to send something during startup, that would be silly, because there's a fat chance that nobody is connected to receive it.
>     
>     So I would prefer not being able to connect unless asterisk is fully loaded. 
>     
>     
>     
>
> 
> Sean Bright wrote:
>     https://issues.asterisk.org/view.php?id=15189

raarts: Modules wouldn't necessarily be in charge of whether they "send something during startup". If the module is registered, it can be responding to an external action (like a SIP call, a peer registering, etc.) and would then try to send an event.

Sean: Ah, so we've tried moving manager initialization before and it failed? That sounds about right. :-) Thanks for the heads up. After working on "CDR fixes" and seeing all the regressions and unintended behavior changes that those have caused, it makes me cautious moving code around these days.


- Terry


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/639/#review1945
-----------------------------------------------------------


On 2010-05-01 01:35:28, Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/639/
> -----------------------------------------------------------
> 
> (Updated 2010-05-01 01:35:28)
> 
> 
> Review request for Asterisk Developers and Russell Bryant.
> 
> 
> Summary
> -------
> 
> It is possible to connect to Asterisk via the manager interface before all of the modules are finished loading. This can lead to manager actions failing because a necessary module hasn't loaded yet. One area where this is really annoying is when writing external tests.
> 
> This small patch adds a FullyBooted manager event which fires when Asterisk is finished loading the modules. Since it is possible that one would miss this event, it is also sent upon login if Asterisk is fully booted.
> 
> I also propose that we add this to all branches to aid in testing. For existing releases, I think it should be disabled by default and enabled via an asterisk.conf setting to avoid any behavior changes.
> 
> In the very unlikely event that someone successfully authenticates between setting of AST_OPT_FLAG_FULLY_BOOTED and the sending of the manager_event in asterisk.c, they would get two FullyBooted events. Personally, I'm Ok with that since we really only care whether or not Asterisk is fully booted or not. I can't think of any circumstances where we could actually miss a FullyBooted event, though, which is the important thing. If we need to bother with locking, we can do that too of course. :-)
> 
> 
> Diffs
> -----
> 
>   /trunk/main/asterisk.c 260520 
>   /trunk/main/manager.c 260520 
> 
> Diff: https://reviewboard.asterisk.org/r/639/diff
> 
> 
> Testing
> -------
> 
> Connected and verified that the Event fires (and that a well placed sleep() makes it fire twice). 
> 
> 
> Thanks,
> 
> Terry
> 
>