Some limitations in the "demo" patch I offered to activate the new process mgmt state machines (Note the demo disclaimer!):
I did not implement the AwaitingDependencies state to wait for dependent processes to stop before stopping. Also, if one process dies, its dependents should be restarted. Also, if we are told to "restartAll", can we just go through all the processes in whatever order they come from the iterator, or do we have to be smarter about it? If we just go through the list in essentially random (alphabetical?) order, all the dependents will restart twice (once when their number comes up, and once when their "owner" restarts). (it doesn't matter what order the list is in, the dependents will restart twice unless we know they are dependents and skip them...) Anyway, none of this is implemented yet. I did not implement any "blocking for state change" functionality in the xmlrpc queries. Also in the patch I did not implement the StartAll, StopAll, RestartAll functions. (This is coming, just didn't get to it yet). Until sipXconfig sets the version stamp, I am ignoring a version mismatch (proceeding anyway with resource check). I did a very simple retry after process fails. It will retry forever at slightly greater intervals. It will raise a low-level alarm each time, a higher-level alarm once (the third time it fails). I would like to at least check how long since the last restart, and reset the counter if the process seems to have stayed up for a while. Ranga suggested a way of saying "please let me die"; but currently there is no such mechanism. We are not capturing the output of the child processes, so the terminal which launches sipx can get pretty messy. On stop, all the stop scripts output their row of dots simultaneously with sipxsupervisor's own dots, and it doesn't look pretty! Cleanup will follow. sipXconfig does not recognize the new state strings yet, so it shows Unknown for Running, ConfigTestFailed, etc. Also, although start/stop through the GUI seemed to work, it caused an internal error each time (not sure if this is due to the xmlrpc not being quite right). On new system start up, no processes will be enabled. We may have to enable them manually (by editing the process-state files, or by using the GUI or sipxproc --start <process> (but not --startAll, since that doesn't work yet :-))) I have not completely ripped out old Watchdog code. ConfigTestFailed will be a process blocker now. It won't "try anyway", as it used to. So whoever owns the "afterhours" and "concurrentrelays" elements will have to add them into the appropriate schemas (if they haven't already). Work will continue on all these fronts, but be aware of them in case Scott commits what was offered last week. And although it is a long list of limitations - it does mostly work! Honest! Comments and suggestions welcome... Carolyn
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
