BIND 10 #2854: memory manager framework

[BIND 10 Development]

#2854: memory manager framework
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  shmem         |  reviewing
  manager                            |                    Milestone:
            Keywords:                |  Sprint-20130709
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  9             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:13 jinmei]:
 > Ah, sorry, that was an oversight.  On thinking about it, my first
 > impression is that it would rather be a noise that is not really
 > useful in practice.  But I then realized there was a precedence for a
 > similar case: the DHCP-DDNS (so called "d2") daemon.  Following that
 > convention, this is my proposed entry:
 > {{{
 > 631.? [func]          jinmei
 >       b10-memmgr: a new BIND 10 module that manages shared memory
 >       segments for DNS zone data.  At this point it's runnable but does
 >       nothing really meaningful for end users; it was added to the
 >       master branch for further development.
 >       (Trac #2854, git TBD)
 > }}}

 OK, looks good.

 > > Well, being a user, I would be wondering what kind of updates can
 XfrOut, for example, receive. As a developer, I know these are updates of
 configuration, but this might be confusing for user. This is what I mean.
 >
 > Hmm, I'm afraid I still don't understand what you tried to raise, but
 > would it help if it reads "now ready to receive commands and
 > configuration updates."?

 Yes, that would help.

 > Finally, on higher level points.  First, on the implication to the
 > current branch: understanding the concept of generation IDs will need
 > more discussion even if it might be eventually adopted, would you like
 > references to it to be removed from the branch?  For example, this
 > means we'll update `DataSrcClientsMgr` so get_clients_map() only
 > returns the clients map.  Or are we going to keep it for now and
 > update it later as we figure out how to deal with the issue?

 It's OK to keep as it is. I think we'll do something about it pretty soon,
 so we'll change it at that time.

 > - The term "fragile" is vague and I'm not sure exactly what it means,
 >   but to me the concept of generation IDs is a rather robust approach
 >   to solve the issue by centralizing the versioning and explicitly
 >   sharing the IDs by the other modules.

 I thought it would be fragile if user could tweak it.

 > I suspect we'll need to distinguish the ordering of the configuration.
 > If the data source configuration changes from "C1", "C2", then "C1"
 > again, the first and third one will have the same hash (if we can
 > define the hash reasonably).  A user module such as auth may look at
 > the first "C1", while the memmgr may have just restarted (and missed
 > two intermediate configuration updates) and look at the second "C1'.
 > In this case the user module will still wait for segments for "C2",
 > but memmgr can't answer that.

 No, it'll not wait for C2. It'll know the current configuration is C1 and
 will wait for that, just skip C2.

 I think it is OK to merge with the tiny update to the log message.

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