Memcached StorageService

[Cantor, Scott]

On 10/2/14, 10:08 AM, "Marvin Addison" <marvin.addison at gmail.com> wrote:
>
>I got everything working to my satisfaction except
>updateContextExpiration, which simply isn't possible with this
>implementation.

I believe the SP's memcache plugin implements it, by maintaining a record
in the store for the context to track the associated keys. Which I think
it an option that's exposed so that it's possible to configure storage
plugins with and without the overhead.

> I saw that at least one other StorageService did not implement that
>method, so I figured it was ok. If anyone has some spare cycles I would
>appreciate review:

Well, the LDAP one Daniel did doesn't support expiration at all, so it's
more of a toy than something somebody could use.

The IdP doesn't appear to use that method. The SP does because of how the
sessions are stored and what's in them, though it probably could be
avoided with a different storage format.

>I will be incorporating this component into our dev environment in the
>next couple weeks, so it will get some live testing. The primary use
>case for this component is supporting protocols that need to access
>IdP session state over back-channel protocols (CAS in our case) in a
>HA environment. Memcached has proven for us a preferable alternative
>to a database backend in terms of performance, simplicity, and
>availability, so I'm looking forward to putting this component through
>the paces.

I admit I still don't "get" how it provides HA given no replication, but
I've had that conversation many times and it doesn't really matter what I
think, memcache is something lots of people want and needs to be in the
package if we can get it there, so you just solved another problem for us.

>I'm interested in contributing this to the project. It only pulls in
>one additional dependency, net.spy:spymemcached [1], which seems
>relatively innocuous. I'd appreciate feedback on contributing.

I would like it in in the 3.0 package if we can get it there. Having the
dependency baked into opensaml-saml-impl doesn't bother me any, unless
somebody objects (and the licensing is kosher). We can always do a
separate project if need be.

Speaking of which, I've just been busy, but we had the formal vote on the
PMC list to add you as a committer so I need to get you an account in svn
and so forth, and then you can start checking in the CAS stuff and this if
you're prepared to work on that.

-- Scott