BIND 10 #1207: Enable the data source factory

[BIND 10 Development]

#1207: Enable the data source factory
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120515
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 Replying to [comment:9 jinmei]:
 >
 > - some `AuthSrvTest` tests such as queryWithInMemoryClient(No)DNSSEC
 >   resulted in segmentation fault somehow related to `RBNodeRRset` in
 >   destructing `Message` in the `SrvTestBase` destructor.  I've not
 >   fully figured out the cause, but I suspect remaining `RBNodeRRset`
 >   pointers stored in the message, which internally refer to in-memory
 >   data source data structures, which are defined in the dynamically
 >   loaded part, somehow confused the run time system.  The following
 >   workaround suppressed this problem, although it's a bit ad hoc:
 > {{{#!cpp
 >     ~AuthSrvTest() {
 >         parse_message->clear(Message::PARSE);
 >     }
 > }}}

 Hmm, added, for now.

 >   (btw, we should actually clean-up the passed message in
 >   `AuthSrv::processMessage` because the stored `RRsets` could be
 >   invalidated if some big change such as reloading happens to the
 >   underlying data source after processing the query.  but that's
 >   another topic)
 >

 Ack :)

 > - The `AuthCommandTest::loadZone` test also crashed.  On looking into
 >   it a bit deeper I found this dynamic cast failed and resulted in
 >   NULL:
 > {{{#!cpp
 >         old_zone_finder_ =
 boost::dynamic_pointer_cast<InMemoryZoneFinder>(
 >             result.zone_finder);
 > }}}
 >   Again, I suspect the dynamically loaded module somehow confused the
 >   RTTI system, but I didn't chase it further.
 >

 Yup, I suspect it has lost typing information across the RTTI-gap, and
 therefore dynamic casts result in NULL. I've changed it to a static-cast,
 and then it works fine. That may be a bit more fragile. I think, however,
 that this would be solved if we move such type-specific code out of here
 completely anyway (and make its functionality either something supported
 by the Client API or have a more general way of doing such things through
 that API).

 > - may or may not be related, I also noticed memory_datasrc.cc is still
 >   compiled into the b10-auth and its test.  Can't (or even shouldn't)
 >   we now eliminate the need for it?
 >

 Almost :) The above is the last thing I think (and in the case of tests,
 there are also a few InMemory-specific tests).

 > Considering our current focus is NSEC for in-memory, I'll stop here
 > and focus on NSEC related tickets.  This may be MacOS specific, so you
 > may want to try to reproduce it on our MacOS buildbot box.  Also,
 > since dynamic loading will have other system-dependent issues, so we
 > may want to run this branch on other buildbots.

 Ack. Done, the above seems to fix it. If I remember, and the NSEC merges
 do not cause any buildbot problems, I'll swing this through buildbot over
 the weekend.
 (i have already tried this branch on my linux and bsd systems before
 setting it to review, so I'm pretty sure it works there, at least on mine
 :))

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