Chuck, Robert, Rob, There was a Chris too, but I think he made his recommendation and left. I'm coming to think that his advice was the best, namely, to just live with the current situation as long as it is working.
Anyway, today I reviewed my code and ran a few more tests. Here is what I found. I found one .jar file where I opened three preparedStatements and neglected to close them. I fixed this, but it had no effect on the system performance. In the main file where I open and close the DB connections, after each open instruction I put in a println statement to output a message like "opened getJsonCountries connection", and right after each close instruction I put in a println statement to output a message like "closed getJsonCountries connection". There are six of these. I then processed a typical query through my client interface and looked in the Glassfish log file, where I saw that every opened connection message was immediately followed by a closed connection message. This verifies that every connection that is opened is also being closed. I take this as confirming that my code is not generating any leaks. I then went into the Glassfish JDBC monitor and recorded the data that was shown, and then a short while later clicked the refresh button and recorded the new data. Some of the data items had changed and some remained the same. The relevant ones are copied below. Briefly, NumConnCreated remained unchanged at 3989, and NumConnUsed remained unchanged at 388. However, NumConnAcquired changed from 12465 to 12475, a difference of 10, and NumConnReleased changed from 12235 to 12245, also a difference of 10. I take this as further evidence that there is no leak. In fact, I suspect that this is why NumPotentialConnLeak is always 0. In every given time window, the number of connections released equals the number acquired. Next, I went into the JDBC pool configuration and started experimenting with different values for the maximum pool size. Strangely, I found that that NumConnUsed value of 388 was critical. If the maximum pool size is set to be anything less than or equal to 388, I start getting those messages saying that Glassfish can't allocate any more connections. But if I change the maximum pool size simply by increasing it to 389, the system starts running again. I have left this at 389 for several hours now, and the system keeps running, and the log file shows none of those "can't allocate" messages. Also, the web crawlers are having a heyday, and this isn't causing any problems. Interestingly, I've noted that the ones currently accessing my website are actually making valid queries. Putting all this together, I'm coming to the conclusion that this is normal Glassfish behavior---there are no memory leaks, and actually no problem. Where that number 388 comes from, I have no idea, but it seems to be internal to the Glassfish system. I understand that people who work with pooling systems view this number as abnormally large, but maybe it's just that different pooling systems behave differently. Regarding some more recent email: I'm using Java JDK 1.8.0_144. Glassfish 4.1 won't work with any version of Java later than 1.8, but later versions of Glassfish will work with later versions of Java. It might be that later versions of Glassfish behave differently and possibly work with small pool sizes. For my purposes, however, I'm not motivated to make the transition at this time. Best regards to everyone and thanks for all the interest and advice. It's been a valuable learning experience for me. Dan ------------------------------------------------------------- NumConnCreated 3989 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:15:04 PM -- The number of physical connections that were created since the last reset. NumConnReleased 12235 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:15:04 PM -- Number of logical connections released to the pool. NumConnAcquired 12465 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:15:04 PM -- Number of logical connections acquired from the pool. NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 16, 2025 9:15:04 PM High Water Mark: 390 count Low Water Mark: 0 count Provides connection usage statistics. The total number of connections that are currently being used, as well as information about the maximum number of connections that were used (the high water mark). NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- -- Number of potential connection leaks --------------------------------------------------------------- NumConnCreated 3989 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:15:04 PM -- The number of physical connections that were created since the last reset. NumConnReleased 12245 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:18:03 PM -- Number of logical connections released to the pool. NumConnAcquired 12475 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:18:03 PM -- Number of logical connections acquired from the pool NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 16, 2025 9:18:03 PM High Water Mark: 390 count Low Water Mark: 0 count Provides connection usage statistics. The total number of connections that are currently being used, as well as information about the maximum number of connections that were used (the high water mark). NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- -- Number of potential connection leaks ---------------------------------------------------------------- 12475 - 12465 = 10 connections acquired 12245 - 12235 = 10 connections released From: Chuck Caldarale <n82...@gmail.com> Sent: Saturday, August 16, 2025 3:58 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: [EXTERNAL EMAIL] How to access a REST service > On 2025 Aug 16, at 14:52, Robert Turner > <rtur...@e-djuster.ca.INVALID<mailto:rtur...@e-djuster.ca.INVALID>> wrote: > > > On Sat, Aug 16, 2025, 15:44 Chuck Caldarale > <n82...@gmail.com<mailto:n82...@gmail.com>> wrote: > >> Robert - >> >> (Sorry > for top-posting, NkdkJdXPPEBannerStart Be Careful With This Message From (Chuck Caldarale <n82...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fd826f835b18e7338a04015f49a15b77653863ed0a15fa37ffc4f9894205136912099218a415a34a8ae189d273ade7bf93e5739fc7a770803286fa06b5f50c5277dd932c6c6d6a96007abf8fcc9dd54653431d0b42bb6c1c99874a0e848fca0e5be0e5182fc1206b39fc7aaa8978197723d6940e429952fd3371f324c6ef50f44aa0f1038a1a89ec337ba2c2b5fbc497ae56a80408831d910c0c7ab891b4114e2b6b4eb66e6464952b6293676c34aa1745bf2f09c40a60fc42b27d1429c85a392b85acf42a1d43be0654b8da320873d23500fb3d74c6fb8912f7e104712568f0e8777a337edcdbaf8> Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fd826f835b18e7338a04015f49a15b77653863ed0a15fa37ffc4f9894205136912099218a415a34a8ae189d273ade7bf93e5739fc7a770803286fa06b5f50c5277dd932c6c6d6a96007abf8fcc9dd54653431d0b42bb6c1c99874a0e848fca0e5be0e5182fc1206b39fc7aaa8978197723d6940e429952fd3371f324c6ef50f44aa0f1038a1a89ec337ba2c2b5fbc497ae56a80408831d910c0c7ab891b4114e2b6b4eb66e6464952b6293676c34aa1745bf2f09c40a60fc42b27d1429c85a392b85acf42a1d43be0654b8da320873d23500fb3d74c6fb8912f7e104712568f0e8777a337edcdbaf8> 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 16, at 14:52, Robert Turner > <rtur...@e-djuster.ca.INVALID<mailto:rtur...@e-djuster.ca.INVALID>> wrote: > > On Sat, Aug 16, 2025, 15:44 Chuck Caldarale > <n82...@gmail.com<mailto:n82...@gmail.com>> wrote: > >> Robert - >> >> (Sorry for top-posting, but this is just about GlassFish 4.1, not Dan’s >> problem.) >> >> GlassFish 4.1 is a bit hard to find these days, but it can be downloaded >> from here: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__javaee.github.io_glassfish_download&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=kcwcsXJW1KFHWbZPs5f2PiB8motHlu4wBFKFO8tq1mlpq9con6rdfRkHYhVBSr9Z&s=_KIYlbVezHnWB6M_6YL8idK2o098rn0x11VqikQDiFc&e= >> >> Also, 4.1 refuses to run on a modern JVM, resulting in this message: >> >> GlassFish requires Java SE version 6. Your JDK is version 0 >> >> Mine is currently 23.0.2; not sure how far back one will have to go… > > > Thanks for the heads up. That might be a bit tricky then... Maybe that > won't happen then. The README says it will run on JDK 8, but makes no mention of anything beyond that. I don’t remember what the current JVM was 11 years ago... - Chuck --------------------------------------------------------------------- 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>
