BIND 10 #192: Data source hotspot cache
BIND 10 Development
do-not-reply at isc.org
Mon Jun 28 01:20:30 UTC 2010
#192: Data source hotspot cache
-------------------------+--------------------------------------------------
Reporter: each | Owner: jinmei
Type: enhancement | Status: reviewing
Priority: major | Milestone: 05. 3rd Incremental Release: Serious Secondary
Component: b10-auth | Resolution:
Keywords: | Sensitive: 0
-------------------------+--------------------------------------------------
Comment(by jinmei):
On the !DataSrcMatch class:
I've updated the code based on the agreement (or at least what I believe
we agreeded on) in the review (r2298).
A few notes, including a substantial one:
- I guess there's a bug in the current implementation (not specific to
this branch. it should be the same for the current trunk version). see
DISABLED_initialUpdateWithNoMatch.
- I've added many more tests and more detailed doxygen description. I'd
expect any new document to be as detailed as this one. And, it helps us,
too; I noticed the bug through this process.
- and this is a substantial note: in the end, I'm feeling even
!DataSrcMatchTest dropping RR type is leaky. this interface cannot well
explain test cases like !DataSrcMatchTest.updateWithWrongClass. we could
provide artificial restriction such as an exception to be thrown or simply
ignoring RR class in update(), but it looks like counter intuitive and
error prone. To me, this suggests we should revisit the abstraction, and
my updated suggestion is to simply go back to the original design of
!NameMatch. And we pass an RR class parameter to findClosestEnclosure()
separately. As we discussed, whether to include RRclass in
Name/DataSrcMatch doesn't affect the hot spot caching itself, and, as a
bonus, the diff will be smaller and review will be easier.
--
Ticket URL: <https://bind10.isc.org/ticket/192#comment:39>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list