From: Rob Sargent <rsarg...@xmission.com> Sent: Friday, August 8, 2025 2:38 PM To: Tomcat Users List <users@tomcat.apache.org> Cc: Tomcat Users List <users@tomcat.apache.org> Subject: Re: How to access a REST service
> On Aug 8, 2025, at 10:23 AM, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > Hello > Robert, > > From your and other people's replies, I'm learning that tracking > down memory leaks can be quite daunting and possibly NkdkJdXPPEBannerStart Be Careful With This Message From (Rob Sargent <rsarg...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f45a39dd08e08288d170a1f429f310dcfc4c2682a0d5110f09626dd9f138e733ba0fa5243d9ee7dd687d549d0a6f29445fc21d4caf9da1e059ec09958dee9e37d7813463d01d3848dceb4ef4ec5293fb84050ce3cd2276b8bea19b4161d14dd83842327d0de3e096dbe18d41d87c4be5f369121ed17c58cd13506310466549992f7e6ec278a725774a1a15c0620add0aa3b640d9c525f8e4e45d3a21d533673a2570492beed254d67e15dcb77a6c36890130ddfd658990f8a258e01a1bc4b5ee7c9384bc31e32a6d8d5354f9e3cca8d5d137fb6f053a12592d66b61af21268785a1f165f20cdff25e> Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f45a39dd08e08288d170a1f429f310dcfc4c2682a0d5110f09626dd9f138e733ba0fa5243d9ee7dd687d549d0a6f29445fc21d4caf9da1e059ec09958dee9e37d7813463d01d3848dceb4ef4ec5293fb84050ce3cd2276b8bea19b4161d14dd83842327d0de3e096dbe18d41d87c4be5f369121ed17c58cd13506310466549992f7e6ec278a725774a1a15c0620add0aa3b640d9c525f8e4e45d3a21d533673a2570492beed254d67e15dcb77a6c36890130ddfd658990f8a258e01a1bc4b5ee7c9384bc31e32a6d8d5354f9e3cca8d5d137fb6f053a12592d66b61af21268785a1f165f20cdff25e> 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 Aug 8, 2025, at 10:23 AM, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > 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. I think most here agree 160 concurrently open db connections is a lot. I don’t recall if you gave the specs on your db server but that load would likely drag an average server quite a bit - most queries would be waiting for a chip. Can the db sever logs give a hint of when that peak was or what was being done? I was wondering about that too. I don't see any indication of when that 160 number occurred, but there is a date range of 8/4 through 8/8, so it could a tally of total connections over the past 4 days. I'm just not sure how to interpret many of the given data items, but there is one called "NumPotentialConnLeak" and the current value is "0 count", which I interpret as meaning that there currently are no leaks. I've decided to stop worrying about this for the time being. The system has been running okay for several days now. > > 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 > > -- --------------------------------------------------------------------- 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>
