BIND 10 #1600: Use UDPSyncServer for b10-auth

BIND 10 Development do-not-reply at isc.org
Wed Mar 7 04:01:11 UTC 2012


#1600: Use UDPSyncServer for b10-auth
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120320
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  auth   |
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:15 kevin_tes]:

 > > What we should do is to have AuthSrvImpl hold a `MessageRenderer`
 > > object and keep using it for all queries (don't forget adding a test
 > > to confirm that too).
 >
 > Reused MessageRenderer has been made,but I do not think it needs
 test.Thanks.

 Why do you think so?  One lesson I learned from the development so far
 is that when we tend to say "we don't need a test for this", we are
 most likely wrong, and in many cases there's actually a bug that could
 have been identified by a test.  So, I'd suggest, if you want say we
 don't need a test, rethinking whether it's really, really true, and
 try to explain to the reviewer explicitly why there's no need for the
 test.  You'll probably be surprised at how often the first impression
 isn't correct.

 Regarding the code, it's not exception safe: If message->toWire()
 throws in the middle of it, renderer_ will keep remembering the
 previously set buffer.  In the version of the base for trac1600 it
 doesn't matter much because the process will immediately die anyway.
 But the latest code catch the condition and continue to the next
 message.  So once this branch is merged this bug becomes more
 critical.

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


More information about the bind10-tickets mailing list