Qs after reviewing Java dynamic metadata resolvers

[Brent Putman]

>> There is the issue that the file-based HttpClient cache doesn't persist across
>> restarts, by conscious intent.  We did briefly discuss possibly changing that,
>> maybe as a configurable option.  I'm not opposed.  However, since we're
>> now going to implement a "SAML cache" that persists across restarts, I think
>> doing that has less value now, at least for the dynamic resolver restart case.
> No, it's a batch thing, but it is a thing, and we still do have work to do there to optimize the startup time. If the solution is changing the cache persistence, that's ok.

Well, the HttpClient cache is less important now for the batch resolver
also I think.  We recently changed to now init from the backing file. 
Any/all HTTP fetches are now going to be in the background, both at
startup and runtime refresh.

So unless I'm forgetting something, the original musings around
persisting the file-based HttpClient cache across restarts are no
longer relevant.

There is a general performance improvement from caching HTTP data
across restarts - if you do fall into having to hit the HTTP source,
and the data in fact hasn't changed per etag/Last-Modified, you don't
fetch new bytes.  But it's not about startup anymore in either metadata
case, it's just about plain old HTTP performance improvement at
runtime, like any HTTP user agent.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160915/459357e8/attachment.html>