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.
Didn't you mention the problem earlier in another report ? I remember something like this, but didn't see anything obvious in the code (which I'm not too familiar with). Yes, refactoring and removing the need for using two connections would be useful. Be careful not to introduce new bugs, though ;)
(In reply to comment #1) > Didn't you mention the problem earlier in another report ? I remember something > like this, but didn't see anything obvious in the code (which I'm not too > familiar with). You might have confused it with this enhancement proposal: http://issues.apache.org/bugzilla/show_bug.cgi?id=33266 Both issues emerged while trying to setup a self-contained webapp (with its own datasource, realm and database driver in WEB-INF/lib). The one decribed in this report is however far more severe.
Created attachment 14165 [details] Refactored o.a.c.realm.DataSourceRealm
Created attachment 14166 [details] Modified o.a.c.realm.LocalStrings.properties Fixed two message keys for more consistent look (uppercesed 's' in a word datasourceRealm). The rest of resource bundles do not contain fixed keys.
Why not ... Do you know the purpose of the if( !dbConnection.getAutoCommit() ) { dbConnection.commit(); } which was in the code before ? I do not see any writes being made.
(In reply to comment #5) > Why not ... > > Do you know the purpose of the > if( !dbConnection.getAutoCommit() ) { > dbConnection.commit(); > } > which was in the code before ? I do not see any writes being made. I'll look into it (by forcing autoCommit off) and let you know if it might have any impact.
Created attachment 14168 [details] o.a.c.realm.DataSourceRealm Indeed, according to jdbc specs, some resources (locks particularly) might not get released when leaving the connection uncommited. I added the required block back in a single place, just before closing the dbConnection (or should I say returning to the pool)
I have applied your patch.
*** Bug 33526 has been marked as a duplicate of this bug. ***
*** Bug 33938 has been marked as a duplicate of this bug. ***