BIND 10 #299: AXFR fails half the time

BIND 10 Development do-not-reply at isc.org
Mon Sep 27 07:15:59 UTC 2010


#299: AXFR fails half the time
-----------------------------+----------------------------------------------
      Reporter:  zzchen_pku  |        Owner:  zzchen_pku
          Type:  defect      |       Status:  reviewing 
      Priority:  major       |    Milestone:            
     Component:  xfrout      |   Resolution:            
      Keywords:              |    Sensitive:  0         
Estimatedhours:  0.0         |        Hours:  0.5       
      Billable:  1           |   Totalhours:  1.0       
      Internal:  0           |  
-----------------------------+----------------------------------------------
Changes (by jinmei):

  * hours:  0.0 => 0.5
  * owner:  jinmei => zzchen_pku
  * totalhours:  1.0 => 1.5


Comment:

 Replying to [comment:20 zzchen_pku]:
 > Replying to [comment:19 jinmei]:
 > > I suspect with this approach the xfrout thread cannot catch shutdown.
 > Do you mean xfrout server can't catch the event of xfrout client
 shutdown. Since Xfrout socket is in blocking mode, when a recv() returns 0
 bytes, it means the xfrout client has closed the connection, at this time
 we can break the handle loop and close this request.
 >
 I meant the shutdown command via the command handler or a signal, etc.
 Then XfroutServer.shutdown() is called, where the shared "shutdown_event"
 is set.  It causes self._unix_socket_server.shutdown(), but if I
 understand the code correctly the serve_forever() loop doesn't stop
 because the worker thread is in a deeper loop (i.e. the big while loop in
 XfroutSession.handle()).

 > >      #self._log.log_message("error", "Failed to receive the file
 descriptor for XFR connection")
 > > }}}
 > Sorry, I forgot to add comment for it. Because the log will display each
 time xfrout client shutdown. I have updated the recv_fd() function, which
 will return different value to distinguish shutdown event from error
 handling, or any other good suggestion?
 >
 The "xfrout client" here means the auth server in effect, right?  Then I
 don't understand why we'd worry about the shutdown because it should be a
 rare event with the new code.  Nevertheless I generally think separating
 errors and normal shutdown is a good idea.

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


More information about the bind10-tickets mailing list