[bind10-dev] plan for "background loading"

[JINMEI Tatuya / 神明達哉]

I've checked the current progress of the scalable in-memory data
source tasks and considered how much we can do by the end of
September.  My conclusion at this time is "the basic updates to the
in-memory backend (the tasks in the current sprint, and the ones
already estimated) + background loading for full reload".  I suspect
we don't have time for implementing incremental updates (applying
diffs after IXFR or DDNS - at the moement we'll do full reload in
background).

I also suspect we can only have 1 sprint (possibly with some small
margin) for the background loading part.  This means we won't have to
prepare nicer abstraction as proposed in
http://bind10.isc.org/wiki/ScalableZoneLoadDesign; we'll need some
workable solution that may be less cleaner but can be implemented
sooner.

So, I propose the following approach:

- update the ConfigurableClientList class so we can do zone loading in
  multiple stages: divide the current reload() method into:
  loadZone(), replaceZone(), and unloadZone().
  - loadZone() loads a new version of zone into memory, but does not
    really link it to the zone table, just remembering a reference to
    the loaded image somewhere in the class.   This can take long time.
  - replaceZone() swaps the current and new version of the zone in the
    zone table.  This is assumed to be an "instant" operation, not
    suspending incoming queries too long.  After swapping the
    versions, a reference to the old one is recorded somewhere in the
    class for subsequent unload.  It returns some ID for that as the
    method's return value.
  - unloadZone() releases memory resources of the old version of the
    zone.  To specify the old one the caller passes the ID returned by
    replaceZone().  This can take long time (could be tens of seconds).
- introduce a new class (say "ZoneLoader") running on a separate
  thread:
  - b10-auth spawns a new thread to run the loader class.
  - b10-auth and the loader share the same ConfigurableClientList with
    a lock.
  - the loader is normally sleeping on a condition variable or read on
    a pipe (with auth) or something
  - when auth receives a loddzone command from other modules, it wakes
    up the loader with the information of the zone to be reloaded
  - the loader loads a new version of the zone using loadZone().
    Since the loaded image isn't used for query processing until
    replace(), the loader doesn't have to acquire a lock for the
    ConfigurableClientList.
  - when loadZone() completes, the loader acquires a lock for the
    ConfigurableClientList, and swaps the two versions by
    replaceZone().  It the releases the lock, and destroy the old
    version by unloadZone().  After that the loader sleeps again.

Note that auth needs to acquire the lock everytime it uses
ConfigurableClientList including for every query processing.
That's not good for performance, but this shouldn't normally cause
contention so hopefully the contention-less lock is reasonably cheap.
And, hopefully, we can replace this intermediate solution with more
sophisticated shared-memory version relateively sooner.

---
JINMEI, Tatuya