Hi Jason,
You can enable monitoring jdbc-connection-pools and if connections are
not closed (leaked) by application, the difference in
NumConnAcquired and NumConnReleased will be increasing over the period.
Also, if your application has a ConnectionManager using which all
database getConnection() happens, logs during getConnection() and
closeConnection() will help to track the leaks.
Thanks,
-Jagadish
On Tue, 2007-04-10 at 09:15 -0500, Jason Lee wrote:
> Hrm. We're on v1 ur1 p01 in production. I guess I should have
> mentioned that. Is there anything like that for v1? I guess if it
> comes down to it, we might be able to upgrade to the beta (eek!), but
> we'd like to avoid upgrading now and then again in August-ish if we can.
> And by we, I mean me, as I'll be the guy pushing the bits. :P Thanks!
>
> -----
> Jason Lee, SCJP
> Senior Software Engineer
> http://www.iec-okc.com
>
>
> > -----Original Message-----
> > From: Jagadish.Ramu_at_Sun.COM [mailto:Jagadish.Ramu_at_Sun.COM]
> > Sent: Monday, April 09, 2007 9:59 PM
> > To: users_at_glassfish.dev.java.net
> > Subject: Re: Maxing out Connection Pools
> >
> > Hi Jason,
> > You can use "connection-leak-tracing" feature in GF V2 by
> > setting "connection-leak-timeout-in-seconds" value, eg: 180.
> > Once the specified period expires, stack trace of the thread
> > that requested the connection will be logged in server.log.
> > This will help to find the application code that is not
> > closing the connections.
> >
> > Thanks,
> > -Jagadish
> >
> > On Mon, 2007-04-09 at 14:55 -0500, Jason Lee wrote:
> > > We have an issue on our production server where we're maxing out a
> > > particular connection pool (which connects to SQL Server,
> > fwiw). If I
> > > look at the DB server, I can see all 128* connections, some of them
> > > showing that they connected several hours earlier. I would
> > think that
> > > the connection should idle out and be removed, but that does not
> > > appear to be happening. One of the frustrating things is
> > that we have
> > > no way (that we know of) of killing the connections from
> > the GlassFish
> > > side other than restart the server, nor do we know how to
> > tell which
> > > applications have the connection. Sadly, we have several JDBC
> > > resources pointing at the same pool, so we've done a bit of this to
> > > ourselves, but that's another issue for us. :P
> > >
> > > Is there a way to reset/close all connections for a given pool? Is
> > > there a way to figure out who the offending applications
> > are so we can
> > > try to fix them? Restarting is a bit jarring for our users. :P
> > >
> > > Thanks!
> > >
> > > -----
> > > Jason Lee, SCJP
> > > Senior Software Engineer
> > > http://www.iec-okc.com
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>