On Mon, 2009-11-16 at 13:06 -0500, Damian Krzeminski wrote: > Scott Lawrence wrote: > > [...] > > >> I suspect sipXconfig implementation would be simpler if sipXalarms were to > >> be separated from sipXsupervisor. At the moment we have a special case for > >> configuring alarms in the sipXconfig code and it has already caused several > >> issues (recently: http://track.sipfoundry.org/browse/XX-6970). > >> It's not directly related to adding alarm functionality but it seems we > >> would be adding even more config files for alarm service, which is trivial > >> if this is a 'normal' service and complicated if it's a sipXsupervisor. > > > > I don't see what the problem is with the above; integrating the alarm > > monitor into sipXsupervisor. The particular issue you cite seems easy > > to me - the replication of that file happens through sipXsupervisor > > anyway; it should be able to notice that fact and reload the definitions > > without any other prompting. > > > > It is a problem: sipXsupervisor cannot be started or stopped like other > services (because it's doing starting and stopping): it needs to be treated > differently.
I think that the supervisor function and the alarm monitor function are similar in that they are both things you never want to stop anyway. > sipXsupervisor detecting changes to its config files would not solve > anything. Part of the problem - uncaught be testing yet - was that > sipXconfig did not push all the files to a newly added host. I don't see how that's relevant to whether or not the alarm monitor should be a part of the supervisor... if sipXconfig is not pushing all the config files to a new host that it needs to, that's just a bug, not a design constraint. Perhaps we're talking about different things? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
