BIND 10 #352: Improve Xfrout request handling strategy

[BIND 10 Development]

#352: Improve Xfrout request handling strategy
------------------------------+---------------------------------------------
      Reporter:  zzchen_pku   |        Owner:  jinmei   
          Type:  enhancement  |       Status:  reviewing
      Priority:  major        |    Milestone:           
     Component:  xfrout       |   Resolution:           
      Keywords:               |    Sensitive:  0        
Estimatedhours:  0.0          |        Hours:  0        
      Billable:  1            |   Totalhours:  1.5      
      Internal:  0            |  
------------------------------+---------------------------------------------
Changes (by zhanglikun):

  * owner:  zhanglikun => jinmei


Comment:

 Replying to [comment:14 jinmei]:
 > Replying to [comment:11 zhanglikun]:
 > I've committed suggested text (r3324), and I have related additional
 suggestions:
 >  - I suggest the name of the mix-in class to NoPollMixIn (documentation
 was revised with the new name) because "ServeMixIn" is too generic.  IMO
 the class name should briefly indicate the role of the class.
 >  - I also suggest change the module name from serve_mixin to
 socketserver_mixin so that it will be clear this mixin will be used with
 the socketserver module.
 >
 > And one related comment: I believe what this class overrides is actually
 "BaseServer" instead of "TCPServer" because, as far as I can see, none of
 the mix-in code assume specific part of TCPServer.  Suggested
 documentation was updated on that point, too.
 >
 > Please feel free to update the suggested doc further.  In particular,
 whether you agree with the suggested class name or not, please make the
 documentation and the actual class name consistent (which are currently
 not).

 I like the two names, see the revision r3346 and r3347.

 > I think just do 'break' is okay for now, but don't think it a good idea
 to dump the error to stderr since we cannot assume how this mixin is used.
 Ideally, the serve_forever() thread sends an exit code to the waiting
 thread, and the waiting thread raises an exception if something went
 wrong.  But that may be too much at the moment.  So we should probably
 simply remove this line for now:
 > {{{
 >                     sys.stderr.write("Error with select(), %s\n", err)
 > }}}

 yes,agree. has committed in r3346.

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