Am 08.08.25 um 18:21 schrieb Daniel Schwartz:
Hello Robert,

 From your and other people's replies, I'm learning that tracking down memory 
leaks can be quite daunting and possibly beyond me.

I'm aware of the try-with-resources instruction and will look into it.  I wrote 
this code before learning about this.

In any case, I will follow your advice and add a "finally" block to the "try" 
statement.  I'm currently closing the connection in case an SQL exception is thrown, but I hadn't 
considered the possibility of other kinds of exceptions.  I suppose that there could be such 
exceptions, but I'm mystified regarding what those might be.

However, there has been a new development.  After "fishing" around in the 
Glassfish administration system, I found that there is a way to monitor the JDBC 
connection pool and get all sorts of information.  Based on this, I really don't think 
that there is any memory leak at all.

When running a simple query on my website, I see that NumConnAcquired increases 
by three (which is what I would expect), and immediately thereafter 
NumConnReleased increases by the same number.  So every connection that is 
being acquired is also being released.  I think that, if there were a memory 
leak, the number of connections acquired would be increasing at a faster pace 
than the number being released.

Also, there is a NumConnUsed statistic that has a "High Water Mark" which is described as 
the "maximum number of connections that were used", and this is currently 160, which is 
not a lot.

So, if every page hit takes up three connections (as I read it above), that would imply, that you have around 50ish concurrent page hits in maximum. Is that consistent with your data?

If so, you probably don't have a connection leak, but rather an unusual program design that uses (in my opinion) far too many connections for each page hit.

If you don't see a correlation between concurrent requests to your service and your database (now, that you are able to view those metrics), I would set the reclaim option for the database pool as described at https://glassfish.org/docs/latest/administration-guide.html#statement-leak-detection-and-leaked-statement-reclamation (note I haven't run Glassfish myself, but I like the log abandoned feature from tomcats db pool).

Felix


So it seems that the system is behaving normally.  And I have noticed that 
since setting the maximum pool size to 1000, the system has not crashed for 
several days.  Probably, 1000 is more than necessary, and you just need make 
sure you have more possible connections available than the anticipated future 
high-water mark.  But this seems to be working.

So maybe I'm just imagining problems that no longer exist.  As long as the 
system keeps running, I'm fine with this.


Thanks to everyone for their replies.

Dan

-----Original Message-----
From: Robert Turner<rtur...@e-djuster.ca.INVALID> Sent: Friday, August 8, 2025 1:32 AM
To: Tomcat Users List<users@tomcat.apache.org>
Subject: Re: How to access a REST service

(sorry for any errors, I'm bashing this out quickly on my phone before going to 
bed)

On Fri, Aug 8, 2025, 00:59 Daniel Schwartz<d...@danielgschwartz.com> wrote:

Hello Chuck,

You are correct, I only catch SQL exceptions.  I have modified my code
so that the Connection object will be closed if an SQL exception is
thrown, but I wasn’t aware that there are other types of exceptions
that I should look for.  I will look into this.


I would encourage entering "avoid java resource leak" into Google and reading the "AI" 
generated details or any other articles that come up. The "AI" description it gave me was a 
reasonable overview of what we are trying to convey to you and how to resolve it.

Unchecked exceptions can be thrown and the compiler will not warn about it.
This may be the issue, but it it not guaranteed, but it definitely is a 
potential and obvious problem with the code.

You need to ensure that everything related to the connection (connection, 
ResultSet, Statement, PreparedStatement) are also released (closed) or they 
will retain references to the connection and the connection may not be returned 
to the pool.

As previously mentioned by others, using try-with-resources for all of these 
objects is strongly recommended to avoid leaks. If you are uaing older Java 
(consider upgrading), you will need to use finally blocks instead (as 
previously mentioned by others).

Unfortunately, you have only posted a portion of the code, and it may be the 
case that it the problems stems from elsewhere (like where you make the 
queries, or anywhere else that obtains a connection).

It should be easy to get a tool to analyze the code (say your IDE (if you use 
one), PMD, Spotbugs, Sonarqube, etc.) and they would likely point out all the 
potential resource leaks. Many IDEs, such as Intellij IDEA, also provide such 
analysis built in. They basically look for any object derived from AutoClosable 
and ensure you are closing the object in a finally clause (or in all potential 
code paths). If you aren't, you have a leak.


However, I don’t think that this is causing a memory link, since my
code has always run perfectly without throwing any exceptions at all,
as far as I know.

You may not know. The container (Glassfish or Tomcat) often catches them and 
unless you are checking their logs, you may not see any evidence of them.


But I’m beginning to wonder if my “close” operation is actually being
recognized by Glassfish.  It seems possible that this is not being
communicated to Glassfish, and the Connection object continues to be
marked as being in use.  This would be a leak.  But I don’t know if
this is happening.

