<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 8, 2017 at 1:06 PM, Jeffrey Williams <span dir="ltr"><<a href="mailto:jfwillia@uncg.edu" target="_blank">jfwillia@uncg.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:12.8px">My questions so far:</div><div style="font-size:12.8px">-Does this look to be an issue with the way Shibboleth is configured?</div><div style="font-size:12.8px">-Has anyone else ran into intermittent attribute resolution such as this?</div><div style="font-size:12.8px">-Are there better logs/log levels to look at for this sort of issue?</div><div style="font-size:12.8px">-Any other info I can provide to paint a clearer picture of what's going on?</div></blockquote></div><br>Somewhat akin to a message I sent to another user on the list last night, I'll note that one key distinction between IdP v2 and v3 is that v3 defaults to using LDAP connection pooling, which means that if you're not validating connections and your firewalls and/or load balancers are reaping what look like stale connections, you'll attempt to make requests on stale connections and timeout.  (I don't have any long-lived connections to our AD server; I'm not sure if AD also times out connections after a while, though I'd expect it to close them rather than merely cut them off.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Of course, it could be something else.  (As I noted last night, when I first started hunting a similar problem _after_ our v3 upgrade, I initially blamed what I just described; but ours ended up being database corruption in the underlying OpenLDAP database.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Greg</div></div>