BIND 10 #1288: Update XFROUT to use new interface

[BIND 10 Development]

#1288: Update XFROUT to use new interface
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111122
                  Component:         |            Resolution:
  xfrout                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:18 jinmei]:
 > BTW, I've noticed via this bug that the current component
 > implementation can cause infinite recursive calls (which subsequently
 > lead to stack overflow and crash) if `Component._start_internal`
 > raises an exception:
 start->_start_internal->(exception)->failed->start->...
 >
 > Maybe this will be automatically resolved as we implement delayed
 > restart, but if we cannot expect it to be very soon we should probably
 > need some intermediate workaround to avoid such catastrophic behavior.

 Yes, I know. It should be solved by the delayed restarts (as the restart
 must wait a while, it can't happen inside the current call). We said this
 will be done in this sprint and should be one of the higher-priority ones,
 so I guess it will be done before the release.

 > >  * More to the workaround itself, we now have two with the same
 workaround, with more to expect, probably? Would it be better to just pass
 the environment variable to anything started? Other things shouldn't be
 hurt by it anyway and it would remove two specials, making it easier for
 the user. Or, should we try talking about it tomorrow at the call?
 >
 > Apparently #1292 was resolved (I've not closely checked the solution
 > though).  So we can probably just merge and then cleanup the
 > intermediate hacks for xfrin/out (but I'd defer the cleanup task to a
 > separate ticket as this ticket could be a blocker for the IXFR-out
 > support; I'd rather merge this branch first).

 I'd like to see it resolved before the release, otherwise the user will
 have to reconfigure after we remove the special components. I don't care
 if in a separate ticket or not, though. How large do you guess it will be?

 > > Anyway, normal tests pass, but now a distcheck fails:
 > [...]
 > > I guess a test file is missing from some variable of Makefile.am.
 >
 > Ah, I see xfrin test's Makefile has a workaround.  I've done the same
 > thing for the notify test (commit 275d091).  That doesn't happen on my
 > system, so could you recheck it fixes the issue?

 Is it possible the Makefile in xfrout test needs that too? Because of this
 failure?
 {{{
 2011-11-15 10:39:31.532 ERROR [b10-xfrout.xfrout]
 XFROUT_HANDLE_QUERY_ERROR error while handling query: Failed to create
 DataSourceClient of type sqlite3:sqlite3_ds.so: cannot open shared object
 file: No such file or directory
 E
 ======================================================================
 ERROR: test_axfr_normal_session (__main__.TestXfroutSessionWithSQLite3)
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File "/home/vorner/work/bind10/src/bin/xfrout/tests/xfrout_test.py",
 line 735, in test_axfr_normal_session
     response = self.sock.read_msg(Message.PRESERVE_ORDER);
   File "/home/vorner/work/bind10/src/bin/xfrout/tests/xfrout_test.py",
 line 62, in read_msg
     get_msg.from_wire(bytes(sent_data[2:]), parse_options)
 pydnspp.MessageTooShort: Malformed DNS message (short length): 0

 ----------------------------------------------------------------------
 }}}

 Anyway, this error might show that it doesn't send even SERVFAIL. Is it
 possible?

 Thank you

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