It's certainly possible that some behaviour of the container and it's pooling 
system is exasperating your issue, but I strongly doubt the container is at 
fault. It is almost guaranteed to be your code.


There are other possibly issues with your code, but these are less "critical" 
than your leaks, but could also be a potential source of issues.
Namely you have static Global's that are not protected against concurrency, and the 
containers typically run each request in separate threads. You could be creating more 
than one instance of your "singleton" as a result.



Dan

From: Chuck Caldarale<n82...@gmail.com>
Sent: Thursday, August 7, 2025 11:52 PM
To: Tomcat Users List<users@tomcat.apache.org>
Subject: Re: How to access a REST service

On 2025 Aug 7, at 21:43, Daniel Schwartz <d...@danielgschwartz.com
<mailto:d...@danielgschwartz.com>> wrote: > > I have just posted everything again, this time with a few modifications. You say, "Last
time you posted it, it was prone to leaking connection."
NkdkJdXPPEBannerStart
Be Careful With This Message
 From (Chuck Caldarale<n82...@gmail.com>)<
https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
Learn More<
https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
Potential Impersonation
The sender's identity could not be verified and someone may be
impersonating the sender. Take caution when interacting with this message.

NkdkJdXPPEBannerEnd



On 2025 Aug 7, at 21:43, Daniel Schwartz <d...@danielgschwartz.com
<mailto:d...@danielgschwartz.com>> wrote:

I have just posted everything again, this time with a few
modifications.  You say, "Last time you posted it, it was prone to
leaking connection."  Could you say more exactly where you see saw the leak?





You only catch errors of the type SQLException, which means anything
else will lose the connection. This is the reason you should always
use try - catch - finally (or the newer with-resources syntax) around
database manipulations, as recommended in Chris’ blog post.



   - Chuck





Thanks,
Dan Schwartz
-----Original Message-----
From: Robert Turner <rtur...@e-djuster.ca.INVALID<mailto:
rtur...@e-djuster.ca.INVALID>>

Sent: Thursday, August 7, 2025 5:07 PM
To: Tomcat Users List <users@tomcat.apache.org<mailto:
users@tomcat.apache.org>>

Subject: Re: How to access a REST service
Dan,
On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz
<d...@danielgschwartz.com
<mailto:d...@danielgschwartz.com>>

wrote:
Hello Chris,
Thank you for your reply, but I'm still unsure.  You seem to be
implying that I have a memory leak, i.e., many connection objects
being created that are not being closed.  However, I really don't
think this is happening.  My code closes each connection
immediately
after using it.

Maybe post your code again. Last time you posted it, it was prone to
leaking connections. If it hasn't changed, that is likely your problem.

My understanding is that the only way the maximum pool size of X,
whatever that is, would be a limitation is if there was an attempt
to
create X+1 simultaneous connections.  When you do this in
Glassfish,
it outputs an error message saying that no more connections can be
created and then crashes.  You have to go back in and manually
restart
it.

I believe that the essential problem, as explained in a previous
email
to Rob Sargent, is that I'm getting several hundred database
requests
per day from web crawlers.  I just spent some time reading through
my
ngnix access.log and found that the vast majority of these are from
GoogleBot.

My guess it that, due to a time lag between opening and closing
connections, many connections will be opened simultaneously.  This
is
why a small pool size won't work.
Also, I'm advised to not block the web crawlers because this
assists
with SEO.  My understanding is that you just have to live with this.
I don't think there is an issue with my code.  The only answer I
can
come up with is to have a large maximum pool size, larger that the
expected number of simultaneous accesses.
There is almost definitely a problem with your code (unfortunately),
or
your database requests are very slow and triggered by any connection.

We run servers that handle much more traffic than you are describing
and
make thousands of DB requests per minute, and we rarely go over 10 DB
connections being used at a time.

There is almost for sure something leaking in your code. This is
very
unlikely to be a problem with the pooling ("select isn't broken"). You
are looking for unlikely causes to the problem.

I originally wrote to this email list because I was thinking of
shifting from Glassfish to Tomcat, and was trying to learn how to
do
this.  I think I do know how to do this now, and might try doing this.
My understanding is that the connection pooling that works with
Tomcat
doesn't have that same limitation as Glassfish, and one can have
connections that exist outside the pool.  This would resolve the
issue
I'm currently having with Glassfish.
Best regards,
Dan Schwartz
...snip..
--------------------------------------------------------------------
-
To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org<mailto:
users-unsubscr...@tomcat.apache.org>

For additional commands, e-mail:users-h...@tomcat.apache.org<mailto:
users-h...@tomcat.apache.org>





---------------------------------------------------------------------

To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org<mailto: users-unsubscr...@tomcat.apache.org>

For additional commands, e-mail:users-h...@tomcat.apache.org<mailto: 
users-h...@tomcat.apache.org>



---------------------------------------------------------------------
To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:users-h...@tomcat.apache.org

Attachment: OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to