[bind10-dev] MSGQ-NG requirements

[JINMEI Tatuya / 神明達哉]

At Fri, 13 Apr 2012 08:46:40 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > > Well, if we couldn't pass our configuration and all this we pass
> > > through it now, the msgq would be pretty useless.
> > 
> > I do not necessarily think so (while I agree that it's convenient if
> > we can assume a single interface with the ability of passing any
> > amount of complicated data).  In an extreme end of this approach, we
> > could even store zone's RRs as part of "configuration" and pass them
> > over msgq.  But I don't think anyone say it would be "pretty useless"
> > if it couldn't be used for that purpose.  So, it's a matter of the
> > balance between the convenience of using a single unified tool and its
> > cost.
> 
> Well, what I mean is this: What else do we pass through the message queue than
> configuration and statistics?

In the case of the zone data (RRs) and possible some other zone
specific configuration, in a backend database.  For statistics, I must
say I'm not so sure, but we could also store it in a backend database
as part of zone specific mutable data.

> So if we couldn't do that, there'd be nothing much
> left for MSGQ to do.

(configuration over) msgq will be still usable for reasonable scale
stuff: port configuration, probably at least global ACLs,
configuration information of data sources, etc.  So it seems to me
much more than "nothing much".

> And I believe the only thing we need to ensure is we do not
> block reading the large message, therefore even if it was only a convenience, I
> think it would still be worth it (we can write a lettuce test to check such
> things).

Non blocking operation on a large amount of data is a minimum
requirement, rather than the only thing.  We don't want to see a large
delay at startup or reloading.  We need to ensure consistency between
any stored information in a database (right now, at least a list of
zones) and any secondary copy of it.  These just seem to be open to
me.  having a full copy in b10-config.db of any large amount of data
and distributing it over msgq may be a workable solution, but to me
it's not so obvious.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.