BIND 10 #387: xfrin not checking for new copy of zone

[BIND 10 Development]

#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       |  
-------------------------+--------------------------------------------------

Comment(by zzchen_pku):

 Replying to [comment:9 jinmei]:
 > 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?)
 I think we have discussed the topic in bind10-dev before, I listed some of
 them below. Maybe we haven't reached a consensus on it, appreciate your
 suggestions.
 {{{
 > >  - about timeout: BIND 9 imposes some random jitters for refresh and
 > >    retry (and perhaps some other) timers.  we probably want to do the
 > >    same thing.
 >
 > Thanks for your hint, we will use it in bind10.
 > I checked the code of bind9, random jitters are only used for refresh
 time:
 > = When bind9 starts, jitter for refresh time is  rand() % (retry * 3 /
 4)
 > = Refresh fails, jitter for next refresh time is   rand() % (retry / 4)
 > = Refresh successes, jitter for next refresh time is rand() %
 > (refresh/4)
 }}}

 {{{
 > > I see there as being two alternatives.  If "r" is the refresh time and
 "j"
 > the jitter value we could set it that the zone refreshes:
 > > a) any time between r - j and r
 > > or
 > > b) any time between r - j and r + j
 > > My own thought is that the latter is the most natural definition, as
 > > the term jitter tends to imply a deviation about a mean.
 > Yeah, from the mean of jitter, the latter one is more natural, but my
 > concern is, it will delay zone refresh which may not user wants,
 >
 > Like a meeting or check in time of company, we can arrive ahead or in
 > time, if you are late, what the boss will say?
 }}}

 > Plus...especially now that you've introduced quite a lot of changes
 including new config parameters, I guess we need tests for these.
 Yes,that is necessary,I have updated the unittest.
 > 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).
 >
 Done.
 > 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.

 {{{
 121.  [bug]*      jerry
 src/bin/zonemgr: Fix a bug that xfrin not checking for new copy of zone on
 startup.
 Imposes some random jitters to avoid many zones need to do refresh at the
 same time.
 (Trac #387, svn rTBD)
 }}}

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