Re: Use of locks in JNDIRealm

[Felix Schumacher]

Hi all,

I now have a bit more information on this.



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)





Any other ideas or preferences?

Felix



Am 30.07.22 um 12:16 schrieb Felix Schumacher:

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). 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. PS. apart from fixing this, I still believe, that we should wait for the lock with a timeout (in case we keep the lock)

Hi all,





Felix

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.

OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature