BIND 10 #299: AXFR fails half the time

BIND 10 Development do-not-reply at isc.org
Tue Nov 2 04:12:06 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         
      Billable:  1           |   Totalhours:  1.5       
      Internal:  0           |  
-----------------------------+----------------------------------------------

Comment(by jinmei):

 Replying to [comment:29 zhanglikun]:
 > Replying to [comment:28 jinmei]:
 > > By multiple xfrout session, I meant handling multiple xfrout requests
 concurrently.  I don't think it possible with the current code (of trac
 #299), exactly for the reason we discussed in the first paragraph: "with
 the long connection between Xfrout and Auth", a single XfroutSession
 instance handles all incoming requests sequentially.
 >
 > Yes, the transfer-in request has to be processed sequentially. from my
 point of view, I don't think it's a serious problem, if compared with the
 time of zone transfer. what's your opinion?
 >
 I'm not sure if we are talking about the same thing.  What do you mean by
 "tarnsfer-in"?  I've been exclusively talking about "transfer-out", where
 a secondary server sends an AXFR request to a BIND 10 primary server and
 BIND10 replies to it via the xfrout process.

 Now, consider BIND 10 manages two large zones and the following sequence
 of events:

 0sec: client A sends an AXFR request for zone X.
 0.1sec: b10-xfrout starts handling the request.  it takes 10 minutes.
 0.2sec: client B sends an AXFR request for zone Y.  It won't get any
 response soon because b10-xfrout is busy for client A.
 10min 0.1sec: b10-xfrout complete the transfer for client A, and starts
 handling client B. (but client B may have given up the transfer by then)

 Are we on the same page?

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


More information about the bind10-tickets mailing list