[bind10-dev] proposed design of scalable in-memory zone loading/updating

[Shane Kerr]

Jinmei,

On Wednesday, 2012-06-27 11:58:35 -0700,
JINMEI Tatuya / 神明達哉 <jinmei at isc.org> wrote:
> > A final consideration is whether we want to have multiple Memory
> > Event Handler instances per process. The use case here is when we
> > are loading a large zone and don't want to block updates to other
> > zones. It may complicate the design slightly, but if we don't
> > include it now and add it later it seems like it may be quite a bit
> > of work to refactor around this idea.
> 
> I believe it's possible with the initially proposed design and a
> single Memory Event Handler:
> 
> 1. auth forwards "replace(full load)" command of zone A to the handler
> 2. the handler starts the replace task, creates (some kind of)
>    continuation context for it and returns it to auth
> 3. auth periodically resumes this incremental task.  everytime the
>    handler makes some progress on replacement
> 4. before the replacement is completed, auth receives an "(partial)
>    update" command of zone B.  auth forwards it to the handler.
> 5. handler immediately completes the update task and returns the
>    result to auth, the in-memory client will use the new version from
>    this point
> 6. the handler still continues the replacement task as it's resumed by
>    auth
> 
> If A != B (which should be the normal case in this scenario), this
> should be safe because the corresponding memory regions are completely
> different.  If A == B we'll need to handle it as a kind of error
> condition (rejecting the latter update or aborting the replacement,
> etc).

This approach makes sense to me. Back to co-operative multi-tasking! :)

Seriously this is quite reasonable, at least as a first pass. If we
need improved performance we can consider increased parallelism,
although this is probably something more for consideration in the
shared-memory model.

Cheers,

--
Shane