[prev in list] [next in list] [prev in thread] [next in thread] 

List:       irrtoolset
Subject:    Re: "set sources" and data cacheing
From:       Ruediger Volk <rv () kronos ! NIC ! DTAG ! DE>
Date:       2010-06-28 8:09:49
Message-ID: 456.1277712589 () x37 ! NIC ! DTAG ! DE
[Download RAW message or body]

  > Looks like the "@rtconfig set sources" command does not interact properly
  > with the object cache:
  > 
  > > rtconfig> @rtconfig set sources = "RIPE"
  > > rtconfig> @rtconfig printPrefixes "can haz %p/%l\n" filter as-inexie
  > > can haz 193.242.111.0/24
  > > can haz 194.88.240.0/23
  > > rtconfig> @rtconfig set sources = "RADB"
  > > rtconfig> @rtconfig printPrefixes "can haz %p/%l\n" filter as-inexie
  > > can haz 193.242.111.0/24
  > > can haz 194.88.240.0/23
  > > rtconfig> 
  > 
  > The second command should return nothing because there is no data in
  > whois.radb.net keyed on AS-INEXIE with source "RADB".
  > 
  > I haven't really looked at the cacheing code.  Does the code store the
  > object source: tag?  If it does, this is should be a relatively simple bug.
  >  If it doesn't, then there's a choice between getting the cache to store
  > the source: tag and making that work correctly, or alternatively any time
  > someone changes the source list, then the entire cache could be
  > invalidated.  The latter is obviously pretty icky.
the logic that I'm used to is:
objects in the cache are handled somewhat different from queries to the
database servers.
In general the objects in the cache take precedence over database queries
and the source: attribute is ignored (and not required) in the cache file.


Ruediger


Ruediger Volk

Deutsche Telekom AG -- Internet Backbone Engineering

E-Mail:  rv@NIC.DTAG.DE
_______________________________________________
irrtoolset mailing list
irrtoolset@lists.isc.org
https://lists.isc.org/mailman/listinfo/irrtoolset
[prev in list] [next in list] [prev in thread] [next in thread]