Repurpose IndexingObjectStore ?

[Brent Putman]

On 9/21/15 7:30 PM, Cantor, Scott wrote:
> On 9/21/15, 5:39 PM, "dev on behalf of Tom Zeller" <dev-bounces at shibboleth.net on behalf of tzeller at dragonacea.biz> wrote:
>
>
>
>> Does it sound reasonable to repurpose IndexingObjectStore<T> to use an index other than a String ?
> I don't pretend to understand that class or why it's used,

At one point Chad did some analysis of memory usage in the IdP (way,
way back) and determined that one of the biggest consumers was the
in-memory storage of base64-encoded certificates, particularly
redundant/duplicates ones (i.e. Strings which were the same according
to equals(), but different instances).  So this was his solution to
reduce that memory usage.  Only store 1 instance of a particular String.

Thinking back, I'm not sure what the duplicates actually were, since
entity certs in metadata would be different and KeyAuthoritys would
typically only appear once anyway.  But I'm probably forgetting something.

In theory this could be applied to any kinds of objects, but it's only
ever been used in the X509CertificateImpl and X509CRLImpl, to store the
base64-encoded String data.


>  but it looks to me like the indexing is an internal function, not an exposed thing. They're just supposed to be opaque strings returned by put() and then used with get(), but they're manufactured internally.
>
Yes, exactly.  Entirely internal. The caller stores off the (completely
opaque) index that is returned from put() and uses it to retrieve via
get().

So to answer Tom's question, it's designed to store at most 1 actual
instance of a T, as determined by equals().  If that's not your use
case, then this isn't what you want.  

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