BIND 10 #2281: use new in-memory data source in the static data source

[BIND 10 Development]

#2281: use new in-memory data source in the static data source
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  vorner
            Priority:  high          |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130219
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => vorner


Comment:

 Hi Michal

 Replying to [comment:13 vorner]:
 > Hello
 >
 > It seems there's some problem with the makefiles, since distcheck
 complains:
 > {{{
 > libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../../src/lib/datasrc
 -I../../.. -I../../../../src/lib -I../../../src/lib
 -I../../../../src/lib/dns -I../../../src/lib/dns -DOS_LINUX
 -I../../../../ext/asio -I../../../../ext/coroutine
 -DASIO_DISABLE_THREADS=1 -Wall -Wextra -Wwrite-strings -Woverloaded-
 virtual -Wno-sign-compare -Werror -fPIC -g -O2 -MT static_datasrc_link.lo
 -MD -MP -MF .deps/static_datasrc_link.Tpo -c
 ../../../../src/lib/datasrc/static_datasrc_link.cc  -fPIC -DPIC -o
 .libs/static_datasrc_link.o
 > ../../../../src/lib/datasrc/static_datasrc_link.cc:16:26: fatal error:
 factory_link.h: No such file or directory
 > compilation terminated.
 > make[7]: *** [static_datasrc_link.lo] Error 1
 > make[7]: Leaving directory
 `/tmp/bind10-1/bind10-20130205/_build/src/lib/datasrc'
 > }}}

 This file has been renamed and added to the Makefile.am SOURCES.
 Documentation for this module's interface has also been added.

 > Is it OK to pass the config of the static data source to the zone
 > table segment? I don't think the config parameter has been described,
 > but it seems strange that such low-level thing would know anything
 > about configuration of a very specific data source.

 I have replaced this with a `NullElement` now. Unless the syntax/purpose
 of the config as passed to the `ZoneTableSegment` is defined, we can't
 be sure what to pass there. A FIXME comment has been added.

 > If you don't link the in-memory library, how does the code get in? Is
 > it some magic I didn't notice, or is it by accident already there? Or,
 > who does link to the in-memory?

 I'm not sure too. Unless `-rdynamic` is specified when linking the main
 executable, its symbols are not exposed to the module. But what seems to
 be happening is that its symbols are indeed being exposed and linked at
 dlopen time.

 * Firstly, it works properly without being linked to the memory
   datasource library. So it's finding its symbols at runtime.

 * The reason why this library was removed from being linked to the
   static data source was that `b10-auth`'s unit tests (and some other
   tests) were crashing. This was because, during the tests, the factory
   was used to repeatedly load and unload `.so`s within the same
   process. During this, the `dlclose()` was finalizing the `.so`'s
   global storage, and destroying a logger inside the memory datasource
   library, which further resulted in singletons within liblog being
   finalized. This wouldn't happen unless they were commonly linked.

 I don't know how it's finding its symbols.

 > I don't understand why the change in the python tests is needed. Can
 > you explain it, please? Why removing in-memory from there? I would
 > understand adding the static one too.

 Now I'm not sure if my change is correct. The old in-memory data source
 _module_ has been removed, so I thought that asking the factory to
 return the 'memory' source would be wrong.

 > Should the mock return the longest partial match if there's no exact
 > one? It seems to pick the first one it finds, which might as well be
 > something shorter than optimal.
 >
 > If you used reverse names for the names in the map (still in the
 > mock), it would be possible to find the longest match by some trick
 > with map::lower_bound, I think. Not that it would be important for the
 > performance.

 From what I observed, only 1 or 2 zones at most are added into the map
 by any unittest. So any overhead is at best constant. Due to the number
 of zones, and the data being used, it does pick the correct zone to
 return.  I didn't want to spend more time optimizing it.

 But now that you have mentioned it, I have changed it to do what you
 describe above. :)

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