Infinispan Based Storage Service

[Paul Hethmon]

Manuel,

Thanks for the feedback. I did look at your memcache version when I was
writing this one. I wanted one where the whole solution was in Java and
really self-contained. In my situation, I run about 60 or 70 IdP clusters,
so having something within the Shibboleth installation was important.

I see what you're saying about the object's being stored under multiple
keys.

I'm wondering if what needs to be done here is to have the storage service
be smart about the objects its storing instead of being more opaque to
what they are. So, if Shib says store this "Session" object, the storage
service not only does that, but uses knowledge of the object to also store
it under other keys (like principal name). Another thought would be to
somehow only store a single copy of the Session object and link that to
multiple keys directly in the storage service. So perhaps the view of the
data might be this:


key                      object
joe (principal name)     abc123 (the session id value)
abc123                   the session object
xh83jdu (transient id)   abc123 (the session id value)

So the storage service would have to be smart about the object type being
returned. It's making a lot of assumptions and I'm sure there is something
missing that will break, but would potentially simply the handling of the
objects.

Paul



On 7/5/12 9:18 AM, "Manuel Haim" <haim at hrz.uni-marburg.de> wrote:

>Hi Scott, hi Paul,
>
>okay, I may have mixed up back-channel artifact resolution with
>back-channel attribute resolution. Thought it was the same. I'm very
>sorry!
>
>But to clarify the problem with multiple keys for a single object:
>
>I just did a quick test with includeAttributeStatement="false" (so the
>SP needs to do back-channel ATTRIBUTE resolution), and it turns out that
>(in my test case) the back-channel is queried by a string containing the
>transientId: So at first, the IdP queries the StorageService's "session"
>partition, and as it sees that the queried key is not in there, the
>"transientId" partition is queried and resolves to the principalName.
>Then, the "session" partition is queried again, but now by the
>principalName, and finally returns the Session object. (Remember that
>you normally get/put Session objects by sessionId? There are multiple
>keys pointing to the same object here.)
>
>I think the Infinispan map had a problem with this. If I put the same
>object under two different keys, and then modify the object and put it
>back only under one key, the replicated map did only hold the modified
>object under this single key (not under both). Even worse, if I did get
>an object value v from the replicated map before and then compare it
>with the new value vNew after repication, it turns out that v!=vNew (so
>if two IdPs concurrently work on an object, the changes are not
>synchronized and may overwrite each other). Thus, back-channel requests
>which depend on the current session but go to a different IdP node will
>not work out-of-the-box if you just pass the StorageService's put and
>set method to the Infinispan map.
>
>This is why we stayed with Memcache and did not step further to use
>Infinispan for the map storage, as it did not bring any more advantages
>(compared to the problems we were already faced with when using
>Memcached). Terracotta, however, is a real monster and synchronizes the
>objects of two virtual machines completely, this is what Infinispan
>(though being a Java solution) just doesn't.
>
>Just my two cents.
>-Manuel
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net