<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 6/11/18 3:46 PM, Tom Scavo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEtu=dOfKAdM9cfxZ9xbbZusMndFdFLeCX40Z4vOHJsUioXmpA@mail.gmail.com"><br>
<pre wrap="">
The current implementation of DynamicHTTPMetadataProvider caches
entity metadata in a local directory (if
persistentCacheManagerDirectory is specified) but then the cache is
treated as nothing more than a glorified backing file (at least
AFAICT). The provider needs to be smarter about how it leverages
cached metadata.</pre>
</blockquote>
<br>
Like Scott, I don't think we agree on what "smarter" could mean.
Are you perhaps missing that the metadata in the persistent cache is
loaded into memory on every refresh? (as long as still valid, not
expired, etc) What that means is that, once it's primed into the
provider by the first request for it [1], it's going to effectively
be available for as long as it is still valid - the same as an
aggregate would be.<br>
<br>
At that point it effectively is "local", in that no query is
attempted for those entities, and it doesn't matter whether the
source server is available etc. Isn't that what you're essentially
trying to do with the notion of the separate batch provider
accessing an aggregate of "high value" entities?<br>
<br>
[1] As far as priming the dynamic providers, Scott mentioned the use
of a script to issue requests. I can't remember whether we built an
admin endpoint into the metadata service to do that (as opposed to
just issuing IdP-initiated requests whose responses you just
disregard). We could. But the other approach we talked about was a
simple Spring bean that would take a metadata resolver ID and a list
of entityIDs and just do the resolution/priming internally on IdP
(re)start.<br>
<br>
</body>
</html>