Hi! I wonder whether anyone experienced problems with performance of JNDIRealm.
In essence it opens a single connection (this.context) which is not thread-safe. Thus it has to synchronize itself whenever it performs an LDAP query. There is TODO comment, "Support connection pooling", but there is no open issues in Bugzilla, nor I see many discussions of this. Some references: - "JNDIRealm connection pooling" thread from April 2008 http://tomcat.markmail.org/thread/7wisup2chr7d77ht -"Add Connection Pooling to JNDIRealm" issue for Tomcat 4.1 from July 2002 https://issues.apache.org/bugzilla/show_bug.cgi?id=10852 I see a race condition in the open() method. Both open() and close() update this.context, but they are not synchronized. There are several methods that call them, most notably authenticate(String,String). The JNDIRealm#startInternal() pre-opens context at startup, so this would be hard to observe, but once the connection fails I expect a bunch of concurrent calls to open() from authenticate(String,String), with all of them but one being wasted. There is also a little chance that the open() method returns null. Maybe that was the real cause behind BZ 42449 / r539907 and those catch(NullPointerException) statements in JNDIRealm. I think it can be fixed by adding synchronized modifier to both open() and close(), but I am afraid that it will make the things worse. If there will be a simple synchronization it means that the threads will wait on the monitor instead of wasting their time in connection attempt: If the LDAP server disappears it may lock all request processing threads: They will wait on the same monitor and then try two connection attempts each. In HTTPD there is mod_ldap that performs connection pooling and caching, so using HTTPD in front of Tomcat might be a workaround for JNDIRealm performance issues. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
