BIND 10 #216: Xfrin: Implement the feature items in TODO file.

[BIND 10 Development]

#216: Xfrin: Implement the feature items in TODO file.
------------------------------+---------------------------------------------
      Reporter:  zhanglikun   |        Owner:  shentingting        
          Type:  enhancement  |       Status:  reviewing           
      Priority:  major        |    Milestone:  y2 6 month milestone
     Component:  xfrin        |   Resolution:                      
      Keywords:               |    Sensitive:  0                   
Estimatedhours:  0.0          |        Hours:  0                   
      Billable:  1            |   Totalhours:  5.0                 
      Internal:  0            |  
------------------------------+---------------------------------------------

Comment(by jinmei):

 First off, if you meant you completed your turn and waited for a response
 (I assumed so), please change the ticket owner.  By leaving the owner
 (currently it's still you), we assume you are still working on it by
 default.

 Replying to [comment:31 shentingting]:
 > >> http://bind10.isc.org/ticket/216?replyto=29#comment:17
 > > I saw your changes, and I agree with you.
 >
 > >> http://bind10.isc.org/ticket/216?replyto=29#comment:19
 > >>isn't it better to delete completed threads as soon as possible? in
 the current implementation they are not purged until a new xfrin attempt
 occurs.
 > > For this, We can delete completed threads as soon as possible. but
 when we delete completed threads, it will find this thread's fd in hash
 map, this waste time. I purged it when a new xfrin attempt occurs. This
 will not run delete, it save time. Although It will occupy some memory,
 but It is little, it's number less than max_transfers_in. So I did so.
 >
 That's not convincing to me.  Searching a hash map is generally cheap, and
 if we argue that memory consumption is marginal because max_transfers_in
 is small (but we should remember this is configurable), that should also
 apply to the search cost.

 But, I wouldn't necessarily insist it should be addressed within this
 ticket.  If you don't agree, please move forward with the current code for
 now.

 > >>I believe we should use select for connect and send while watching a
 shutdown event. consider, e.g., the case where a shutdown event is sent
 when the primary server is dead and connect blocks. but it's okay for me
 to leave this enhancement to another ticket (or we should rather do so)
 >
 > > I think it is better to create another ticket to solve this.
 >
 I've created one (#370).

 > > For the newest code, I delete connect function. For error code 0, it
 is success, so there is no exception,  And add a DEFAULT_TRANSFER_IN
 variable to remove the hardcoding.
 >
 The diff from r3181 to r3183 looks okay.

 But please answer my original question: have you addressed all of my
 previous comments, or is there any outstanding issue?  By only selectively
 answering a subset of the points I cannot be sure about that.

 In general, if I made comments like this:
   - Point 1: ...
   - Point 2: ...
   ...
   - Point n: ...

 I'd expect a response as follows:
   - Point 1: I addressed this in rXXXX
   - Point 2: I don't agree with the suggestion because XXX.  So I didn't
 touch the code for now.
   ...(covering all other points like this)
   - Point n: Good point, but I'd defer it to a different ticket.  Will
 open one.

 Or, if the points are minor, a comprehensive summary would be sufficient:
  - I believe I've addressed all of your comments in rXXXX.  Please check.

 But the responses I've seen so far are something like this:
  - (citing Point 2) I did XXX for this point in the latest code.

 That makes me wonder "so, what about point 1, point3, ... and point n!?"

 If you could be more comprehensive in subsequent post-review responses,
 that would be very helpful.

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