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