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-20130625
           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:10 jinmei]:
 > Thanks for the review.  I've addressed specific code comments, leaving
 > some higher level discussions (generation ID and load command) open.
 > I'll be offline for a while, so I'm giving the ticket back to you at
 > this point.

 OK. What do we do with the points? Defer to other tickets/mailing list?

 > > I think a changelog would be nice, even if the daemon is not of any
 use. The user might get interested in the fact that a new program exists,
 so we should say he should leave it alone. Also, we should update the
 component status wiki page with the new daemon.

 And this one? Is it one of the higher level ones?

 > > These two messages look like saying a very similar thing both. Is one
 a never version of the other?
 > > {{{
 > > $(man_MANS):
 > >     @echo Man generation disabled.  Creating dummy $@.  Configure with
 --enable-generate-docs to enable it.
 > >     @echo Man generation disabled.  Remove this file, configure with
 --enable-generate-docs, and rebuild BIND 10 > $@
 > >
 > > endif
 > > }}}
 >
 > I see the point, but it seems to be derived from existing Makefile
 > (probably for ddns).  And I'm not sure how it should be fixed - I
 > believe it was originally written by Jeremy.  So my suggestion is to
 > create a separate cleanup ticket for all these rules and give it to
 > him.

 OK, let's do a separate ticket.

 > > Will this load all the local memory segments to memory, or do I
 confuse this `use_cache` with some other?
 > > {{{#!python
 > > DataSrcClientsMgr(use_cache=True)
 > > }}}
 >
 > Hmm, I didn't think about the implication, but I believe (a copy of)
 > local segments will be loaded for memmgr.  And I guess you meant it
 > might be a waste and should be avoided - if so, I see the point, but
 > I think it can be at least deferred in practice; if the amount of
 > memory (and loading overhead itself) is substantial (and as long as
 > memmgr is used), it would better be shared anyway.  If it's not that
 > big, that's a waste but marginal.  So I suggest just creating a
 > ticket, describing the issue, and see if we want to solve it later.

 Yes, that was my worry. I'm OK with separate ticket.

 > > What is the motivation to returning the JSON _string_ here? I know
 there are cases when we need to pass the string (usually to the C++
 wrappers), but even from the description, we expect there'll be cases when
 we pass it as structures (when sending as the command parameters) and it
 is handled as structures in the tests. So, does it make sense to convert
 to string and then back?
 > > {{{
 > > It returns a json expression in string that contains parameters for
 > > the specified type of user to reset a zone table segment with
 > > }}}
 >
 > I guess (again I forgot what exactly I was thinking) I thought we want
 > a string form so we can pass it to
 > `ConfigurableClientList.reset_memory_segment()`.

 That makes some sense (to pass it there as string). But I still believe it
 is better to transform it to string there, than transform it from string
 at 3 or 4 other places _and_ do the transform to string and back from in
 these cases.

 > > Does a general server receive updates?
 > > {{{#!python
 > > % PYSERVER_COMMON_SERVER_STARTED %1 server has started
 > > The server process has successfully started and is now ready to
 receive
 > > commands and updates.
 > > }}}
 >
 > Not in the bind10_server module, but in the user class of that mixin.
 > I think the log description is okay as the observable behavior for end
 > users should be the same.

 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.

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