On Jan 4, 2011, at 22:42, Glenn Knickerbocker wrote: > On Tue, 4 Jan 2011 22:05:18 -0500, Bob Cronin wrote: >> On Tue, Jan 4, 2011 at 8:58 PM, Paul Gilmartin <paulgboul...@aim.com> wrote: >>> No, because once it's processing a spool file, it is no longer the one >>> with the fewest total spool files, and some other worker will be chosen. >> Not necessarily, it depends on the timing of the queries. > > If it hasn't finished processing a file since your last query, on the > next query it will have at least one more file than any of the other > workers that had the same number before. If it has, then it's not > overloaded, so why worry? > Have you ever gone to a bank where there's a separate line before each teller's window. The best you can do is to stand in the shortest line, only to discover that the person ahead of you has a complicated transaction and your line stalls while all othes flow along.
The OP proposes that when there's a tie for the shortest line to pick one at random. This doesn't help at all. And unlike the bank example, it's complicated for a task to jump to a different server when one becomes idle. Better to implement a true single-queue multi-server protocol. When each worker becomes available and idle it writes its identifier to a FANINANY stage. The task dispatcher reads a task from the input queue, stalling until one is available. Then it reads a record from the FANINANY, again stalling until one is available. It assigns the task to the worker and loops back to reading the input queue. Processing of each task will begin in order of arrival; the best FIFO that can be implemented. One might buffer the output of the FANINANY with an ELASTIC stage to guarantee that workers are activated in the same order that they became idle, if that's desirable. Or is that built in to FANINANY? One must buffer the task queue with ELASTIC so submitters don't stall. I haven't looked at THROTTLE REXX. -- gil
