BIND 10 #2934: xfrout session can be broken due to EAGAIN

[BIND 10 Development]

#2934: xfrout session can be broken due to EAGAIN
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  jinmei
            Priority:  medium        |                       Status:
           Component:  xfrout        |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130528
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  2             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:13 vorner]:

 > > Hmm, I have no idea about the reason for that.  Other terrain script
 > > should also use installed bindctl, and both cases are invoked in the
 > > same way.  So if other tests such as bindctl_commands_feature works
 > > I don't see why it doesn't work for loadzone.  Does your test
 > > environment have b10-loadzone installed somewhere in the PATH with
 > > executable permission?
 >
 > I don't know why it fails. I do have bind10 installed, but to a strange
 location. Neither b10-loadzone nor bindctl is in path. But I run it
 through the run_lettuce.sh script, it might be related. And maybe it might
 be related to this in setup_intree_bind10.sh:
 > {{{
 >
 PATH=/home/vorner/work/bind10/src/bin/bind10:/home/vorner/work/bind10/src/bin/bindctl:/home/vorner/work/bind10/src/bin/msgq:/home/vorner/work/bind10/src/bin/auth:/home/vorner/work/bind10/src/bin/resolver:/home/vorner/work/bind10/src/bin/cfgmgr:/home/vorner/work/bind10/src/bin/cmdctl:/home/vorner/work/bind10/src/bin/stats:/home/vorner/work/bind10/src/bin/xfrin:/home/vorner/work/bind10/src/bin/xfrout:/home/vorner/work/bind10/src/bin/zonemgr:/home/vorner/work/bind10/src/bin/ddns:/home/vorner/work/bind10/src/bin/dhcp6:/home/vorner/work/bind10/src/bin/sockcreator:$PATH
 > export PATH
 > }}}

 Ah, that's probably it.  I'm still not sure why it resulted in
 "permission denied", but I confirmed it failed locally if I moved the
 installed b10-loadzone (the error was "no such file", which made more
 sense to me).  I've added a path to loadzone in the PATH setting.

 > > I actually didn't try to lower the value, but I found I'd still need
 > > at least 4 seconds to reproduce the original problem with the test.
 > > Of course, it highly depends on local environment, so 5 seconds may be
 > > too long for some, and might even be too short for others.  In any
 > > case the problem shouldn't happen how long we delay it, and in that
 > > sense any value is okay as long as it catches any future regression
 > > like that.  For now, I've kept the same amount of delay with some
 > > explanatory comments.
 > -
 > Is it so slow it actually keeps running and generating messages to the
 buffer for the whole 4 seconds?

 Yes.  This is a log:
 {{{
 2013-05-20 09:23:09.657 INFO  [b10-xfrout.xfrout/24060]
 XFROUT_XFR_TRANSFER_STARTED AXFR client [::1]:56977: transfer of zone
 example.org/IN has started
 2013-05-20 09:23:13.171 ERROR [b10-xfrout.xfrout/24060]
 XFROUT_XFR_TRANSFER_ERROR AXFR client [::1]:56977: error transferring zone
 example.org/IN: [Errno 35] Resource temporarily unavailable
 }}}

 That's probably partially because xfrout in the test is also quite
 slow, dumping log messages at the highest debug level.  And, probably
 for the same reason, 5 seconds of wait time are not that big a
 bottleneck in the entire test scenario: with the 5 seconds delay, it
 took about 14 seconds; if I changed it to 1 second, it was just
 reduced to 12.

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