Qs after reviewing Java dynamic metadata resolvers

[Brent Putman]

On 9/14/16 5:43 PM, Cantor, Scott wrote:
> On 9/14/16, 5:19 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>
> If we implemented "priming" with a background thread, we'd need something like that anyway, 

If priming is done by just externally executing metadata resolve
requests (i.e. ignoring the return values), I don't think anything
additional is needed.  It's handled by the existing read/write lock.

I didn't mention, but with this proposal, another way to prime the
resolver is to just dump XML into the cache (e.g. drop files into the
cache directory).  You actually don't even have to name them in any
particular way.  On the init and enumeration, if the existing cache key
doesn't match the expected cache key (for example, on the restart you
changed the cache key generator function), it updates the record in the
cache to be indexed by the expected one.  That's the reason for the
updateKey(currentKey, newKey) method.  This is not tested yet, though.

> and I'm not sure that it's all that different than the general locking we'll need for normal usage.

Actually, you may be right for the above reason.  I guess you just get
the write lock and if you already have "live" metadata, you skip that
cache entry - it would have been from an incoming request (since the
background thread started) and the one in cache would necessarily
already match it, I think, having been newly written (assuming lazy
iteration of the filesystem).

>  But, I'm also not saying it's worth it, I think a predicate you could inject would take care of tuning the startup cost well enough.

I'll start out with that for sure.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160914/1f290d26/attachment.html>