[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: alternatives to ETRN
Matus Uhlar wrote:
... (ETRN talk removed)
> I even thought about mail processing. NROUTERS is defined in
> /etc/zmailer.conf and contains number of routers running. I thought this
> number could be sometimes too big and someties too low on the same machine.
> Wouldn't it be better to make it virtual ?
> Maybe there should be main router listening on named pipe for
> smtpserver/sendmail which will only take incoming messages, put them to
> files (or will take just filename) and execute child routers which will
> process those messages. And it can have x to y child routers processing
> those messages (x and y defined in config file). comunications between them
> could go through unnamed pipe, and router will know when it should create
> new router (too much unprocessed messages in incoming queue) if it shouldn't
> fork (too big load average or too much routers running), if it should kill
> one of its childs (2 childs idle for given time) etc.
> I know this is just speculation but maybe will give you (Matti) good idea.
Perhaps. I do have thought of it, but not done anything for it.
Like with scheduler, the router needs to collect new jobs, and
then process them.
The way things work now, is to run a fixed size of set of router
processes all competing with each other on which job-file to pick.
If there would be a job-feeder master in scheduler style, it could
spot new jobs arriving (thru UDP/AF_UNIX/whatnot IPC mechanism, and/or
plain directory scan every now and then), and add them into the queue,
then to run a farm of router sub-processes feeding each with a new
job-spec in similar style to that of the scheduler/transport-agent
create bidirectional pipe, fork slave
start main job-acceptance loop; send
"#hungry\n" message to master
Notice appearance of "#hungry\n", and
feed job filename: "12345\n"
pick job filename, do the processing,
and report for more work ("#hungry\n").
... loop continues ...
Things will become more complicated, when the queue processing
wants to do also router resource management, for example by
starting up additional working routers, if the queue is long,
and to cut down the number of routers, when there is no more
work, and they have been idle for some preset time.
Would somebody want to do such code ?
> e.g. when smtpserver gets expn or vrfy, executes router with one command -
> router <addr>; it could also use named pipe
Not so easy at all.
The number of needed named pipes, and routers behind them
is not easy to predict.
Also security issues might greep up -- router process runs with
root privileges, and the current smtpserver/router interface is
essentially a bidirectional pipe thru which a set of shell commands
is sent down to the router, and responses are read by the scheduler.
> Matus "fantomas" Uhlar, sysadmin of one server at SANET Kosice, Slovakia
> E-mail: Matus.Uhlar@tuke.sk ; WWW: http://ccsun.tuke.sk/users/uhlar
/Matti Aarnio <email@example.com>