BIND 10 #214: ASIO fix causes auth not to listen to commands/config updates
BIND 10 Development
do-not-reply at isc.org
Mon May 31 15:27:02 UTC 2010
#214: ASIO fix causes auth not to listen to commands/config updates
--------------------------+-------------------------------------------------
Reporter: each | Owner: jelte
Type: defect | Status: new
Priority: critical | Milestone:
Component: Unclassified | Keywords:
Sensitive: 0 |
--------------------------+-------------------------------------------------
In #168 we converted b10-auth to use asio rather than boost::asio or the
home-grown select-based query response loop. When I merged this I noticed
that the home-grown version had a capability the boost::asio version (and
the new asio version that was derived from it) lacked: monitoring for
queued configuration commands. I tried to copy that logic into the asio
version and apparently did it wrong.
Taking the liberty of assigning this to Jelte even though the bug was my
fault, 'cause he knows the config system wayyyy better than me...
Jelte's comment from #168:
>This doesn't seem exactly right, the hasQueuedMessages&&checkCommand was
used in before select() loops where the processing of the loop could have
had synchronous request/response communication. If there are other
messages arriving while this is being done these are queued and need to be
resolved at some point. In the loop structure the right place for this is
at the start of the loop. In an asynchronous setup, I'm not entirely sure
whether this should be handled at all, though I haven't fully wrapped my
head around asio yet (do we get an immediate calling of the io_services
handler the moment a new message arrives, even if we're still busy
handling other stuff? Or does asio call it as soon as we're done, at which
point we do have possibly queued messages, and if so the current way is
probably right, although we could consider putting it in moduleccsession
itself, at the end of checkcommand (while stuff_left handle_stuff)).
> There is, however, a more immediate problem; in the current trunk,
commands aren't handled at all. Since ModuleCCSession is started without
an io_service, it defaults to the (non-asio) SocketSession?, which expects
manual polls. I have a small patch that fixes this, but it needs expansion
of the asio_link API, to get access to the underlying io_service object.
This isn't really clean and I think we should probably refactor this,
though I'm not sure how, and i'd like to have a bit of a brainstorm for
this (and probably another ticket).
--
Ticket URL: <http://bind10.isc.org/ticket/214>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list