BIND 10 #1747: refactor auth::Query so it's reusable

[BIND 10 Development]

#1747: refactor auth::Query so it's reusable
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:         |  Proposed
  critical                           |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  auth   |
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> The auth::Query class is now (going to) use internal resource
> to hold RRsets with #1607.  In #1607 I used a local
> vector<ConstRRsetPtr> object, but it's not efficient to allocate it
> for every query.
>
> I propose making auth::Query reusable and reusing the internal
> resource within the class.  Then the auth server creates a Query
> object on its initialization and keeps using it.  Make sure the
> internal resource is always cleared for every query, especially when
> some query processing results in an exception.  It would also be
> better to ensure the capacity of the vector(s) won't exceed some
> limit after cleanup.
>
> This would be a relatively easy task, so I'd also make one more
> refactoring in this ticket: using separate vectors for the answer and
> authority sections and storing RRsets for these sections in the middle
> of the query processing.  Then we can conslidate the response message
> construction at the end of the method:
>
> {{{#!c++
>     for_each(answers.begin(), answers.end(),
>              RRsetInserter(response_, Message::SECTION_ANSWER, dnssec_));
>     for_each(authorities.begin(), authorities.end(),
>              RRsetInserter(response_, Message::SECTION_AUTHORITY,
> dnssec_));
>     for_each(additionals.begin(), additionals.end(),
>              RRsetInserter(response_, Message::SECTION_ADDITIONAL,
>                            dnssec_));
> ]}}
>
> which would be clearer, and will make #1688 easier to handle.
>
> It's not direct dependency, but it's probably better to start this
> task after #1607.

New description:

 The auth::Query class is now (going to) use internal resource
 to hold RRsets with #1607.  In #1607 I used a local
 vector<ConstRRsetPtr> object, but it's not efficient to allocate it
 for every query.

 I propose making auth::Query reusable and reusing the internal
 resource within the class.  Then the auth server creates a Query
 object on its initialization and keeps using it.  Make sure the
 internal resource is always cleared for every query, especially when
 some query processing results in an exception.  It would also be
 better to ensure the capacity of the vector(s) won't exceed some
 limit after cleanup.

 This would be a relatively easy task, so I'd also make one more
 refactoring in this ticket: using separate vectors for the answer and
 authority sections and storing RRsets for these sections in the middle
 of the query processing.  Then we can conslidate the response message
 construction at the end of the method:

 {{{#!c++
     for_each(answers.begin(), answers.end(),
              RRsetInserter(response_, Message::SECTION_ANSWER, dnssec_));
     for_each(authorities.begin(), authorities.end(),
              RRsetInserter(response_, Message::SECTION_AUTHORITY,
 dnssec_));
     for_each(additionals.begin(), additionals.end(),
              RRsetInserter(response_, Message::SECTION_ADDITIONAL,
                            dnssec_));
 }}}

 which would be clearer, and will make #1688 easier to handle.

 It's not direct dependency, but it's probably better to start this
 task after #1607.

--

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