tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon DuRette" <brand...@alum.mit.edu>
Subject JNDIRealm connection pooling
Date Thu, 10 Apr 2008 22:55:02 GMT
While trying to track down an issue with logins taking a very long time, I
just discovered in the 5.5.26 source code/Javadoc for JNDIRealm (likewise in
the 6.0 documentation) that there's a big bold TODO to support connection
pooling in the JNDIRealm.  I think this may be part of the login problem I'm
seeing.

Looking over the current source code, I can see that it's going to require a
fairly extensive refactoring of the JNDIRealm code.  I'm willing to take a
shot at fixing it, but wanted to first check with the list on a couple of
things, mostly matters of process.

   1. I could not find a corresponding case in the bug database in either
   the 5.5 or 6.0 builds.  Since this is an issue in both, should I open it in
   both?  If not, does anyone care which one the issue is filed against?
   2. Likewise, is there a preferred version to contribute patches
   against?  Ideally for me, I would patch 5.5, since that's what we use at
   work, but I'm willing to do either provided the patch ultimately could be
   applied to both versions.
   3. Library dependencies.  The fix, as indicated in the comment,
   requires that the MessageFormat objects for user search and/or user pattern
   be pooled in some manner to make them thread-safe.  My initial thought was
   to use the Apache Commons Pool library for this purpose.   I see it listed
   in the Core Optional Libraries and JNDIRealm is a part of the
   catalina.optional library, but I don't see commons-pool*.jar show up
   anywhere in the package, so I must be missing something.  Any pointers on
   that would be greatly appreciated.  Also, if I'm way off base and should be
   using some other pooling mechanism please let me know.

Thanks in advance for any pointers.

Regards,
Brandon

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message