Qs after reviewing Java dynamic metadata resolvers

[Cantor, Scott]

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:

> I agree, the memory isn't close to the batch case.  Init time - yeah, I see your point.  I
> still think it's probably preferable to pay that cost up front rather than at request
> time.  We could instead theoretically load from the cache in a background thread
> at init time, so it doesn't delay the startup.  But there's some synchronization
> complexity there, if you get requests in for metadata before or while it's running for
> entityIDs that overlap, and newer ones are resolved than the cache.  That complexity is
> evil, as it always is, and doesn't seem worth it to me personally.

If we implemented "priming" with a background thread, we'd need something like that anyway, and I'm not sure that it's all that different than the general locking we'll need for normal usage. 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'm not actually sure though if the roundtrip does cause a problem in the Java code. It's
> certainly a strong possibility, but not certain. 

I don't think it does now, at least not for the same reason, it's strictly that it's a potential risk, and we probably won't have much notice of it becoming a problem, it would be caused by regressions in the XML parser.

> However, I was just looking again at the StorageService API to confirm viability.  I think
> I missed something earlier and it's not currently possible.  I don't see mechanism on the
> SS API for enumeration.

There isn't, I didn't want to impose that requirement. It probably is somewhat historical now and could be revisited, but I don't think it's possible in all back-ends, and I've gotten around it by maintaining my own index list records, essentially Berkeley DB style with less efficiency (though doing a sort of embedded hashtable type thing is also potentially possible to avoid overly large index lists).

-- Scott