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