Re: depend take 2

[Martin Pala]

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