MemcachedStorage and IdP3
O'Dowd, Josh
Josh.O'Dowd at mso.umt.edu
Thu Aug 24 10:11:06 EDT 2017
Thanks Marvin,
That info is helpful for us.
We have seen a spike in the memcached timeout and retrieval errors in the past 2 days. I assume those translate to a failed node. It has been wildly intermittent and I am struggling to find out if it is network latency or something else.
I have to believe that 2s is plenty of time for a memcached operation, and I don’t want to mitigate this by simply increasing the timeout allowance.
Thanks again.
Josh
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Marvin Addison
Sent: Thursday, August 24, 2017 7:48 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: MemcachedStorage and IdP3
On Wed, Aug 23, 2017 at 2:48 PM O'Dowd, Josh <Josh.O'Dowd at mso.umt.edu<mailto:Josh.O%27Dowd at mso.umt.edu>> wrote:
Basically, I am trying to figure out if a session is lost when Idp tries to retrieve it from a now unavailable(timing out) node
That's what happens. If the node holding the IdPSession object goes down, it has the same effect as if the IdP session were terminated and the user will have to log in again.
I intend to scratch my own itch in coming months and write an IdP storage backend for Redis to provide better resiliency in the case you described. For us the memcached behavior has been tolerable since our memcached daemons have uptimes measured in months if not years, but we can do better with a key-value store that has replication built in. Hazelcast is similar; I believe there's an IdP component for that technology today (Unicon developed it IIRC).
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170824/5922f673/attachment.html>
More information about the users
mailing list