BIND 10 #1847: CC timeouts in auth

[BIND 10 Development]

#1847: CC timeouts in auth
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:
                       Type:         |                Status:  closed
  defect                             |             Milestone:  New Tasks
                   Priority:         |            Resolution:  invalid
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  Unclassified                       |  Estimated Difficulty:  2
                   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:13 naokikambe]:

 > > One possibility I had in my mind is that b10-auth stores
 > > statistics in a separate storage such as an SQLite3 DB file, maybe in
 > > a periodic batch task.  b10-stats or any other statistics clients
 > > would then retrieve the stored statistics values from that storage
 > > separately.
 >
 > IMO stats might periodically pull out statistics from each module via a
 CC session, and store them into an SQLite3 DB together with a timestamp.
 Because maybe auth is very busy to answering DNS queries, and its
 asynchronous writing to the SQLite3 DB is likely to be very difficult. I'm
 afraid it might be possible to affect its response performance. That
 situations of auth are definitely in my image. If we complete replacing
 the current msgq with another better implement, couldn't that issue be
 problem, which is transmitting large bytes in the CC channel?

 I wouldn't expect too much from an unrealized magic technology:-)

 I believe we all share the same goal: exchanging statistic information
 from a (possibly very busy) server module and a statistics collector
 without disrupting the main service of the server.  It just seems to
 me that opinions/views vary about where the major bottleneck that may
 cause the disruption is.

 To me, explicit inter-process communication, especially for a large
 amount of data, is much riskier in that sense.  The other end might
 also be busy and the send() operation could block, but asynchronous
 communication makes the code more complicated.  Also, I'm not so sure
 how and where b10-auth can store the statistics data until it's asked
 to provide it by the collector (which is an unpredictable event in the
 pull model).  The number of zones may be millions, and the zone data
 may be in a separate DB file or DB server, and b10-auth may not even
 be able to have a handy way to get a list of all zones stored in the
 DB.

 Alternatively, b10-auth could simply build and maintain the statistics
 as it responds to queries on the fly (and in memory), and periodically
 (e.g. every 30 sec) dump it to somewhere, either to the collector via
 asynchronous communication, or to an SQLite3 DB file.  I guess
 synchronous write is okay for the latter case if the period is
 reasonably short, and the implementation can be much simpler.  This is
 what I imagined at the cited part above.

 But, again, I'm not insisting on any particular approach as long as
 the goal is achieved.  So far, however, it seems to me that direct
 communication approach has more difficult issues to solve for
 stability and scalability.

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