SP memcache plugin problem

[Cantor, Scott]

On 3/4/14, 11:58 AM, "jacob at collegenet.com" <jacob at collegenet.com> wrote:

>
>Hmm...  Then I'd say memcached isn't a good fit.  I've never seen a
>memcached cluster with 100% uptime.  ;)

It wasn't my choice, I simply accepted the code and agreed to maintain it
in the distribution.

>I'm a bit surprised though; couldn't the SP just act like the session does
>not exist in the (admittedly somewhat rare) case?

It does, or should be. No different than if you lose stickiness. Sorry, I
didn't mean it fell over or  anything.

>Or is it relying on the
>cache for even very short-term storage?  I guess in that case a small
>local
>memory cache with LRU eviction would be a good idea to supplement the
>memcached storage.  But then there would be sizing considerations, etc...

That's more or less what it does with every back-end. The session cache
implementation is two stage, one half in memory in Apache for efficiency
and the other out of process, which may be in memory in shibd, or in a
separate store.

It should never fail outright when a lookup fails, it just causes
assumptions to be made about certain things. A replay check for example I
believe is assumed to be a failure if the actual replay cache fails.

-- Scott