We have found in production that the JNDIRealm can get to a point where NullPointerExeception's are thrown by Sun's LDAP provider for JNDI, and no user can log in. It seems that Sun's LDAP provider holds onto its SSL connection to our Novell LDAP server, even after it throws a NullPointerException. The JNDIRealm does not catch NullPointerExceptions, so it does not close the JNDI context or retry. However, we have found that if we change the two catch clauses in the "authenticate(String username, String credentials)" method to catch Exception (which includes NullPointerException), then the problem goes away. Tomcat 6.0.13: 811: } catch (CommunicationException e) { 835: } catch (NamingException e) { Our hack: 811: } catch (Exception e) { 835: } catch (Exception e) { The only drawback we have found in changing the first catch clause to Exception is that all exceptions cause a retry, including incorrect username/password attempts. It might be possible to avoid these unnecessary retries by checking for AuthenticationException. Another approach might be to add an option to always the close JNDI context before authenticating, if the performance is acceptable. At the very least, changing the outer catch clause to Exception means that after the LDAP connection goes bad, only the first user to try logging in will see an error. Subsequent login attempt should succeed because the outer catch clause will catch the NullPointerException from the first failed login attempt and close the JNDI context. NOTE: we use the "Bind mode" option of JNDIRealm, and we have been using JDK 1.5.0_06 on Red Hat Enterprise Linux 4.
fixed with Committed revision 539907. thanks!