[16314] in Kerberos_V5_Development
KDC worker processes project
daemon@ATHENA.MIT.EDU (ghudson@mit.edu)
Thu Sep 16 15:44:42 2010
Date: Thu, 16 Sep 2010 15:44:39 -0400 (EDT)
From: ghudson@mit.edu
Message-Id: <201009161944.o8GJid0I009727@outgoing.mit.edu>
To: krbdev@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
I'm beginning a formal review of the KDC worker processes project,
ending next Friday. The project proposal is at:
http://k5wiki.kerberos.org/wiki/Projects/Parallel_KDC
The purpose of this project is to allow better KDC scalability on
multi-processor KDC hosts, or KDC hosts making use of slow database
modules. Possibly controversial aspects of the proposal are:
* The supervisor is very simplistic. It only knows how to propagate
HUP signals to children (all we do on a HUP right now is re-open the
KDC logfile), and how to terminate worker processes if the
supervisor receives a termination signal or any worker process
exits.
(Why terminate all workers when one exits, instead of restarting the
worker? So that the KDC has similar behavior on a crash with or
without worker processes. The goal of this feature is to provide
scalability, not to increase KDC uptime in the face of bugs.)
* If you use worker processes, you don't get network reconfigs. If
your platform supports IPv4 pktinfo (Linux or modern Solaris), this
is not a change in behavior. If your platform does not support
pktinfo, then the KDC will have to be restarted in order to
recognize newly added network interfaces.
* KDB modules will be closed in the supervisor just before forking and
then opened in each child by reinvoking initialize_realms(), which
will re-parse the argument list. I don't think it's a terribly
clean design that we combine argument parsing and realm
initialization, but we have such a tangle of realm options that it's
not trivial to separate them out.
* There won't be automated tests; it's just too hard. There will be
manual tests which will involve some temporary code modifications.
Because we only added this to the 1.9 slate a few months ago when
things had already gotten busy, implementation time is very limited.
So while it's fair to advocate for a more complicated design, also
consider whether the current design is better or worse than the status
quo.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
