Skip to main content

JDBC Connection leak... how to spot the place?

6 replies [Last post]
Anonymous

Hi!

I've ported a fairly large PHP application to glassfish v3 + quercus.
Now I have the problem that somewhere JDBC-Connections don't get
closed and the number open connections continuously grow until
the max-pool-size is reached and the app stops working .

I'm getting: java.sql.SQLException: Error in allocating a connection.
Cause: In-use connections equal max-pool-size and expired
max-wait-time. Cannot allocate more connections.

I have connected myself to the server with JConsole, but now I'm somehow
lost... I'm able to see some nice graphs, a list of threads and to
browse MBeans.

I'm also trying VisualVM, but I'm lost here also, as I have never used
tools like that...

Any help would be greatly appreciated.

thanks,
dominik

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Hassan Schroeder

On Fri, Apr 16, 2010 at 10:41 AM, Dominik Dorn wrote:

> Now I have the problem that somewhere JDBC-Connections don't get
> closed and the number open connections continuously grow until
> the max-pool-size is reached and the app stops working .

Set your connection pool size to 1 and see what was executed just
before your app stops :-)

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jagadish Prasath Ramu

You can use connection leak tracing to figure out the block of
application code that is leaking the connections.
You can refer :
http://blogs.sun.com/kshitiz/entry/connection_leak_tracing

Thanks,
-Jagadish

On Fri, 2010-04-16 at 19:41 +0200, Dominik Dorn wrote:
> Hi!
>
> I've ported a fairly large PHP application to glassfish v3 + quercus.
> Now I have the problem that somewhere JDBC-Connections don't get
> closed and the number open connections continuously grow until
> the max-pool-size is reached and the app stops working .
>
> I'm getting: java.sql.SQLException: Error in allocating a connection.
> Cause: In-use connections equal max-pool-size and expired
> max-wait-time. Cannot allocate more connections.
>
> I have connected myself to the server with JConsole, but now I'm somehow
> lost... I'm able to see some nice graphs, a list of threads and to
> browse MBeans.
>
> I'm also trying VisualVM, but I'm lost here also, as I have never used
> tools like that...
>
>
> Any help would be greatly appreciated.
>
>
> thanks,
> dominik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Dominik Dorn

Hello Jagadish,

I was able to set connection leak detection for the connectionpool.

However, I'm unable to find the equivalent of this screenshot in Glassfish v3
http://blogs.sun.com/kshitiz/resource/clt/monitor.gif

Could you give me a hint?

Thanks,
Dominik

@Hassan: The App currently runs in "public beta", so that would just
make the App break sooner, but I still would not know where exactly it happened,
or am I missing the point here?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Hassan Schroeder

On Sat, Apr 17, 2010 at 5:44 AM, Dominik Dorn wrote:

> @Hassan: The App currently runs in "public beta", so that would just
> make the App break sooner, but I still would not know where exactly it happened,
> or am I missing the point here?

I'd hope you can either run it locally on your own system or you have
a test/staging server to play with. :-)

And if you're the one using it, you'll know what part of the code you're
exercising when it locks up! Judicious use of debugging statements
in the code and running tail -f on your log file will help narrow it down.

YMMV, but it's certainly worked for me in the past.

--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
twitter: @hassan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Dominik Dorn

I actually think I have found the problem with the help of the
connection-leak detection thing... it writes to the server.log file
when it "thinks" it found a leak
including a full stack trace.

Thanks for the help.

dominik

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Martin Gainty

Hi Dominik

i think what you're describing is more common than most of is would ever know it would be helpful if we had the right tools and/or heavy logging to constantly check connection handles and statement handles

Could you describe the specific symptoms of how you detected this connection leak and how you solved this?

Thanks,
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.

> From: dominik.dorn@gmail.com
> Date: Sat, 17 Apr 2010 16:30:00 +0200
> To: users@glassfish.dev.java.net
> Subject: Re: JDBC Connection leak... how to spot the place?
>
> I actually think I have found the problem with the help of the
> connection-leak detection thing... it writes to the server.log file
> when it "thinks" it found a leak
> including a full stack trace.
>
> Thanks for the help.
>
> dominik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:...
[att1.html]