You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bogdan Calmac <bc...@gmail.com> on 2005/10/26 03:17:49 UTC
DBCP connection leak after undeploy
I've written a simple web application consisting of a servlet which
does a select from a table and displays the result. It is then
packaged as a war and deployed using the tomcat ant task. After
executing the servlet, it is undeployed using the ant task again.
stdout confirms that the webapp is deployed and undeployed without
errors. The problem is that the connection to the DB is left open even
after undeploy.
Software used:
- tomcat 5.5.9 on Windows
- DBCP connection pool
- MSSQL server
The datasource is defined in META-INF/context.xml with:
<Resource name="jdbc/default" auth="Container" type="javax.sql.DataSource"
maxActive="5" maxIdle="2" maxWait="10000"
username="sa" password="sa"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sqlserver://localhost/pubs"/>
and then referenced in WEB-INF/web.xml with:
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/default</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
The code accessing the database is:
private long getTitlesCount() {
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
try {
InitialContext cxt = new InitialContext();
DataSource ds = (DataSource) cxt.lookup(
"java:/comp/env/jdbc/default" );
conn = ds.getConnection();
stmt = conn.createStatement();
rs = stmt.executeQuery("select count(*) from titles");
if (rs.next())
return rs.getLong(1);
}
catch(Exception e) {
System.out.println("Failed to retrive title count from the DB.");
e.printStackTrace();
}
finally {
if (rs != null) try { rs.close(); } catch (Exception e) {}
if (stmt != null) try { stmt.close(); } catch (Exception e) {}
if (conn != null) try { conn.close(); } catch (Exception e) {}
}
return -1;
}
If I deploy/undeploy several times, the number of leaked connections
is incremented with 1 each time.
If I execute the servlet several times, the number of connections
remains constant, which confirms that the servlet releases the
connection properly.
My guess is that the datasource is not tied to the webapp and it is
not notified/released when the webapp is undeployed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP connection leak after undeploy
Posted by Bogdan Calmac <bc...@gmail.com>.
Correct.
On 10/31/05, Steve Kirk <to...@web-startup.co.uk> wrote:
>
> I was thinking that you could write your own ServletContextListener code to
> create/close the pool, so that you do not have to rely on TC to manage DBCP
> via JNDI. I am planning to do this myself sometime soon, for other reasons
> (you've just given me another one). I'm thinking that by not using JNDI, I
> would not encounter of the problem you mention below, because the problem is
> related to the TC-JNDI interface. Does that sound right to you?
>
> > -----Original Message-----
> > From: Bogdan Calmac [mailto:bc4all@gmail.com]
> > Sent: Monday 31 October 2005 16:50
> > To: Tomcat Users List
> > Subject: Re: DBCP connection leak after undeploy
> >
> >
> > In our company we share several Tomcat servers for all developers, so
> > that's why we use deploy/undeploy instead of start/stop.
> >
> > As a workaround for this problem, you can create a
> > ServletContextListener and close the datasource yourself in
> > contextDestroyed(). I used refection here to avoid compile time
> > dependency on Tomcat DBCP.
> >
> > try
> > {
> > Context initCtx = new InitialContext();
> > ds = (DataSource)
> > initCtx.lookup("java:comp/env/jdbc/YourDSName");
> > if ("org.apache.tomcat.dbcp.dbcp.BasicDataSource".equals(
> > ds.getClass().getName()))
> > {
> > Method closeMethod = ds.getClass().getMethod("close");
> > closeMethod.invoke(ds);
> > }
> > catch (Exception e)
> > {
> > yourLog.error("Failed to close DBCP DataSource.", e);
> > }
> >
> > The above code would actually not work because JNDI is destroyed by
> > the time contextDestroyed() is called (see
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=37264) so you could
> > do the lookup and cache the datasource object in contextInitialized().
> >
> > On 10/28/05, Steve Kirk <to...@web-startup.co.uk> wrote:
> > > Yes, confirmed, I get the same problem. (I used the
> > undeploy command from
> > > within the NetBeans runtime window, and also checked using
> > the undeploy link
> > > in the browser from /manager/html/). Conns are cleaned up OK if you
> > > start/stop TC, but not if you undeploy the app with TC
> > still running, as you
> > > said.
> > >
> > > Having said that, does anyone undeploy apps like this on
> > production servers?
> > > I wouldn't think so, but then again I suppose it might
> > affect ISP type
> > > users.
> > >
> > > PS I have these config values:
> > > maxActive="10"
> > > maxIdle="5"
> > >
> > > > -----Original Message-----
> > > > From: Bogdan Calmac [mailto:bc4all@gmail.com]
> > > > Sent: Thursday 27 October 2005 19:27
> > > > To: Tomcat Users List
> > > > Subject: Re: DBCP connection leak after undeploy
> > > >
> > > >
> > > > > PS I don't think that I have see the problem that you have
> > > > reported. I run
> > > > > TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8,
> > > > have never
> > > > > noticed that problem, my pools always seem to clean up fine.
> > > >
> > > > You might not have the same setup. I would suggest to try the
> > > > following:
> > > >
> > > > 1. make sure you define the datasource in
> > META-INF/context.xml and you
> > > > access the DB using that JNDI datasource.
> > > > 2. package your webapp as a war
> > > > 3. Do a "netstat" and note how many DB connections are open
> > > > 4. deploy your webapp using the ant task or the manager webapp
> > > > 5. Access your webapp to use the DB
> > > > 6. Do another "netstat" to confirm that there is one more DB
> > > > connection (which is now pooled)
> > > > 7. undeploy your webapp using the ant task or the manager
> > webapp (do
> > > > not stop tomcat)
> > > > 8. Do one more "netstat" and I would be very surprised if
> > the extra
> > > > connection was closed :-)
> > > >
> > > > Another explanation for your finding could be setting
> > maxIdle="0" in
> > > > the resource definition, but that practically disables pooling.
> > > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: DBCP connection leak after undeploy
Posted by Steve Kirk <to...@web-startup.co.uk>.
I was thinking that you could write your own ServletContextListener code to
create/close the pool, so that you do not have to rely on TC to manage DBCP
via JNDI. I am planning to do this myself sometime soon, for other reasons
(you've just given me another one). I'm thinking that by not using JNDI, I
would not encounter of the problem you mention below, because the problem is
related to the TC-JNDI interface. Does that sound right to you?
> -----Original Message-----
> From: Bogdan Calmac [mailto:bc4all@gmail.com]
> Sent: Monday 31 October 2005 16:50
> To: Tomcat Users List
> Subject: Re: DBCP connection leak after undeploy
>
>
> In our company we share several Tomcat servers for all developers, so
> that's why we use deploy/undeploy instead of start/stop.
>
> As a workaround for this problem, you can create a
> ServletContextListener and close the datasource yourself in
> contextDestroyed(). I used refection here to avoid compile time
> dependency on Tomcat DBCP.
>
> try
> {
> Context initCtx = new InitialContext();
> ds = (DataSource)
> initCtx.lookup("java:comp/env/jdbc/YourDSName");
> if ("org.apache.tomcat.dbcp.dbcp.BasicDataSource".equals(
> ds.getClass().getName()))
> {
> Method closeMethod = ds.getClass().getMethod("close");
> closeMethod.invoke(ds);
> }
> catch (Exception e)
> {
> yourLog.error("Failed to close DBCP DataSource.", e);
> }
>
> The above code would actually not work because JNDI is destroyed by
> the time contextDestroyed() is called (see
> http://issues.apache.org/bugzilla/show_bug.cgi?id=37264) so you could
> do the lookup and cache the datasource object in contextInitialized().
>
> On 10/28/05, Steve Kirk <to...@web-startup.co.uk> wrote:
> > Yes, confirmed, I get the same problem. (I used the
> undeploy command from
> > within the NetBeans runtime window, and also checked using
> the undeploy link
> > in the browser from /manager/html/). Conns are cleaned up OK if you
> > start/stop TC, but not if you undeploy the app with TC
> still running, as you
> > said.
> >
> > Having said that, does anyone undeploy apps like this on
> production servers?
> > I wouldn't think so, but then again I suppose it might
> affect ISP type
> > users.
> >
> > PS I have these config values:
> > maxActive="10"
> > maxIdle="5"
> >
> > > -----Original Message-----
> > > From: Bogdan Calmac [mailto:bc4all@gmail.com]
> > > Sent: Thursday 27 October 2005 19:27
> > > To: Tomcat Users List
> > > Subject: Re: DBCP connection leak after undeploy
> > >
> > >
> > > > PS I don't think that I have see the problem that you have
> > > reported. I run
> > > > TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8,
> > > have never
> > > > noticed that problem, my pools always seem to clean up fine.
> > >
> > > You might not have the same setup. I would suggest to try the
> > > following:
> > >
> > > 1. make sure you define the datasource in
> META-INF/context.xml and you
> > > access the DB using that JNDI datasource.
> > > 2. package your webapp as a war
> > > 3. Do a "netstat" and note how many DB connections are open
> > > 4. deploy your webapp using the ant task or the manager webapp
> > > 5. Access your webapp to use the DB
> > > 6. Do another "netstat" to confirm that there is one more DB
> > > connection (which is now pooled)
> > > 7. undeploy your webapp using the ant task or the manager
> webapp (do
> > > not stop tomcat)
> > > 8. Do one more "netstat" and I would be very surprised if
> the extra
> > > connection was closed :-)
> > >
> > > Another explanation for your finding could be setting
> maxIdle="0" in
> > > the resource definition, but that practically disables pooling.
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP connection leak after undeploy
Posted by Bogdan Calmac <bc...@gmail.com>.
In our company we share several Tomcat servers for all developers, so
that's why we use deploy/undeploy instead of start/stop.
As a workaround for this problem, you can create a
ServletContextListener and close the datasource yourself in
contextDestroyed(). I used refection here to avoid compile time
dependency on Tomcat DBCP.
try
{
Context initCtx = new InitialContext();
ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/YourDSName");
if ("org.apache.tomcat.dbcp.dbcp.BasicDataSource".equals(
ds.getClass().getName()))
{
Method closeMethod = ds.getClass().getMethod("close");
closeMethod.invoke(ds);
}
catch (Exception e)
{
yourLog.error("Failed to close DBCP DataSource.", e);
}
The above code would actually not work because JNDI is destroyed by
the time contextDestroyed() is called (see
http://issues.apache.org/bugzilla/show_bug.cgi?id=37264) so you could
do the lookup and cache the datasource object in contextInitialized().
On 10/28/05, Steve Kirk <to...@web-startup.co.uk> wrote:
> Yes, confirmed, I get the same problem. (I used the undeploy command from
> within the NetBeans runtime window, and also checked using the undeploy link
> in the browser from /manager/html/). Conns are cleaned up OK if you
> start/stop TC, but not if you undeploy the app with TC still running, as you
> said.
>
> Having said that, does anyone undeploy apps like this on production servers?
> I wouldn't think so, but then again I suppose it might affect ISP type
> users.
>
> PS I have these config values:
> maxActive="10"
> maxIdle="5"
>
> > -----Original Message-----
> > From: Bogdan Calmac [mailto:bc4all@gmail.com]
> > Sent: Thursday 27 October 2005 19:27
> > To: Tomcat Users List
> > Subject: Re: DBCP connection leak after undeploy
> >
> >
> > > PS I don't think that I have see the problem that you have
> > reported. I run
> > > TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8,
> > have never
> > > noticed that problem, my pools always seem to clean up fine.
> >
> > You might not have the same setup. I would suggest to try the
> > following:
> >
> > 1. make sure you define the datasource in META-INF/context.xml and you
> > access the DB using that JNDI datasource.
> > 2. package your webapp as a war
> > 3. Do a "netstat" and note how many DB connections are open
> > 4. deploy your webapp using the ant task or the manager webapp
> > 5. Access your webapp to use the DB
> > 6. Do another "netstat" to confirm that there is one more DB
> > connection (which is now pooled)
> > 7. undeploy your webapp using the ant task or the manager webapp (do
> > not stop tomcat)
> > 8. Do one more "netstat" and I would be very surprised if the extra
> > connection was closed :-)
> >
> > Another explanation for your finding could be setting maxIdle="0" in
> > the resource definition, but that practically disables pooling.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: DBCP connection leak after undeploy
Posted by Steve Kirk <to...@web-startup.co.uk>.
Yes, confirmed, I get the same problem. (I used the undeploy command from
within the NetBeans runtime window, and also checked using the undeploy link
in the browser from /manager/html/). Conns are cleaned up OK if you
start/stop TC, but not if you undeploy the app with TC still running, as you
said.
Having said that, does anyone undeploy apps like this on production servers?
I wouldn't think so, but then again I suppose it might affect ISP type
users.
PS I have these config values:
maxActive="10"
maxIdle="5"
> -----Original Message-----
> From: Bogdan Calmac [mailto:bc4all@gmail.com]
> Sent: Thursday 27 October 2005 19:27
> To: Tomcat Users List
> Subject: Re: DBCP connection leak after undeploy
>
>
> > PS I don't think that I have see the problem that you have
> reported. I run
> > TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8,
> have never
> > noticed that problem, my pools always seem to clean up fine.
>
> You might not have the same setup. I would suggest to try the
> following:
>
> 1. make sure you define the datasource in META-INF/context.xml and you
> access the DB using that JNDI datasource.
> 2. package your webapp as a war
> 3. Do a "netstat" and note how many DB connections are open
> 4. deploy your webapp using the ant task or the manager webapp
> 5. Access your webapp to use the DB
> 6. Do another "netstat" to confirm that there is one more DB
> connection (which is now pooled)
> 7. undeploy your webapp using the ant task or the manager webapp (do
> not stop tomcat)
> 8. Do one more "netstat" and I would be very surprised if the extra
> connection was closed :-)
>
> Another explanation for your finding could be setting maxIdle="0" in
> the resource definition, but that practically disables pooling.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP connection leak after undeploy
Posted by Bogdan Calmac <bc...@gmail.com>.
> PS I don't think that I have see the problem that you have reported. I run
> TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8, have never
> noticed that problem, my pools always seem to clean up fine.
You might not have the same setup. I would suggest to try the following:
1. make sure you define the datasource in META-INF/context.xml and you
access the DB using that JNDI datasource.
2. package your webapp as a war
3. Do a "netstat" and note how many DB connections are open
4. deploy your webapp using the ant task or the manager webapp
5. Access your webapp to use the DB
6. Do another "netstat" to confirm that there is one more DB
connection (which is now pooled)
7. undeploy your webapp using the ant task or the manager webapp (do
not stop tomcat)
8. Do one more "netstat" and I would be very surprised if the extra
connection was closed :-)
Another explanation for your finding could be setting maxIdle="0" in
the resource definition, but that practically disables pooling.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: DBCP connection leak after undeploy
Posted by Steve Kirk <to...@web-startup.co.uk>.
Interesting, thanks for mailing to the list.
Have you considered whether managing the DBCP resource yourself might help?
In other words you don't have to use the TC container-managed method of
declaring DBCP resources if you don't want to. If you wrote a
ServletContextListener to create and close the pool and make it available to
your webapp, you would have more control over these issues (or to put it
another way, you could choose to write the "glueing integration code"
yourself).
I have this on my "to do" list, because of other issues around using
container managed resources. Have not done it yet but I have some quick and
dirty code that does it, which I need to combine/adapt.
PS I don't think that I have see the problem that you have reported. I run
TC 5.5.9 on WinXP with Mysql 4.1.11 and Connector/J 3.1.8, have never
noticed that problem, my pools always seem to clean up fine.
> -----Original Message-----
> From: Bogdan Calmac [mailto:bc4all@gmail.com]
> Sent: Thursday 27 October 2005 16:49
> To: Tomcat Users List
> Subject: Re: DBCP connection leak after undeploy
>
>
> This problem is caused by Tomcat not cleaning up the JDBC resources
> defined in context.xml. When a context is stopped the DBCP resource is
> not notified and the pooled connections are leaked. I've submitted a
> bug along with a fix
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=37262) but it was
> rejected on the grounds that DBCP is an some external library and
> tomcat should not contain any glueing integration code.
>
> I'm not verry happy about it, because connection leaks seem like a
> pretty serious issue to me. But hey, why do I complain, I din not pay
> a dime for Tomcat, right?
>
> On 10/26/05, Bogdan Calmac <bc...@gmail.com> wrote:
> > When tomcat is stopped the connection is closed. I'll
> probably submit
> > the example to bugzilla. Can somebody familiar with the code suggest
> > which catalina object keeps a reference of the datasource (beside
> > being registered in JNDI)?
> >
> > On 10/26/05, Steve Kirk <to...@web-startup.co.uk> wrote:
> > >
> > > Your code and config below look fine to me, conns seem to
> be returned OK to
> > > pool as you say. Sounds to me like the pool itself
> leaves the database with
> > > hanging conns in the pool when it goes down.
> > >
> > > When you say "If I deploy/undeploy several times" do you
> stop and restart TC
> > > between undeploy and redeploy? If so, might be worth
> trying to see whether
> > > the problem still happens if you stop and restart TC
> cleanly rather than
> > > redeploying the webapp while TC is running? Might help
> narrow down the
> > > cause slightly. Might be worth reporting to bugzilla?
> > >
> > > > -----Original Message-----
> > > > From: Bogdan Calmac [mailto:bc4all@gmail.com]
> > > > Sent: Wednesday 26 October 2005 02:18
> > > > To: users@tomcat.apache.org
> > > > Subject: DBCP connection leak after undeploy
> > > >
> > > >
> > > > I've written a simple web application consisting of a
> servlet which
> > > > does a select from a table and displays the result. It is then
> > > > packaged as a war and deployed using the tomcat ant task. After
> > > > executing the servlet, it is undeployed using the ant
> task again.
> > > > stdout confirms that the webapp is deployed and
> undeployed without
> > > > errors. The problem is that the connection to the DB is
> left open even
> > > > after undeploy.
> > > >
> > > > Software used:
> > > > - tomcat 5.5.9 on Windows
> > > > - DBCP connection pool
> > > > - MSSQL server
> > > >
> > > > The datasource is defined in META-INF/context.xml with:
> > > >
> > > > <Resource name="jdbc/default" auth="Container"
> > > > type="javax.sql.DataSource"
> > > > maxActive="5" maxIdle="2" maxWait="10000"
> > > > username="sa" password="sa"
> > > >
> driverClassName="net.sourceforge.jtds.jdbc.Driver"
> > > > url="jdbc:jtds:sqlserver://localhost/pubs"/>
> > > >
> > > > and then referenced in WEB-INF/web.xml with:
> > > >
> > > > <resource-ref>
> > > > <description>DB Connection</description>
> > > > <res-ref-name>jdbc/default</res-ref-name>
> > > > <res-type>javax.sql.DataSource</res-type>
> > > > <res-auth>Container</res-auth>
> > > > </resource-ref>
> > > >
> > > > The code accessing the database is:
> > > >
> > > > private long getTitlesCount() {
> > > > Connection conn = null;
> > > > Statement stmt = null;
> > > > ResultSet rs = null;
> > > > try {
> > > > InitialContext cxt = new InitialContext();
> > > > DataSource ds = (DataSource) cxt.lookup(
> > > > "java:/comp/env/jdbc/default" );
> > > > conn = ds.getConnection();
> > > > stmt = conn.createStatement();
> > > > rs = stmt.executeQuery("select count(*) from titles");
> > > > if (rs.next())
> > > > return rs.getLong(1);
> > > >
> > > > }
> > > > catch(Exception e) {
> > > > System.out.println("Failed to retrive title count
> > > > from the DB.");
> > > > e.printStackTrace();
> > > > }
> > > > finally {
> > > > if (rs != null) try { rs.close(); } catch
> (Exception e) {}
> > > > if (stmt != null) try { stmt.close(); } catch
> (Exception e) {}
> > > > if (conn != null) try { conn.close(); } catch
> (Exception e) {}
> > > > }
> > > > return -1;
> > > > }
> > > >
> > > >
> > > > If I deploy/undeploy several times, the number of
> leaked connections
> > > > is incremented with 1 each time.
> > > >
> > > > If I execute the servlet several times, the number of
> connections
> > > > remains constant, which confirms that the servlet releases the
> > > > connection properly.
> > > >
> > > > My guess is that the datasource is not tied to the
> webapp and it is
> > > > not notified/released when the webapp is undeployed.
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: users-help@tomcat.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP connection leak after undeploy
Posted by Bogdan Calmac <bc...@gmail.com>.
This problem is caused by Tomcat not cleaning up the JDBC resources
defined in context.xml. When a context is stopped the DBCP resource is
not notified and the pooled connections are leaked. I've submitted a
bug along with a fix
(http://issues.apache.org/bugzilla/show_bug.cgi?id=37262) but it was
rejected on the grounds that DBCP is an some external library and
tomcat should not contain any glueing integration code.
I'm not verry happy about it, because connection leaks seem like a
pretty serious issue to me. But hey, why do I complain, I din not pay
a dime for Tomcat, right?
On 10/26/05, Bogdan Calmac <bc...@gmail.com> wrote:
> When tomcat is stopped the connection is closed. I'll probably submit
> the example to bugzilla. Can somebody familiar with the code suggest
> which catalina object keeps a reference of the datasource (beside
> being registered in JNDI)?
>
> On 10/26/05, Steve Kirk <to...@web-startup.co.uk> wrote:
> >
> > Your code and config below look fine to me, conns seem to be returned OK to
> > pool as you say. Sounds to me like the pool itself leaves the database with
> > hanging conns in the pool when it goes down.
> >
> > When you say "If I deploy/undeploy several times" do you stop and restart TC
> > between undeploy and redeploy? If so, might be worth trying to see whether
> > the problem still happens if you stop and restart TC cleanly rather than
> > redeploying the webapp while TC is running? Might help narrow down the
> > cause slightly. Might be worth reporting to bugzilla?
> >
> > > -----Original Message-----
> > > From: Bogdan Calmac [mailto:bc4all@gmail.com]
> > > Sent: Wednesday 26 October 2005 02:18
> > > To: users@tomcat.apache.org
> > > Subject: DBCP connection leak after undeploy
> > >
> > >
> > > I've written a simple web application consisting of a servlet which
> > > does a select from a table and displays the result. It is then
> > > packaged as a war and deployed using the tomcat ant task. After
> > > executing the servlet, it is undeployed using the ant task again.
> > > stdout confirms that the webapp is deployed and undeployed without
> > > errors. The problem is that the connection to the DB is left open even
> > > after undeploy.
> > >
> > > Software used:
> > > - tomcat 5.5.9 on Windows
> > > - DBCP connection pool
> > > - MSSQL server
> > >
> > > The datasource is defined in META-INF/context.xml with:
> > >
> > > <Resource name="jdbc/default" auth="Container"
> > > type="javax.sql.DataSource"
> > > maxActive="5" maxIdle="2" maxWait="10000"
> > > username="sa" password="sa"
> > > driverClassName="net.sourceforge.jtds.jdbc.Driver"
> > > url="jdbc:jtds:sqlserver://localhost/pubs"/>
> > >
> > > and then referenced in WEB-INF/web.xml with:
> > >
> > > <resource-ref>
> > > <description>DB Connection</description>
> > > <res-ref-name>jdbc/default</res-ref-name>
> > > <res-type>javax.sql.DataSource</res-type>
> > > <res-auth>Container</res-auth>
> > > </resource-ref>
> > >
> > > The code accessing the database is:
> > >
> > > private long getTitlesCount() {
> > > Connection conn = null;
> > > Statement stmt = null;
> > > ResultSet rs = null;
> > > try {
> > > InitialContext cxt = new InitialContext();
> > > DataSource ds = (DataSource) cxt.lookup(
> > > "java:/comp/env/jdbc/default" );
> > > conn = ds.getConnection();
> > > stmt = conn.createStatement();
> > > rs = stmt.executeQuery("select count(*) from titles");
> > > if (rs.next())
> > > return rs.getLong(1);
> > >
> > > }
> > > catch(Exception e) {
> > > System.out.println("Failed to retrive title count
> > > from the DB.");
> > > e.printStackTrace();
> > > }
> > > finally {
> > > if (rs != null) try { rs.close(); } catch (Exception e) {}
> > > if (stmt != null) try { stmt.close(); } catch (Exception e) {}
> > > if (conn != null) try { conn.close(); } catch (Exception e) {}
> > > }
> > > return -1;
> > > }
> > >
> > >
> > > If I deploy/undeploy several times, the number of leaked connections
> > > is incremented with 1 each time.
> > >
> > > If I execute the servlet several times, the number of connections
> > > remains constant, which confirms that the servlet releases the
> > > connection properly.
> > >
> > > My guess is that the datasource is not tied to the webapp and it is
> > > not notified/released when the webapp is undeployed.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP connection leak after undeploy
Posted by Bogdan Calmac <bc...@gmail.com>.
When tomcat is stopped the connection is closed. I'll probably submit
the example to bugzilla. Can somebody familiar with the code suggest
which catalina object keeps a reference of the datasource (beside
being registered in JNDI)?
On 10/26/05, Steve Kirk <to...@web-startup.co.uk> wrote:
>
> Your code and config below look fine to me, conns seem to be returned OK to
> pool as you say. Sounds to me like the pool itself leaves the database with
> hanging conns in the pool when it goes down.
>
> When you say "If I deploy/undeploy several times" do you stop and restart TC
> between undeploy and redeploy? If so, might be worth trying to see whether
> the problem still happens if you stop and restart TC cleanly rather than
> redeploying the webapp while TC is running? Might help narrow down the
> cause slightly. Might be worth reporting to bugzilla?
>
> > -----Original Message-----
> > From: Bogdan Calmac [mailto:bc4all@gmail.com]
> > Sent: Wednesday 26 October 2005 02:18
> > To: users@tomcat.apache.org
> > Subject: DBCP connection leak after undeploy
> >
> >
> > I've written a simple web application consisting of a servlet which
> > does a select from a table and displays the result. It is then
> > packaged as a war and deployed using the tomcat ant task. After
> > executing the servlet, it is undeployed using the ant task again.
> > stdout confirms that the webapp is deployed and undeployed without
> > errors. The problem is that the connection to the DB is left open even
> > after undeploy.
> >
> > Software used:
> > - tomcat 5.5.9 on Windows
> > - DBCP connection pool
> > - MSSQL server
> >
> > The datasource is defined in META-INF/context.xml with:
> >
> > <Resource name="jdbc/default" auth="Container"
> > type="javax.sql.DataSource"
> > maxActive="5" maxIdle="2" maxWait="10000"
> > username="sa" password="sa"
> > driverClassName="net.sourceforge.jtds.jdbc.Driver"
> > url="jdbc:jtds:sqlserver://localhost/pubs"/>
> >
> > and then referenced in WEB-INF/web.xml with:
> >
> > <resource-ref>
> > <description>DB Connection</description>
> > <res-ref-name>jdbc/default</res-ref-name>
> > <res-type>javax.sql.DataSource</res-type>
> > <res-auth>Container</res-auth>
> > </resource-ref>
> >
> > The code accessing the database is:
> >
> > private long getTitlesCount() {
> > Connection conn = null;
> > Statement stmt = null;
> > ResultSet rs = null;
> > try {
> > InitialContext cxt = new InitialContext();
> > DataSource ds = (DataSource) cxt.lookup(
> > "java:/comp/env/jdbc/default" );
> > conn = ds.getConnection();
> > stmt = conn.createStatement();
> > rs = stmt.executeQuery("select count(*) from titles");
> > if (rs.next())
> > return rs.getLong(1);
> >
> > }
> > catch(Exception e) {
> > System.out.println("Failed to retrive title count
> > from the DB.");
> > e.printStackTrace();
> > }
> > finally {
> > if (rs != null) try { rs.close(); } catch (Exception e) {}
> > if (stmt != null) try { stmt.close(); } catch (Exception e) {}
> > if (conn != null) try { conn.close(); } catch (Exception e) {}
> > }
> > return -1;
> > }
> >
> >
> > If I deploy/undeploy several times, the number of leaked connections
> > is incremented with 1 each time.
> >
> > If I execute the servlet several times, the number of connections
> > remains constant, which confirms that the servlet releases the
> > connection properly.
> >
> > My guess is that the datasource is not tied to the webapp and it is
> > not notified/released when the webapp is undeployed.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: DBCP connection leak after undeploy
Posted by Steve Kirk <to...@web-startup.co.uk>.
Your code and config below look fine to me, conns seem to be returned OK to
pool as you say. Sounds to me like the pool itself leaves the database with
hanging conns in the pool when it goes down.
When you say "If I deploy/undeploy several times" do you stop and restart TC
between undeploy and redeploy? If so, might be worth trying to see whether
the problem still happens if you stop and restart TC cleanly rather than
redeploying the webapp while TC is running? Might help narrow down the
cause slightly. Might be worth reporting to bugzilla?
> -----Original Message-----
> From: Bogdan Calmac [mailto:bc4all@gmail.com]
> Sent: Wednesday 26 October 2005 02:18
> To: users@tomcat.apache.org
> Subject: DBCP connection leak after undeploy
>
>
> I've written a simple web application consisting of a servlet which
> does a select from a table and displays the result. It is then
> packaged as a war and deployed using the tomcat ant task. After
> executing the servlet, it is undeployed using the ant task again.
> stdout confirms that the webapp is deployed and undeployed without
> errors. The problem is that the connection to the DB is left open even
> after undeploy.
>
> Software used:
> - tomcat 5.5.9 on Windows
> - DBCP connection pool
> - MSSQL server
>
> The datasource is defined in META-INF/context.xml with:
>
> <Resource name="jdbc/default" auth="Container"
> type="javax.sql.DataSource"
> maxActive="5" maxIdle="2" maxWait="10000"
> username="sa" password="sa"
> driverClassName="net.sourceforge.jtds.jdbc.Driver"
> url="jdbc:jtds:sqlserver://localhost/pubs"/>
>
> and then referenced in WEB-INF/web.xml with:
>
> <resource-ref>
> <description>DB Connection</description>
> <res-ref-name>jdbc/default</res-ref-name>
> <res-type>javax.sql.DataSource</res-type>
> <res-auth>Container</res-auth>
> </resource-ref>
>
> The code accessing the database is:
>
> private long getTitlesCount() {
> Connection conn = null;
> Statement stmt = null;
> ResultSet rs = null;
> try {
> InitialContext cxt = new InitialContext();
> DataSource ds = (DataSource) cxt.lookup(
> "java:/comp/env/jdbc/default" );
> conn = ds.getConnection();
> stmt = conn.createStatement();
> rs = stmt.executeQuery("select count(*) from titles");
> if (rs.next())
> return rs.getLong(1);
>
> }
> catch(Exception e) {
> System.out.println("Failed to retrive title count
> from the DB.");
> e.printStackTrace();
> }
> finally {
> if (rs != null) try { rs.close(); } catch (Exception e) {}
> if (stmt != null) try { stmt.close(); } catch (Exception e) {}
> if (conn != null) try { conn.close(); } catch (Exception e) {}
> }
> return -1;
> }
>
>
> If I deploy/undeploy several times, the number of leaked connections
> is incremented with 1 each time.
>
> If I execute the servlet several times, the number of connections
> remains constant, which confirms that the servlet releases the
> connection properly.
>
> My guess is that the datasource is not tied to the webapp and it is
> not notified/released when the webapp is undeployed.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org