<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 14, 2016 at 12:22 PM, Rich Graves <span dir="ltr"><<a href="mailto:rgraves@carleton.edu" target="_blank">rgraves@carleton.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>Progress, thanks! Although I haven't been able to reproduce the blocking production failure in test (production was fixed by increasing firewall idle timeouts), when I (intentionally) break the test system's access to LDAP by dropping responses with client-side iptables, what I see is:<br>
  a) a quick responseTimeout<br>
  b) the pooled connection validator kills the connection<br>
  c) an exception is raised and caught<br>
  d) the user is sent back to the login form with visible error "Login Failure: Validation of connection failed."<br>
Ideally, I would like to see the shibb server automatically retry with the next LDAP server in the list instead of (d). Can that be done?<br></blockquote><div> </div><div>Not easily. If you can't keep your connection pool healthy you may be better off just turning off pooling.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another related observation: the user or users need to fail and see the "Validation of connection failed" error idp.pool.LDAP.minSize times, not just once. Why? Because at least on my system, all idp.pool.LDAP.minSize..maxSize connections are created with the first working member of the idp.authn.LDAP.ldapURL list. Can I tell ldaptive to use ldapUrl in series or at random instead of as an ordered failover list?<br></blockquote><div><br></div><div>Yes. It requires a bit more config, but you can use round robin or random connection strategies.</div><div><br></div><div>--Daniel Fisher</div><div><br></div></div></div></div>