The description isn't very clear, i'll try to update it:
syntax: { line_number . thread_name: "[" action "]" }
1.main_thread: [start three independent threads thread1 and thread2
for taking care about p1, p6 and p9 branches + start p1, p6 and p9 at
once]
(Note: all threads will continue to work indepently until thay
start/stop all processes. The dependency layer should be completely
independent on atomic start/stop methods in control.c stuff)
2.thread1: [continue to start p2]
2.thread2: [continue to start p7]
2.thread3: [finished]
3.thread1: [start two threads thread1.thread1 and thread1.thread2 to
take care about p4 and p5 branches + start p4 and p5 at once]
3.thread2: [finished]
4.thread1.thread1: [start p8]
4.thread1.thread2: [finished]
5.thread1.thread1: [finished]
6. thread1: [finished]
I didn't expand the scheme totaly (in 1.main_thread and 3.thread1
steps) but i think it is possible to understand :)
Martin Pala wrote:
Agree. When i though about your proposal (dependency matrix) in the
past, i found, that best way could be to paralelize start-up process
as much as possible => make one thread for every independent process
branch/subtree to start/stop them. In the case that the branch has
two or more even processes dependant on one process, it could be
possible to start them at once. I hope following ascii-art will
explain its princip:
/ p4 - p8
- p1 - p2 -
\ p5
- p6 - p7
-p9
So the fastest way to start it will be:
1.) start three independent threads for taking care about p1, p6 and
p9 branch (all threads will continue to work indepently until thay
start/stop all processes). The dependency layer should be completely
independent on atomic start/stop methods (control.c stuff)
2a.) continue to start p2
2b.) continue to start p7
2c.) finished
3a.) start two threads to take care about p4 and p5 branch
3b.) finished
4a.) start p8
4b.) finished
5a.) finished
So following "algorithm" is as fast as possible and won't block whole
process if there will be some problem. By the way, there are yet
another two options:
I.) it could be possible to independantly monitor processes by main
thread on the background, but there must be some mechanism to
synchronize start-up progress with monitoring, so monit should know,
that some processes are under "maintanance" and that it doesn't make
sense to try start/stop them until present work will be done.
II.) just block main monit thread and wait until all the others
(start/stop of processes) will finish
Martin
Jan-Henrik Haukeland wrote:
Anyway, I still think that moint should suspend itself as litle as
possible in
the start program phase, max 10 seconds and if that doesn't work it
should
break out of the start-program+depend loop with a warning message in
the log.
Besides it will retry again on the next cycle anyway. This is better
than to
(worst case) sleep Run.polltime for a program. Monit should instead
then go on
to the next program that needs to be started.
Jan-Henrik
Besides if a program does not manage to create a pidfile in 10
seconds
something is wrong.
Not true. If you are doing some kind of connection testing, it may
well
take a full poll cycle to come up.
_______________________________________________
monit-dev mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/monit-dev
_______________________________________________
monit-dev mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/monit-dev
_______________________________________________
monit-dev mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/monit-dev