Shibboleth Developers

[André Cruz <>]

So far I've encountered a few problems with a memcache StorageService:

- Key size. Memcache's max key size is 250 chars (bytes). I can alter  
memcache and raise it to 256 but more than that requires bigger  
changes and could also break the clients.

- Contexts. Memcache works like a dictionary so it only has one  
level. If the key size was smaller I could use a key like CONTEXT:KEY  
but this way I dont know.. And the context size is not specified as  
well.

- Update Context and Delete Context. Memcache has no API to search as  
it is not a database... So in order to implement this I would have to  
keep in memcache a structure with the list of keys stored by context...

The biggest problem here is the contexts I think... Anyone have any  
suggestion to work this out?

Also, if we ever get this to work, will it be possible to share this  
cache among various SPs of different applications or will their  
contexts clash?

Thanks,
André



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.
>
> > Regarding 2.0 (trunk of repositories) I see a shibsp/SessionCache.h
> > (which is the Storage API?) and it is implemented by shibsp/impl/
> > StorageServiceSessionCache.cpp (memory based cache?) and odbc_ccache/
> > odbc-ccache.cpp (odbc based cache?).
> >
> > Am I right? Also, what is the RemotedSessionCache?
>
> You do not need to do anything with the SessionCache APIs in 2.0.  
> There are
> already two plugins that should be sufficient for now. The Remoted  
> cache is
> just a stub that lives inside mod_shib and buffers sessions in  
> memory that
> are managed in shibd. The "real" cache is the StorageService-backed  
> plugin.
>
> > In a previous thread the cpp-xmltooling repo was mentioned and I
> > found a caching API there but I don't know the relation between this
> > cache and the SP session cache. (xmltooling/util/StorageService.h)
>
> The only thing you have to implement for 2.0 is a StorageService  
> plugin. It
> knows nothing about the data being stored, it just has to follow  
> the rules
> and provide a bunch of different features like versioned reads and  
> writes,
> and the ability to update the record expiration time.
>
> The ODBC version will be done soon, until then only the in-memory  
> version
> inside the xmltooling library exists as a sample.
>
> If you write a SS plugin, your new backing store can be used for  
> the session
> cache, replay cache, and the artifact mapping store without any  
> special
> work. All the code is written to that API.
>
> The SS API stores data in "contexts" to allow one database table to  
> be used
> to store a lot of different data. In SQL, it's just a separate  
> column making
> a two part key. You don't have to care about how the other pieces  
> of code
> actually make use of the two parts but if there are efficiency  
> issues, I can
> outline some of that.
>
> -- Scott