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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
