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

BIND 10 Development do-not-reply at isc.org
Fri Oct 8 08:13:16 UTC 2010


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

 Replying to [comment:28 jinmei]:
 > Replying to [comment:27 shentingting]:
 > > Because the latest change is small, so I attach a diff file to this
 ticket. the xfrin.2.diff is correct.
 >
 > xfrin.2.diff looks mostly okay except the following two points:
 >
 >  - I'm not sure why we need this in !XfrinConnection.connect():
 > {{{
 >             if why.args[0] not in (0, EISCONN):
 >                 raise
 > }}}
 >   Should "0" be really considered in this context explicitly?  It seems
 to be a leftover from the previous version using _ex (where 0 should mean
 "success").  I'm also not sure why we can ignore EISCONN.  Is there any
 valid scenario we catch EISCONN but it's not an error?
 >  - you removed the description for _threads_zones and _conn_sockets with
 renaming the attributes.  it's not good.  we should revise the description
 according to the name change.
 >
 > Also, it's not clear to me whether all of my previous comments were
 addressed.  For example, there doesn't seem to be any change for this
 point:
 >  - "Xfrin.init: the initialization of _max_transfers_in doesn't make
 sense..."
 >  - "configuration update for "transfers_in" should be tested."
 > (there are probably more)
 >
 > Please clarify which of my points were addressed and which were not, and
 in the latter case, why not.  I do not necessarily rqeuire all of the
 comments be addressed, but without the explanation I cannot be sure
 whether they were just forgotten or rejected due to some reasoable reason.
 >
 > Giving the ticket back to tingting.


 1. "Xfrin.init" problem: I think the initialization is necessary.
    (1)In Xfrin._cc_setup function,  after we new a
 isc.config.ModuleCCSession variable, we must call it`s start function.
    (2) the start function call a config_handler callback function, which
 we rewrite.
    (3) In config_handler function the first sentence is
 "self._max_transfers_in = new_config.get("transfers_in") or
 self._max_transfers_in" to make new config valiable. If we do not set
 neither xfrin.transfers_in config data nor the initialization of
 xfrin._max_transfers_in , this will make a error"[b10-xfrin] 'Xfrin'
 object has no attribute '_max_transfers_in'. Just like self._master_addr
 and self._master_port, which are initial.

 2. Actually I copy connect function, send and recv function from
 asyncore.py library, and make a little changes, 0 is success, a connected
 socket call connect function again, it will make a EISCONN code. Maybe
 this is make sense.

 3. In fact, I have already add test_config_handler function to test
 transfers_in.

 4. I am adding description for _conn_sockets_to_threads and
 _zones_to_threads.

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


More information about the bind10-tickets mailing list