BIND 10 #2201: [meta] background zone loading in memory

BIND 10 Development do-not-reply at isc.org
Sat Aug 18 07:46:11 UTC 2012


#2201: [meta] background zone loading in memory
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:         |  Proposed
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  meta
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 First off: anyone who tries to work on any task that belongs to this
 ticket
 should read
 http://bind10.isc.org/wiki/ScalableZoneLoadDesign
 and
 https://lists.isc.org/pipermail/bind10-dev/2012-July/003695.html
 to understand the overall ideas.

 In this feature set we are going to make data source (re)configuration
 and zone reloading run "background" so it won't disrupt query
 processing.

 It's based on the idea of using a separate thread proposed in the
 second link above.  But since we'll have a bit more time for
 development in September than we thought at the time of email
 discussion, I also incorporated some of the ideas of the first link so
 we can migrate to the shared memory version without heavily rewriting
 other parts of the code.

 A key concept is the `(memory)ZoneUpdater` class (#2207).  It provides
 unified update interface regardless of the underlying memory segment
 implementation.  This allows both b10-auth (or possibly other data
 source user) and the generic data source implementation (more
 specifically, `InMemoryClient` which is hidden in
 `ConfigurableClientList`) to be agnostic about segment model details.
 In this task set we only use the local memory segment, but the idea is
 to minimize future changes to b10-auth and `InMemoryClient` or
 `ConfigurableClientList` when we support shared memory segments.

 Specific development tasks are as follows:

 - Preparation: thread and lock: #2202, #2205
 - Preparation: update data source configuration for auth: #2203, #2204
 - data source updates and enhancements: #2206, #2207, #2208, #2209
 - integration: #2210, #2211, #2212, #2213

 Feature-level goals are #2211 and #2213.

 Final note: I know some people don't like the name "cache" to mean the
 in-memory copy of data source content (and to some extent I agree, in
 that "cache" could be misunderstood for many other things).  But in
 this task set I didn't touch this issue.  If we can agree on a better
 terminology quickly, I'm okay with introducing the name change within
 these tasks.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2201#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list