shibboleth-dev - Re: Location of SP Session Cache
Subject: Shibboleth Developers
List archive
- From: André Cruz <>
- To:
- Subject: Re: Location of SP Session Cache
- Date: Sun, 10 Jun 2007 20:19:04 +0100
Sorry to bring this subject back again but only now I got the opportunity to look at the 1.3 code.
On 2007/05/29, at 19:43, Scott Cantor wrote:
Regarding 1.3 there is the ISessionCache present in shib-target.h
which is implemented by shib-ccache.cpp (memory based cache) and shib-
mysql-ccache.cpp (mysql based cache).
The 1.3 cache is a huge mess. It was supposed to get better, but I botched
it and made things even worse if that's possible. You have to implement the
IsessionCacheEntry interface to actually supply the different storage
routines, but also wrap the in-memory ISessionCache implementation. It's
probably a small bit easier than with 1.2, but it's just as confusing.
You pretty much have to copy the MySQL cache plugin.
I don't understand why we have to wrap the in-memory cache. Surely this can cause the in-memory cache to become stale in some situations?
Taking as an example the mysql cache: if in machine A a session is accessed, the mysql cache and in-memory cache of machine A update the last access time of the session. If the same session is accessed via a shibd process in machine B, the session is fetched from the in- memory cache before the mysql cache (assuming it was already there) and so the last access time is wrong. Or maybe this is not a problem?
Anyway... In 1.3 the only caches that need to be distributed are the session cache and replay cache found in shib-mysql-cache.cpp, right?
The reasons this distributed remote cache looks interesting to me are:
- lower memory consumption on the machines running shibd. Normally these machines are the front-ends of our applications which have better uses for their RAM.
- no need for sticky sessions.
- if I can organize the session cache by userid maybe I can remotely kill all the SP sessions of a specific user by deleting his entries from the memcache cache (that's another reason for not wanting to wrap an in-memory cache) and therefore have Single-logout on 1.3. :)
Is this too much fantasy?
Thanks for your help,
André
- RE: Shibboleth CAS LDAP Kerberos, (continued)
- RE: Shibboleth CAS LDAP Kerberos, Lisa Tan, 06/08/2007
- Re: Location of SP Session Cache, André Cruz, 06/06/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/06/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/06/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/10/2007
Archive powered by MHonArc 2.6.16.