BIND 10 #2044: In-Memory cache in ClientList

[BIND 10 Development]

#2044: In-Memory cache in ClientList
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  vorner                             |                Status:  closed
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120717
  medium                             |            Resolution:  complete
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  7
            Defect Severity:  N/A    |           Total Hours:  5.01
Feature Depending on Ticket:  Use    |
  new datasources                    |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jelte):

 Replying to [comment:11 vorner]:
 > Replying to [comment:10 jelte]:
 > > I wonder if we should check whether a zone is present in multiple
 datasources; that might result in some unexpected behaviour (not really
 specific here, but the way they are added to the cache reminded me of it).
 >
 > Well, the semantics is that the first instance of the best match takes
 precedence. So, there's no need to. Note that each data source has its own
 separate cache.
 >

 yes this was more of a general pondering :)

 > > This seems a lot like running memory datasource that loads from
 sqlite3 (except this will hopefully be load-on-demand completely in the
 future) :) Will this replace that or will we have both? (i.e. the to be
 implemented cache_all option).
 >
 > Yes, that's a generalization of that, for any data source. I want it to
 be able to detect the zones automatically, so we can omit the list of the
 zones. I want it to replace that, because the current/old way is non-
 systematic hack. I'd like the „memory“ type be gone in the long term (or,
 at least, modify the configuration it takes to something sane).
 >

 +1 on getting rid of the current configuration :) And tentative +1 on not
 having a separate memory ds (but may depend on how we end up doing the
 scalability work, and on how we will keep this synced on rapidly changing
 zones/zone lists)

 > Anyway, I don't think an on-demand loading would make sense. Can you
 imagine your `com.` is not yet cached and you get the query? Even if we
 could load it in background, the query would likely time out by then.
 >

 for something like .com it would indeed be bad, I was more thinking of
 having a gazillion small zones which should load quite fast and then be
 'cached' (now thinking cache may not be a very good name for this), but if
 query rate is low enough you probably don't want them in memory anyway, so
 yeah, on-demand is probably not a good idea.

 > > I don't recall if this would be part of the zoneloaderv2 work., but
 did we intend to change the way zones are loaded in the API? The
 intermediate zonefinder creation seems unnecessary, and things would look
 simpler if we could just call load() directly on InMemoryClient; or
 perhaps even make it a public call of DataSourceClient (in that case we
 can remove the InMemoryClient class from the code here completely, and
 initialize a base datasourceclient as an inmemory one). Though of course
 the latter would need some consideration as to what to do for different
 types of datasource.
 >
 > I don't think I parse the question. If you want to explain it, could you
 do it by email (either to me or to -dev)? Thank you

 will do

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