On Mon, 2004-04-05 at 19:49, Matti Aarnio wrote: > > Now, smtpserver will inject jobs to the router farm over the socket, the > > router pass it to the scheduler, again, over another socket, and > > [scheduler] pass it to the transport agent much like it does now *but* > > over the socket rather than pipe. > > Here I got a bit confused, do you mean "pass the message file over > the socket" or just (as we already do with notifications), tell about > new jobs available in the queue ? I mean that the *file name* is (always) passed over between different processors. Like it is now (but this could become the *only* way to inject a job, startup/periodical directory scanning being done "externally"). > > On reboot/restart, a separate ("run once") process can traverse queue > > directories and inject old jobs emulating smtpserver for the router, and > > another one emulating router for the scheduler. > > This is for the external persistent queue model. Any further thoughts > about how that persistency could be implemented ? I suggest it for "internal" case as well. > > The only bottleneck continues to be the scheluler, but even that > > will need half as many descriptors as it uses now. > > Half of one descriptor per transport agent is ... integresting ;-) > I think you have missed the quirks in lib/pipes.c (formerly in > scheduler/pipes.c); when ZMailer is being compiled in a system with > socketpair(2) call, it will be used. The fall-back will use classic > pipe(2), that are unidirectional, and are needed in pairs. > (Presumption is, that if the system doesn't have socketpair(2), > things are grim indeed...) Guilty, Your Honor! I was unaware that pipe() has been replaced with socketpair() > > If sockets are used to pass queue object handles, then the current file > > approach is quite easily extended to database approach, only interface > > functions will change, not the "business logic" code. Having queue > > objects in a database would (theoretically) allow to keep queue on one > > physical server, smtpserver on another, router on the third, etc. All > > of them would communicate over tcp sockets and access actual message > > data via particular database API. > > Uh.... I do know that Oracle has a product doing something quite like > what you describe, but would it a) really make sense, b) be lightweight > enough to be worthwhile without huge server hardware ? It just becomes theoretically possible. And it *may* be еру way to scale the system up to the size of Yahoo mail, if anyone would want to. Eugene
This is a digitally signed message part