BIND 10 #401: Timouts in the recursor

[BIND 10 Development]

#401: Timouts in the recursor
------------------------------+---------------------------------------------
      Reporter:  vorner       |        Owner:  vorner   
          Type:  enhancement  |       Status:  reviewing
      Priority:  major        |    Milestone:           
     Component:  recurser     |   Resolution:           
      Keywords:               |    Sensitive:  0        
Estimatedhours:  0.0          |        Hours:  0        
      Billable:  1            |   Totalhours:  0        
      Internal:  0            |  
------------------------------+---------------------------------------------
Changes (by stephen):

  * owner:  stephen => vorner


Comment:

 I've looked at the changes in src/lib/asiolink and src/bin/recurse since
 r3524.  The ''seem'' OK, although I did note the following concerning
 recursor.h and recursor.cc:

 '''recursor.h'''
  * Methods are documented, but not the class itself.  What is its purpose?

 '''recursor.cc'''
  * RecursorImpl::!RecursorImpl should initialize rec_query_ to NULL
 (instead of "()".
  * Is there a potential failure mode here should querySetup() be called
 when a query is in progress?  Suggest that if querySetup() is called with
 a non-NULL rec_query_ an exception is thrown.
  * The classes !QuestionInserter and !SectionInserter seem to related more
 to code associated with general DNS message manipulation than with the
 recursor.  Should they be in recursor.cc or in the main DNS library?
  * Similarly, !MessageAnswer does a general transformation of a message.
 Although it takes a Recursor* argument to its constructor, it seems that
 this is never used.  I would suggest that the functionality of
 !MessageAnswer is placed in the main DNS library and that the
 !MessageAnswer code just calls it.

 On a more general point, documentation: as the resolver progresses, it is
 getting more difficult to relate the bits to one another.  I think we need
 to take some time to document what we have so far.  At minimum a class
 diagram and an outline of the general logic is required.  (In fairness, I
 think that also needs to include the asiolink classes; there is some
 documentation in the "doc" directory but it does need to be extended.
 Most of the time in this review was flitting back and forth between
 asiolink and recurse trying to work out what method was being called and
 why.)

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