BIND 10 #347: Implement query counters in auth module

BIND 10 Development do-not-reply at isc.org
Mon Dec 6 10:37:27 UTC 2010


#347: Implement query counters in auth module
------------------------------+---------------------------------------------
      Reporter:  naokikambe   |        Owner:  y-aharen             
          Type:  enhancement  |       Status:  reviewing            
      Priority:  major        |    Milestone:  y2 12 month milestone
     Component:  b10-auth     |   Resolution:                       
      Keywords:               |    Sensitive:  0                    
Estimatedhours:  0.0          |        Hours:  0                    
      Billable:  1            |   Totalhours:  0                    
      Internal:  0            |  
------------------------------+---------------------------------------------
Changes (by jinmei):

  * owner:  jinmei => y-aharen


Comment:

 Replying to [comment:8 y-aharen]:

 > > '''stats.cc'''
 > >   - The comment and log messages assume that the other end is the
 > >     b10-stats program, but interface-wise it's not necessarily correct
 > >     (that could be a third-party app that implements the stat API,
 > >     right?)
 > Counter in Auth module is not intended to communicate with third-party
 stats module. It only communicates with b10-stats.
 >
 Hmm, this is different from my general understanding (general = not just
 about statistics): the protocol among various BIND 10 modules is open, and
 any single module can be replaced (and should be replaceable) with other
 implementation, as long as it supports the inter module protocol.  For
 example, we can replace b10-xfrin with a third party xfrin process without
 affecting how the entire BIND 10 system behaves.  And, there shouldn't be
 a reason why statistics is an exception.

 It's possible my understanding is incorrect, however, so, if you don't
 agree please bring it to bind10-dev.

 > >   - BTW, even if it doesn't cause timeout and exception, we should
 > >     actually not even block in group_recvmsg (and also
 > >     group_sendmsg(), which can happen because it's a connected
 > >     channel): b10-auth shouldn't stop handling DNS queries even for 1
 > >     second.  Since it should relatively a rare event we can live with
 > >     the current blocking mode (and there are actually other parts of
 > >     b10-auth that have the same problem).  But please leave a TODO
 > >     comment on this point.  We should eventually solve it.
 > I don't think that blocking in group_{send,recv}msg also blocks handling
 of DNS queries. I understand blocking read/write operation stops in the
 ASIO library, and if another event arrives ASIO starts handling it. Excuse
 me if I misunderstood.
 >
 This is not true for group_sendmsg(), because it uses a blocking primitive
 of ASIO (asio::write()).

 I actually thought it also applied to group_recvmsg(), but after re-
 checking the code I found (or rediscovered) that it uses a tricky
 asynchronous loop with a timer (internally calling asio::run_one()), so,
 you seem to be right; the internal loop will handle other events while
 waiting for the stats response.

 But I suspect it was a non intended side effect, and the original intent
 was to introduce a timeout for a blocking read operation (if you want to
 be sure, we should ask Jelte, who implemented it).  Actually, calling
 run_one() in an event handler of asio::run() don't seem to be safe in
 general; there seems to be possible race condition in handling a lock for
 the shared io_message object.  Besides, in my understanding we'll
 eventually integrate this code into the generic asio_link wrapper, at
 which point this will probably be a blocking operation again.

 So, basically, I think my point still stands.  Note, however, that I
 didn't request to solve this problem.  This is just a note, and my
 suggestion was to leave some comments for future fixes.

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


More information about the bind10-tickets mailing list