Spring LockTimeoutException?

[Redman, Chad Eric]

Pulling up an old thread here, just to mention we've seen this two times while testing lightly loaded systems before going live. The first time, we could see from the access logs that an SP triggered two simultaneous auth requests for reasons unknown. The first of these returned immediately, but the second one hung for 30 seconds. The 30 second delay is what the user saw. The second time we saw this happen, there was zero load on the system, and there was a single SP auth request. Nothing unusual was logged other than the LockTimeoutException, and the single line in the access log that showed it took 30 seconds to return the page.

My hunch so far is that it has something to do with the LDAP pool settings in our  attribute data connector. On a quiet system, maybe the open connections get reset or are otherwise unresponsive, after a period of being unused. Turning on debug or trace in the ldaptive classes is pretty verbose, so we haven't tried to look deeply into it yet.

Our setup is IdP 3.2.1, RedHat 7, Tomcat 8.5.

-Chad


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Jorj Bauer
Sent: Friday, June 03, 2016 3:45 PM
To: users at shibboleth.net Shib Users <users at shibboleth.net>
Subject: Spring LockTimeoutException?

Has anyone else run in to this?


2016-06-03 15:21:19,903 - ERROR 
[org.springframework.webflow.conversation.impl.LockTimeoutException:76] -
org.springframework.webflow.conversation.impl.LockTimeoutException: 
Unable to acquire conversation lock after 30 seconds


... that's our lightly loaded production IdP, which just locked itself 
up pretty hard. Tomcat 8 couldn't grab hold of itself to shut down; we 
had to kill -9 the process.

I'm looking for hints as to what might have lead to the underlying 
condition. We've never seen that behavior before.


-- Jorj
-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net