BIND 10 #387: xfrin not checking for new copy of zone
BIND 10 Development
do-not-reply at isc.org
Thu Dec 2 08:27:14 UTC 2010
#387: xfrin not checking for new copy of zone
-------------------------+--------------------------------------------------
Reporter: shane | Owner: zzchen_pku
Type: defect | Status: reviewing
Priority: major | Milestone:
Component: xfrin | Resolution:
Keywords: | Sensitive: 0
Estimatedhours: 0.0 | Hours: 0
Billable: 1 | Totalhours: 0
Internal: 0 |
-------------------------+--------------------------------------------------
Changes (by jinmei):
* owner: jinmei => zzchen_pku
Comment:
Replying to [comment:8 zzchen_pku]:
> Replying to [comment:7 jinmei]:
> > Okay, but shouldn't we also include a jitter in this case? Not sure
if this patch changes something on this point.
> Sure, need a jitter for this case, I have updated the patch and added a
new config parameter for reload jitter, please have a look.
>
Hmm...now I have even more questions...why do we have to do something
special for the jitter just by changing the base parameter? From a quick
look at the code, is it because only a minus jitter (and only when the
result is a future time) is introduced? If so, why only minus? (Is that
what BIND 9 does?) And, from a quick look at the revised patch, we
basically wait for the SOA retry time. Is that okay? What if retry is
big, such as 30 minutes? (Again, is this what BIND 9 does?)
Plus...especially now that you've introduced quite a lot of changes
including new config parameters, I guess we need tests for these.
Another minor point: "set_zone_reload_timer" sounds counter intuitive
because it sounds like a timer for reloading (i.e., we reload something
when the timer expires).
> > BTW, we need proposed text for the changelog entry.
> Please find the proposed changelog entry below:
>
> {{{
> src/bin/zonemgr: Check for zone status after loading a zone into
zonemgr. Imposes some random jitters to avoid many zones need to do
> refresh at the same time.(Trac #387, svn rTBD)
> }}}
>
This doesn't specify a change category (I suspect it's a "bug"). And it
doesn't explain what was wrong (just like I asked for the change). Also,
if you change existing parameters, it will break backward compatibility,
so there should be a "*" mark.
--
Ticket URL: <http://bind10.isc.org/ticket/387#comment:9>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list