I solved this problem a long time ago by passing an environment variable
from the master process to the child process when the child process is
spawned indicating that the server is full. I used CYRUS_MAXCHILD, and
the child process already checks for the CYRUS_VERBOSE variable when it
starts in order to properly set the debugging level. If that variable
was set, then the child would output an error message indicating that the
server was full and to try again later. It would then close the client
connection and then exit.

A couple things to note:

1) I prefer the client to be notified when the server is full and not
simply get connection refused messages or have the email client just
sit there, appearing to hang, while the server waits for a connection
to become free.

2) My method worked, but it didn't take advantage of the process reuse
feature. Basically, the master process only gets one chance to pass
an environment variable off to the child process. So, once that
variable is set in the child, the child will always believe that the
max has been reached. That is why I had the child process go away,
as it is basically useless after handling that one connection.

3) If there was a good way for the master to notify the child process
on each connection pass (either when passing the connection to an
already available child, or when passing the connectioin to a newly
spawn child) what the current status of maxchild is, then it would
be quite efficient to send the server full messages, close the
connection and wait for the master process to hand it another. I
don't know enough about how the master and child process communicate
to know how to make this work.

Scott

--On Wednesday, February 05, 2003 12:57 PM -0500 Lawrence Greenfield <[EMAIL PROTECTED]> wrote:

   Date: Wed, 05 Feb 2003 18:51:35 +0100
   From: Sebastian Hagedorn <[EMAIL PROTECTED]>
[...]
   Wouldn't it be possible (and better) to refuse further connections
instead     of having to wait for them to time out? Maybe I haven't
thought this     through properly, but it seems to me as if that were
cleaner.

Yes, that would be desirable. The easiest way of doing this would be
to close the socket used to accept() new connections. However, it's
open in all of the children, so closing it is infeasible.

The next option would be to have master accept() and then immediately
close() the connection. This raises interesting blocking concerns and
is thus somewhat harder to implement.

Thus the current solution seems acceptable.

Larry


--
+-----------------------------------------------------------------------+
     Scott W. Adkins                http://www.cns.ohiou.edu/~sadkins/
  UNIX Systems Engineer                  mailto:[EMAIL PROTECTED]
       ICQ 7626282                 Work (740)593-9478 Fax (740)593-1944
+-----------------------------------------------------------------------+
    PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/

Attachment: msg10910/pgp00000.pgp
Description: PGP signature

Reply via email to