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

[Michal 'vorner' Vaner]

Hello

On Mon, Feb 06, 2012 at 11:54:42AM +0100, Jelte Jansen wrote:
> 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.

I don't like this. Besides the issues Stephen pointed out, this will also
confuse the user. What if the user decides to shut down the „master“ one (remove
it from configuration)? Will another of the processes become master or will they
all be slaves? Also, this means more code in each module. I'd rather concentrate
the support for multiple instances to the infrastructure, if possible, and
minimize the amount of work we need to do for every different module.

> 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.

I believe we'll need to do this some time anyway, if we're going to support
views this way (eg. the same binary with different configuration and with some
kind of receptionist, or something). However, I don't think this is the way to
solve this current problem. If a user has 16 cores in the system and wants to
start 16 authoritative servers, there's no way in asking for 16 configurations
which are the same.

Currently, I start multiple instances by providing multiple components in boss
with the same configuration. They have different component name, but the same
address on the msgq. I'd like to change this sometime to something like:
set Boss/components/b10-auth/count 16

They can be given some kind of identifier, if it helps something, though. Or
they can use the address (not the group address) on msgq, and introduce
themself.

> 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).

What do you mean by hiding? That they are configured together as a group? I
don't think hiding is the correct word, but I'd definitely like to have it that
way.

Anyway, this is the second place we need something like signal about
disconnected msgq client (the first one was refcounting of sockets). I think
this signals we should really add it to msgq or whatever we want to use later
on. And if the msgq would be signalling „This one is disconnected“, it could as
well signal „This one got disconnected“ and be used as the introduction (and, if
some other module is interested, it could query it and ask what kind of module
it is).

With regards

-- 
A nuclear war can ruin your whole day.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120206/b16c28da/attachment.bin>