<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 23, 2017 at 2:48 PM O'Dowd, Josh <<a href="mailto:Josh.O%27Dowd@mso.umt.edu">Josh.O'Dowd@mso.umt.edu</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-6023569988951273832WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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</span></p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>M</div><div><br></div></div></div>