> On 2025 Aug 18, at 21:22, Daniel Schwartz <d...@danielgschwartz.com> wrote: > > I wasn't resisting using the try-with-resources construct, only when I tried > to do this, I was getting compiler errors. But I evidently wasn't doing it > right, because I tried it again and this time it worked. > > Following is the new code for getting the list of countries. It uses this > construct and in addition has an extra catch clause for any kind of > exception. I have done this in all six places where a connection is being > created. > > I restarted Glassfish earlier today and dropped in the new .war file. It has > been running for 6-8 hours now. The log files show no evidence of any > exceptions being thrown.
When you’re running GlassFish in your production environment, is it running as a service? If so, you’re not going to see anything written via System.out (or System.err), unless GlassFish has an option to redirect that to its internal logging mechanism. Tomcat has such an option, and GlassFish started as a fork of Tomcat many years ago, so such an option may well exist. > The current contents of the JDBC monitor page are copied below. I don't know > how to interpret most of this, but I do note that the number of connections > released equals the number acquired. Also, I have set the Connection Leak > Timeout to be 10 seconds, and the NumPotentialConnLeak is still at 0. However, there are a couple of stats that might be a bit concerning: of the 20 physical connections created, only 1 is free and 19 were destroyed. I would think that a pool would destroy connections only when it had to (eg, the connection is considered unsafe for reuse), although GlassFish does appear to have a mode where it discards connections after a while just in case. There’s also something odd with having only 1 free connection, since the pool is supposed to maintain a minimum of 8. Or were these statistics captured when the minimum was set to 1? > In addition, I did some further experimenting with the pool size, and now I > find that if I set the minimum back to 8 and the maximum to 32, which are the > defaults, the system keeps running and doesn't output that "can't allocate > more connections" message. For me this is very puzzling. Did my code > changes have anything to do with this? Not much else changed, so in all likelihood, yes. Note that the highest number of connections concurrently used is just 2, which is what we’d expect for an app like yours. > Anyway, my interpretation of all this is as before, that there are no memory > leaks. Is this correct? There don’t appear to be any with your revised code, at least up to this point (other than perhaps those 19 destroyed connections), but let it run for a few days and see what happens if the web crawlers start feeding garbage to your web service again. - Chuck --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
