<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 9/28/16 10:24 AM, Tom Scavo wrote:<br>
</div>
<blockquote
cite="mid:CAEtu=dNFNJ=KAbmL9GEVQjWpQ3W8VpEUZ187b_1CrzK+Vm+eRw@mail.gmail.com"
type="cite">
<pre wrap="">On Tue, Sep 27, 2016 at 8:56 PM, Brent Putman <a class="moz-txt-link-rfc2396E" href="mailto:putmanb@georgetown.edu"><putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On 9/27/16 8:28 PM, Tom Scavo wrote:
Is there a way to seed a DynamicHTTPMetadataProvider with a list of SP
entityIDs? That is, the metadata for those entityIDs is loaded in the
background, without waiting for a request from the SP.
</pre>
<blockquote type="cite">
<pre wrap="">
The only real question would be whether it was acceptable for such a
component to run synchronously at startup (i.e. blocking the start process),
or async in a background thread.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
Yes, I understand the implementation choice. I will mention (something
you've probably already thought about) is that either approach seems
to overlap with the IdP's ability to restart based on the file-based
cache. </pre>
</blockquote>
<br>
Yes, I thought about after the fact, and was going to mention. The
persistent backup cache (which doesn't have to be file-based btw -
it's pluggable, could be a database, etc) kind of already primes the
resolver using the state that it had before the restart (as long as
a given EntityDescriptor in the cache is still valid).<br>
<br>
<br>
<blockquote
cite="mid:CAEtu=dNFNJ=KAbmL9GEVQjWpQ3W8VpEUZ187b_1CrzK+Vm+eRw@mail.gmail.com"
type="cite">
<pre wrap="">All of those entities need to be in the file cache upon
startup.
</pre>
</blockquote>
<br>
Hmm, it's really the other way around. The "priming entityIDs"
we're discussing don't *need* to be in the persistent cache. If
they're not, they're be resolved as usual via an HTTP fetch.<br>
<br>
If they *are* however, then the "priming" of any given entity is
really a no-op, since there is nothing further to resolve. I was
going to bring that up vis-a-vis the cost of the priming component
block the startup if done synchronously. Assuming the priming
entityIDs are the ones actually being regularly used in the
resolver, then it's likely that many (or most, or all) of those
would be in the persistent cache, and so become no-ops. So the
priming op itself may not actually be all that expensive, and
synchronous wouldn't really be an issue. The expense is instead
paid earlier, by the resolver initialization from the persistent
cache.<br>
<br>
<br>
</body>
</html>