Use of locks in JNDIRealm

[Felix Schumacher <fe...@internetallee.de>]

Hi all,

yesterday, we had a Tomcat, that would be unresponsive for about twenty 
minutes on every full hour. The cause was a long running scheduled job 
that used the /last/ available connection of the 200 default 
connections. All other connections were waiting to lock the single LDAP 
connection (probably waited already for a long time). I could not find a 
thread in the stack trace, that actually held the lock, so that must 
have been gone (and should probably be investigated further).

Would you mind, if we changed the locking into a timed locking and 
throwing a NamingException on timeout? That way the connections would be 
re-available in a timely manner if such a situation arises again.

Felix

Re: Use of locks in JNDIRealm

[Felix Schumacher <fe...@internetallee.de>]

Hi all,

I now have a bit more information on this.

The problem arises, when you have configured a single LDAP connection 
(no pooling) and the a naming exception is thrown (for example) in 
JNDIRealm#getPrincipal (for example line 2242 in current main). In that 
location we hold a lock while been thrown into the catch block. There we 
are throwing away the connection (without releasing the lock) and 
increase the lock counter (for our thread) by calling get(). After the 
catch block, we release the connection and decrease the lock counter by 
one (which does not release the lock).

We try to fix this with a few different paths:

a) in get() check for the lock, if we hold it ourselves, don't increase it

b) in release() unlock the lock, till we don't hold it anymore

(both ways seem a bit dirty)

c) release the lock and re-get it (that might incur trouble as some 
other thread might get "our" connection, but it should not be that bad, 
as we would get a "new" one anyways)

d) remove the code to handle single connections  and use the pool 
(stack) with a size of one and a special handling, when no connection 
can be taken from the stack.

Any other ideas or preferences?

Felix

PS. apart from fixing this, I still believe, that we should wait for the 
lock with a timeout (in case we keep the lock)

Am 30.07.22 um 12:16 schrieb Felix Schumacher:
>
> Hi all,
>
> yesterday, we had a Tomcat, that would be unresponsive for about 
> twenty minutes on every full hour. The cause was a long running 
> scheduled job that used the /last/ available connection of the 200 
> default connections. All other connections were waiting to lock the 
> single LDAP connection (probably waited already for a long time). I 
> could not find a thread in the stack trace, that actually held the 
> lock, so that must have been gone (and should probably be investigated 
> further).
>
> Would you mind, if we changed the locking into a timed locking and 
> throwing a NamingException on timeout? That way the connections would 
> be re-available in a timely manner if such a situation arises again.
>
> Felix
>