Spring LockTimeoutException?

[Cantor, Scott]

On 7/29/16 10:30 AM, Redman, Chad Eric wrote:
> 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.

All it takes is one holding the lock of course.

> The second time we saw this happen, there was zero load on the system,
> and there was a single SP auth request.

It's not load, it's I/O wait, stuff hanging on connections to other
systems, etc. It definitely cannot be observed with a single request in
isolation. You have to have at least two requests from that same Java
client session with one holding the lock.

> 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.

That's just the timeout of the specific request that caused it to exceed
the limit waiting to acquire the lock. It doesn't reflect the actual
cause. If there's nothing logged, then whatever it is is totally hung or
deadlocked and there's no IdP code running to log anything for that request.

> 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.

That certainly can cause threads to back up and hang. Network behavior
is one of the pieces that a lot of libraries just don't get right. It
took me months with the original IdP 1.3 to come up with a pooling
library that worked for databases.

-- Scott