You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2005/02/02 15:06:11 UTC
DO NOT REPLY [Bug 33357] New: -
DataSourceRealm leaks connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33357>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33357
Summary: DataSourceRealm leaks connections
Product: Tomcat 5
Version: 5.5.7
Platform: All
OS/Version: Windows 2000
Status: NEW
Severity: major
Priority: P1
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: drzewo@post.pl
o.a.c.r.DataSourceRealm leaks connections (does not return to the pool) in
getRoles(String). The new connection is obtained from the data source, but never
returned. Bedides there seems to be a slight performance optimization possible
so that the getRoles makes use of the very same connection the authenticate()
does. Right now the whole authentication process i.e. authentication and
retrieval of user roles (which I consider as a whole and non-separable) requires
*two* connections of which one is never returned. I observe the increase of the
number of database backend. It eventually reaches the limit rendering the Realm
unusable.
One might workaround it by adding the following attributes in her datasource
Resource definition: removeAbandoned="true" removeAbandonedTimeout="15". But for
heavy loaded applications which extensively use the Realm facility 15 seconds
might be way too much.
Here is what logAbandoned="true" produced:
DBCP object created 2005-02-02 14:40:38 by the following code was never closed:
java.lang.Exception
at
org.apache.tomcat.dbcp.dbcp.AbandonedTrace.setStackTrace(AbandonedTrace.java:157)
at
org.apache.tomcat.dbcp.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:76)
at
org.apache.tomcat.dbcp.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
at
org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
at org.apache.catalina.realm.DataSourceRealm.open(DataSourceRealm.java:407)
at org.apache.catalina.realm.DataSourceRealm.getRoles(DataSourceRealm.java:538)
at
org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceRealm.java:360)
at
org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceRealm.java:284)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:256)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:391)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:365)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommonAccessLogValve.java:481)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:738)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
I volunteer to fix this bug as well as rework the DataSourceRealm which seems a
bit messy to me IMHO. Particularly the fact that two connections are reqired is
the most annoying.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org