On 8/15/25 21:03, Daniel Schwartz wrote:
Today I decided to run a test where I cleared out Glassfish so I could start
from scratch. I executed one REST request using the URL I posted recently,
which returns a list of countries. Then I looked at the Glassfish JDBC pool
monitor. A PDF of this is attached. You will see that it says the following:
1. NumConnAcquired, 1 count, Number of logical connection
2. NumConnReleased, 1 count, Number of logical connections released to the pool.
3. NumConnCreated, 8 count, The number of physical connections that were
created since the last reset.
4. NumConnFree, 8count, The total number of free connections in the pool as of
the last sampling.
I believe that this is why the minimum pool size is 8; each logical connection
requires 8 physical connections.
I believe you are misinterpreting this report. The 8 connections are
the pool. Your test used one of the 8, and returned it to the pool. No
connection leek. Yet.
This leads me to believe that this is why the number of connections in my
connection pool is much larger than what one would expect. Assuming that
Tomcat only requires one connection object per query, this implies that
Glassfish requires 8 times that amount. So, while a normal pool size for
Tomcat might be 20 connections, in Glassfish this same activity would require
160 connections.
In any case, I'm now 100% sure that my program doesn't, and never did, have a
memory leak. I have modified my code according to Chris's recommendations, as
this surely is good advice, but it hasn't changed the performance, since no
exceptions were ever being thrown.
It appears to me that Glassfish is performing normally according to its
internal design, and there really is no problem as long as I keep the maximum
pool size large enough.
What do you think?
Dan
I think that if you repeat that experiment with pool size of 1000
thousand, you will see line 3 of the report will have "NumConnCreated,
1000 count". And you haven't started leaking connections yet.
I think if you take Chris's advice and really hammer all your services
with curl or similar you will get NumPotentialConnLeak greater than 0.
