<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">I've also struggled with the pooling config. Seems like I account for one thing and the exact opposite happens next. I'm not sure it's an option for you but ever since we've disabled pooling, we've had much higher stability. There is probably some implication with having shibb do a handshake on each LDAP connection, however it's not been an issue for us.</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">Most of the problems we've seen is when a network device will silently drop a TCP connection, either due to some sort of idle timeout or if an LDAP system suddenly crashes.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font face="courier new, monospace">Jeffrey E. Crawford<br>Enterprise Service Team<a href="mailto:jeffreyc@ucsc.edu" target="_blank"></a></font><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Both pilots and IT professionals require training and currency before charging into clouds!<br></font></div><div><font face="courier new, monospace">---------------------------------------</font></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Sep 15, 2016 at 7:10 AM, Chris Reeves <span dir="ltr"><<a href="mailto:chris.reeves@york.ac.uk" target="_blank">chris.reeves@york.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Daniel,<br>
<br>
On Wed 14 Sep 2016 at 20:25:49 +0100, Daniel Fisher wrote:<br>
<span class="">> On Wed, Sep 14, 2016 at 2:05 PM, Chris Reeves wrote:<br>
> ><br>
> > The first sign that we saw of issues with LDAP authentication were the<br>
> > following messages suggesting that the IdP was reconnecting:<br>
> > --------<br>
> > 2016-09-13T08:37:30.401+01:00 - WARN [org.ldaptive.AbstractOperatio<br>
> > n$<wbr>ReopenOperationExceptionHandle<wbr>r:277] - Operation exception encountered,<br>
> > reopening connection<br>
> > 2016-09-13T08:37:30.402+01:00 - WARN [org.ldaptive.AbstractOperatio<br>
> > n$<wbr>ReopenOperationExceptionHandle<wbr>r:277] - Operation exception encountered,<br>
> > reopening connection<br>
> > 2016-09-13T08:37:30.402+01:00 - WARN [org.ldaptive.AbstractOperatio<br>
</span><span class="">> > n$<wbr>ReopenOperationExceptionHandle<wbr>r:277] - Operation exception encountered,<br>
> > reopening connection<br>
> > --------<br>
><br>
> Were you able to confirm that the reopen was successful?<br>
<br>
</span>I can correlate most of the 'reopening connection' log messages with<br>
successful binds and searches in our LDAP logs, so it looks like the reopen<br>
was successful. The reopens appear to occur in groups of 3 (presumably because<br>
our aggregateAuthenticator is searching three OUs).<br>
<br>
  - The first set of reopens (~08:37:30) bind, search once and then do nothing<br>
    more.<br>
  - The second set of reopens (~08:37:39) bind and then do dozens of searches<br>
    over the next 3 or 4 minutes.<br>
  - The next set (~08:41:21) does a couple of searches before stopping.<br>
  - The next set (~08:41:29) bind and then do dozens of searches over the next<br>
    6 minutes.<br>
  - The final set (~08:41:58) bind and then do dozens of searches over the<br>
    next 6 minutes.<br>
<span class=""><br>
> > Following these initial messages we only saw two authentication attempts<br>
> > complete:<br>
> > --------<br>
> > 2016-09-13T08:37:48.076+01:00 - INFO [net.shibboleth.idp.authn.impl<br>
> > .<wbr>ValidateUsernamePasswordAgains<wbr>tLDAP:152] - Profile Action<br>
> > ValidateUsernamePasswordAgains<wbr>tLDAP: Login by 'user1' failed<br>
> > 2016-09-13T08:39:05.566+01:00 - INFO [net.shibboleth.idp.authn.impl<br>
> > .<wbr>ValidateUsernamePasswordAgains<wbr>tLDAP:152] - Profile Action<br>
> > ValidateUsernamePasswordAgains<wbr>tLDAP: Login by 'user2' failed<br>
> > --------<br>
><br>
> These were probably the only two that the pool returned before the pool was<br>
> emptied by the validator.<br>
> And they likely were not in a working state either.<br>
<br>
</span>Possibly. The LDAP logs show that for the connections that are working they<br>
are successfully searching for users. I can't see any attempts to bind as any<br>
user (this is harder to spot though).<br>
<span class=""><br>
> > Any ideas why the LDAP connection pool got locked up? It seems to have been<br>
> > detecting broken connections to a certain extent, as we see connections<br>
> > being<br>
> > reopened in the logs (although there are only 20 log entries to this<br>
> > effect,<br>
> > spread between 08:37:30 and 08:52:37). I would have thought it should be<br>
> > able<br>
> > to recover from a blip in connectivity to its LDAP authentication source -<br>
> > the<br>
> > blip would have been less than a second, but even if it had been as long<br>
> > as 10<br>
> > seconds that should have been recoverable, surely?<br>
><br>
> I'm guessing that the pool couldn't create new connections.<br>
> Do you have any ldaptive logs that show what was happening to the pool?<br>
> I'd be interested in the thread dump if you can share it off list.<br>
<br>
</span>No, I'm afraid not. There are no log messages from ldaptive other than those<br>
similar to the ones above.<br>
<br>
I'm happy to send you the thread-dump off-list, if that will be helpful.<br>
<span class=""><br>
> > Are there any config options that we should be looking at tweaking, such as<br>
> > timeouts, retry counts, validation, etc. that could improve the situation<br>
> > if<br>
> > this were to happen again?<br>
><br>
> Setting connectTimeout and responseTimeout on the connectionConfig may<br>
> allow the connection pool to recover quicker.<br>
<br>
</span>If it recovers at all... There were obviously some successful reconnections,<br>
but things still somehow got locked up.<br>
<br>
Thanks for taking a look at this,<br>
    Chris<br>
<div class="HOEnZb"><div class="h5">--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</div></div></blockquote></div><br></div>