[bind10-dev] interaction between 'active' module list and multi-process modules

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

we are currently working on two features that may conflict in their
effects; ticket #640 makes the configuration manager keep track of
which modules are actually running and which have stopped, and we've
been adding support for running multiple instances of the Auth module.

This has a potential problem; as the code is now, should one of the
auth instances stop, it would send a 'Auth is stopping' message, and
the rest of the system would assume that all of Auth has stopped. Of
course we'd run into the same problem for any module that could
potentially run multiple instances.

Depending on how we want to approach multi-instance modules in the
long run, I see several solutions to this problem (there may be more
than the ones below), each of which has their own advantages and
drawbacks; This, btw, is not only to keep an 'active module' list, it
can also be an issue of how to adress or configure instances
independent of each other.

1) Treat any extra instance of a module as a second class citizen;
they 'steal' their config from the first instance, and skip part of
the normal module protocol. For starters, they would not send a
stopping message, and they would not respond to config changes (they
would apply them, but they would assume the first instance reports any
errors). In effect, this would mean that for configuration and command
purposes, it would appear to the system that there is only one process
for this module, and the others would (pretty quietly) run in the
background.

2) Provide any instance with its own name; possibly auto-generated
(Auth1, Auth2, Auth3), but maybe even configurable. So instead of
running 'Auth' (or any module) multi-process, you'd actually configure
multiple modules, that happen to be the same binary. This would
require more work; we'd have to modify the basic code so that modules
get told what their names are, and figure out how to handle and
respond to naming conflicts. It would also require more configuration
activity to run them. But one could then configure 2 Auths to do very
different things.

3) Do some form of reference counting. If X modules of type Y start
up, there should be X messages to that effect, and when they close,
and the number does not drop to 0, it should still be considered an
active module. This has the advantage of 'hiding' extra instances, but
we'd need to make the messaging much more robust. Currently, if a
module simply gets killed, it wouldn't send a 'stopping' message. We
can make Boss respond to process deaths in this sense, but Boss is not
necessarily aware of every module (you can still start them by hand).
So the only reliable way would be on the level of the messaging system
(msgq does notice when clients disconnect, and I assume so would any
msgq replacement), but especially right now, msgq operates on an
abstraction level below 'modules', so putting in module-level
communication there seems like a break in abstraction (i think there
would be nice ways around it btw, but haven't really thought about it
much).


Note that these options partly overlap, and they don't necessarily
preclude each other; 2 could coexist with both 1 and 3 i think.


Discuss.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8vsXIACgkQ4nZCKsdOncXSCQCfarugRyW2yj5NZznlHPzhl1KI
dRUAn1UzlVVn90gPwNnSaSjemZYAff1j
=RLbq
-----END PGP SIGNATURE-----