<div dir="ltr">Thanks Peter. Appreciate your feedback. We want to avoid lengthy stickyness. Sometimes, the load may not get distributed properly. Let me try the other clustering options.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 17, 2015 at 1:52 AM, Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* nr673 . <<a href="mailto:nara.rama.us@gmail.com">nara.rama.us@gmail.com</a>> [2015-12-17 01:54]:<br>
<span class="">> As mentioned in the following documentation, I enabled the session<br>
> stickyness for 2 mins in the load balancer.<br>
><br>
> <a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPClustering" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPClustering</a><br>
><br>
> shibboleth2.xml does not declare any StorageService element. By default,<br>
> Shibboleth would use the memory storage service. I could login into my<br>
> application successfully. After 3 or 4 minutes idleness, Shibboleth looses<br>
> the session and redirects me to the application welcome page.<br>
<br>
</span>It's not Shibboleth losing the session, it's the loadbalancer losing<br>
stickiness (as configured) and routing the request to a web server<br>
that does not have the same Shibbleth session in memory as the one<br>
that created it initially.<br>
<span class=""><br>
> Is the clustering possible just by enabling the session stickyness<br>
> in load balancer?<br>
<br>
</span>No.<br>
<br>
With permanent stickiness you could make something like that work,<br>
until one of the 4 machines goes down, then everyone having a session<br>
on that SP would have to log in again.<br>
Many would still find that a workable compromise, I suppose.<br>
<span class=""><br>
> Or do I need to use shared process or shared database approach?<br>
<br>
</span>Yes (modulo the compromise mentioned above). If you can't make sure<br>
requests will always end up on the same server then you need to make<br>
sessions available to all the servers where requests might end up.<br>
I.e., you can't keep them in memory on one server and expect things to<br>
magically work if you route requests to another server.<br>
<span class="HOEnZb"><font color="#888888">-peter<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</font></span></blockquote></div><br></div>