Re: [Clockwork-developers] Decision time

[Joel L. <jo...@lo...>]

+- On Tuesday (3/12/2002 20:40) "Shawn Dvorak" <sd...@cf...> Wrote-
| Perhaps we could make a compromise, with
| some number of distributed servers responsible for collecting scheduling
| statuses from a subsets of servers.  These collector servers wouldn't do any
| dispatching; they'd only collect job status broadcasts/unicasts from the

If multiple systems would do the dispatching, then how would we determine
which system would dispatch a given job?

I'm in agreement that it would be great not to have the single-dispatcher
bottleneck, but all the solutions I can think of involve a lot of
constant communication between the scheduler nodes, and it seems like there
would be a fair amount of risk that something would get out of sync. Then
again, even the centralized design would require some sort of failover
replication, so maybe it wouldn't be _that_ much more work to design
a system that has N schedulers instead of 2.

But it sure would be nice if you could distribute the schedule-processing
load just by, say, activating a few more nodes as schedulers. Sort of like
Legato Cluster -- you can promote as many nodes as you want to primary, and
they'll just start replicating the configuration among themselves.

I'm not opposed to this design, but I'd want to flesh out a plan for how
the GUI would manage the jobs and how the jobs would be dispatched before
committing to this approach.

Have you got any more detailed ideas for how to approach this?

-- 
Joel