> On Aug 8, 2025, at 10:23 AM, Daniel Schwartz <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?
>
> 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
For additional commands, e-mail: users-h...@tomcat.apache.org
