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):

 Thanks for the review.

 Replying to [comment:10 vorner]:

 > The lettuce tests don't pass for me, for some kind of permission error:
 > {{{
 >       File
 "/var/tmp/bind10/bind10-3/tests/lettuce/features/terrain/loadzone.py",
 line 35, in run_loadzone
 >         subprocess.PIPE, subprocess.PIPE)
 >       File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
 >         errread, errwrite)
 >       File "/usr/lib64/python2.7/subprocess.py", line 1308, in
 _execute_child
 >         raise child_exception
 >     OSError: [Errno 13] Permission denied
 > }}}

 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?

 > Also, the 5 seconds of timeout seems like a really long time to me. I
 guess some kind of wait is needed here, but single second would be more
 than enough to fill whatever buffers the OS has (or flush the whole zone
 into the buffers if they are large enough).
 > {{{
 > When I do a customized AXFR transfer of example.org from [::1]:47806
 with pose of 5 seconds
 > }}}

 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.

 > Does anything still use the `database_file` option? Didn't we change the
 xfrin/out to use the client lists?
 > {{{
 >     "Auth": {
 >         "database_file": "data/xfrout.sqlite3",
 >         "listen_on": [ {
 >             "address": "::1",
 >             "port": 47806
 >         } ]
 >     },
 > }}}

 xfrout still needs to refer to it (one of the things we should fix).

 > Then there are two things in comments.
 >
 > This should be „with“, not „without“:
 > {{{#!python
 > # examine how it's called, so we replace it without our mock.
 > }}}

 Ah, right, corrected.

 > I believe this is not a file, but socket. Files are always blocking, at
 least in linux (I don't know about other unices).
 > {{{#!python
 >     """A helper function to change blocking mode of the given file.
 >
 >     It sets the mode of blocking I/O for the file associated with
 filenum,
 >     according to parameter 'on': if it's True the file will be made
 blocking;
 >     otherwise it will be made non-blocking.
 >
 >     filenum(int): file number (descriptor) of the file to update.
 >     on(bool): whether enable (True) or disable (False) blocking I/O.
 >
 >     """
 > }}}

 I intentionally chose the word file because the API used in the
 function only relies on file abstraction and the descriptor it takes
 is named "fileno" in the Python API.  But that's a minor point, and in
 fact the given descriptor must always be for a socket for this helper
 anyway, so I revised the docstring replacing 'file' with 'socket'.

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