seeding the DynamicHTTPMetadataProvider

[Brent Putman]

On 9/28/16 10:24 AM, Tom Scavo wrote:
> On Tue, Sep 27, 2016 at 8:56 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>> 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.
>>> 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.
> 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. 

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).


> All of those entities need to be in the file cache upon
> startup.

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.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160928/615e7e34/attachment.html>