You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Grzegorz Borkowski (JIRA)" <ji...@apache.org> on 2010/04/24 19:41:50 UTC
[jira] Created: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
---------------------------------------------------------------------------
Key: DBCP-332
URL: https://issues.apache.org/jira/browse/DBCP-332
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.4
Reporter: Grzegorz Borkowski
BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
I was able to fix it by overriding close method this way:
{code}
public class XBasicDataSource extends BasicDataSource {
@Override
public synchronized void close() throws SQLException {
DriverManager.deregisterDriver(DriverManager.getDriver(url));
super.close();
}
}
{code}
but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Posted by "Grzegorz Borkowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870563#action_12870563 ]
Grzegorz Borkowski commented on DBCP-332:
-----------------------------------------
@Daniele: what you see in Tomcat logs means that Tomcat sees that there is memory leak, and it tries to prevent it. In earlier Tomcat versions, you wouldn't see it.
> Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
> ---------------------------------------------------------------------------
>
> Key: DBCP-332
> URL: https://issues.apache.org/jira/browse/DBCP-332
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Reporter: Grzegorz Borkowski
> Fix For: 1.3.1, 1.4.1
>
>
> BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
> SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
> I was able to fix it by overriding close method this way:
> {code}
> public class XBasicDataSource extends BasicDataSource {
> @Override
> public synchronized void close() throws SQLException {
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
> super.close();
> }
> }
> {code}
> but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Posted by "Grzegorz Borkowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861774#action_12861774 ]
Grzegorz Borkowski commented on DBCP-332:
-----------------------------------------
If they all use the same classloader, than probably yes, this could cause the problem - it needs verification, but it sounds logical. If that's the case, than it would be better to make this behavior optional. So add the method "deregisterDriver" to BasicDataSource so that I can call it from some listener programatically. Also, add settings "deregisterDriverOnClose", so that I can set up BasicDataSource, for example in Spring, with this option set to true, so that it dergisters the driver automatically, and I don't have to write any code, only by pure configuration.
> Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
> ---------------------------------------------------------------------------
>
> Key: DBCP-332
> URL: https://issues.apache.org/jira/browse/DBCP-332
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Reporter: Grzegorz Borkowski
> Fix For: 1.3.1, 1.4.1
>
>
> BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
> SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
> I was able to fix it by overriding close method this way:
> {code}
> public class XBasicDataSource extends BasicDataSource {
> @Override
> public synchronized void close() throws SQLException {
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
> super.close();
> }
> }
> {code}
> but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Posted by "Grzegorz Borkowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861714#action_12861714 ]
Grzegorz Borkowski commented on DBCP-332:
-----------------------------------------
I don't think so. DBCP-272 talks about initialization process - when and how driver should be registered, from what I see. But the net result is the same: driver gets registered.
Here I mean the fact, the it is not unregistered during closing the SimpleDataSource - which causes memory leak, and Tomcat complains about it.
> Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
> ---------------------------------------------------------------------------
>
> Key: DBCP-332
> URL: https://issues.apache.org/jira/browse/DBCP-332
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Reporter: Grzegorz Borkowski
> Fix For: 1.3.1, 1.4.1
>
>
> BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
> SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
> I was able to fix it by overriding close method this way:
> {code}
> public class XBasicDataSource extends BasicDataSource {
> @Override
> public synchronized void close() throws SQLException {
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
> super.close();
> }
> }
> {code}
> but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Posted by "Grzegorz Borkowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865125#action_12865125 ]
Grzegorz Borkowski commented on DBCP-332:
-----------------------------------------
6.0.24
> Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
> ---------------------------------------------------------------------------
>
> Key: DBCP-332
> URL: https://issues.apache.org/jira/browse/DBCP-332
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Reporter: Grzegorz Borkowski
> Fix For: 1.3.1, 1.4.1
>
>
> BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
> SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
> I was able to fix it by overriding close method this way:
> {code}
> public class XBasicDataSource extends BasicDataSource {
> @Override
> public synchronized void close() throws SQLException {
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
> super.close();
> }
> }
> {code}
> but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz updated DBCP-332:
-----------------------------
Fix Version/s: 1.3.1
1.4.1
Affects Version/s: 1.3
Could this be a regression introduced by the fix for DBCP-272?
> Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
> ---------------------------------------------------------------------------
>
> Key: DBCP-332
> URL: https://issues.apache.org/jira/browse/DBCP-332
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Reporter: Grzegorz Borkowski
> Fix For: 1.3.1, 1.4.1
>
>
> BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
> SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
> I was able to fix it by overriding close method this way:
> {code}
> public class XBasicDataSource extends BasicDataSource {
> @Override
> public synchronized void close() throws SQLException {
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
> super.close();
> }
> }
> {code}
> but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861770#action_12861770 ]
Sebb commented on DBCP-332:
---------------------------
Is it possible for multiple data sources to register the same driver?
If so, won't deregistering it in one cause problems for the others?
> Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
> ---------------------------------------------------------------------------
>
> Key: DBCP-332
> URL: https://issues.apache.org/jira/browse/DBCP-332
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Reporter: Grzegorz Borkowski
> Fix For: 1.3.1, 1.4.1
>
>
> BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
> SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
> I was able to fix it by overriding close method this way:
> {code}
> public class XBasicDataSource extends BasicDataSource {
> @Override
> public synchronized void close() throws SQLException {
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
> super.close();
> }
> }
> {code}
> but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Posted by "Daniele Cappè (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865123#action_12865123 ]
Daniele Cappè commented on DBCP-332:
------------------------------------
In which Tomcat version it has been corrected ? 6.0.25 ?
> Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
> ---------------------------------------------------------------------------
>
> Key: DBCP-332
> URL: https://issues.apache.org/jira/browse/DBCP-332
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Reporter: Grzegorz Borkowski
> Fix For: 1.3.1, 1.4.1
>
>
> BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
> SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
> I was able to fix it by overriding close method this way:
> {code}
> public class XBasicDataSource extends BasicDataSource {
> @Override
> public synchronized void close() throws SQLException {
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
> super.close();
> }
> }
> {code}
> but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Posted by "Daniele (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865128#action_12865128 ]
Daniele commented on DBCP-332:
------------------------------
I have Tomcat 6.0.24 and in my catalina.log i see this error:
A web application registered the JBDC driver [com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
A web application appears to have started a thread named [Thread-4] but has failed to stop it. This is very likely to create a memory leak.
> Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
> ---------------------------------------------------------------------------
>
> Key: DBCP-332
> URL: https://issues.apache.org/jira/browse/DBCP-332
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Reporter: Grzegorz Borkowski
> Fix For: 1.3.1, 1.4.1
>
>
> BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
> SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
> I was able to fix it by overriding close method this way:
> {code}
> public class XBasicDataSource extends BasicDataSource {
> @Override
> public synchronized void close() throws SQLException {
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
> super.close();
> }
> }
> {code}
> but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-332) Closing BasicDataSource doesn't
deregister JDBC driver, causing memory leak
Posted by "Grzegorz Borkowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870567#action_12870567 ]
Grzegorz Borkowski commented on DBCP-332:
-----------------------------------------
I've discovered one problem with unregistering SQL driver in BasicDataSource.close() method: if you create the BasicDataSource, retrieve connection, close connection, than close BDS, and than create new instance of BDS, and try to obtain connection, it will not work: it will complain that it can't find proper driver for given URL. I haven't had time to investigate it, but I guess that driver registration is done somehow statically, at class loading. So after you deregister driver and create new instance of BDS, driver is not registered again, because no classlodin is done at that moment. That's my guess at least. As a solution, the BDS could try to register manually the driver (using java.sql.DriverManager.registerDriver) whenever first attempt to obtain driver fails.
> Closing BasicDataSource doesn't deregister JDBC driver, causing memory leak
> ---------------------------------------------------------------------------
>
> Key: DBCP-332
> URL: https://issues.apache.org/jira/browse/DBCP-332
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Reporter: Grzegorz Borkowski
> Fix For: 1.3.1, 1.4.1
>
>
> BasicDataSource's method close() doesn't deregister JDBC driver. This causes permgen memory leaks in web server environments, during context reloads. For example, using Tomcat 6.0.26 with Spring, and BasicDataSource declared in Spring context, there is a message printed at web application reload:
> SEVERE: A web application registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
> I was able to fix it by overriding close method this way:
> {code}
> public class XBasicDataSource extends BasicDataSource {
> @Override
> public synchronized void close() throws SQLException {
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
> super.close();
> }
> }
> {code}
> but I think it should be probably the default behavior of BasicDataSource. Or perhaps there should be some flag/setting on BasicDataSource, named "deregisterDriverAtClose" or so.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.