BIND 10 #2160: b10-auth should clear Message at the end of request handling
BIND 10 Development
do-not-reply at isc.org
Sat Sep 1 04:26:59 UTC 2012
#2160: b10-auth should clear Message at the end of request handling
-------------------------------------+-------------------------------------
Reporter: | Owner: UnAssigned
jinmei | Status: reviewing
Type: | Milestone:
defect | Sprint-20120904
Priority: | Resolution:
medium | Sensitive: 0
Component: | Sub-Project: DNS
b10-auth | Estimated Difficulty: 4
Keywords: | Total Hours: 0
Defect Severity: N/A |
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by jinmei):
Replying to [comment:6 jelte]:
> Ready for review, I did create a separate Holder class for the message,
and put it at a slightly different location (operator() instead of in
processMessage() itself), mostly so that the tests can still inspect the
message is processed correctly.
- I first thought I'd like to test the case where
processMessage() throws. The current test would pass with a more
straightforward version of cleanup:
{{{#!cpp
server_->processMessage(io_message, *message, *buffer, server);
message->clear(Message::PARSE);
}}}
(but this one isn't fully exception safe). But then I notice most
of the exceptions are caught in processMessage(). And, if an
uncaught exception leaks to the operator(), that would kill b10-auth
anyway, so the cleanup effort will be moot. At this point I'm not
sure what to do, but if it's not difficult I'd still test a case
where processMessage() throws.
- not really related to this ticket, but with this cleanup we now do
`Message::clear()` twice, both in the operator() and in
`SyncUDPServer::handleRead()`. The latter is effectively waste.
For a bit longer term, I think we should rather remove the `Message`
object from the `SyncUDPServer` implementation.
- Just checking: do we need a changelog entry? It's a mostly
invisible internal change, so we probably don't need it, but maybe
we do.
--
Ticket URL: <http://bind10.isc.org/ticket/2160#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list