Well, I guess that this is a top post. But this message is getting longer with all the replies.
I don’t think it is a memory leak. I’m fairly sure that I’m closing every connection immediately after using it. It seems that most of my database queries are coming from web crawlers, and there are a few hundred accesses every day. I was getting error messages from Glassfish saying that it couldn’t allocate any more connection objects and then crashing. At that time the maximum pool size was the default, which is 32. So I believe it was just being overloaded by the web crawlers. Now that I have increased to 1000, the system has stopped crashing. But I have to admit that I really don’t understand how these connection pooling systems work. My understanding is that only as many connection objects are created and placed in the pool as are needed, so even if you set the upper limit high it doesn’t necessarily mean that you will have that many. Once a database session terminates, then that connection object becomes available for future use. So at any given time, the number of connection objects in the pool would be the maximum number of simultaneous connections that have been made so far, and not necessarily the total maximum that are allowed (in my case 1000). Is this correct? Dan Schwartz From: Rob Sargent <rsarg...@xmission.com> Sent: Tuesday, August 5, 2025 12:57 AM 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 4, 2025, at 8:11 PM, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > Hello > Rob, > > I don’t know what a “top post” is or why it should warrant an > apology, but I appreciate your taking the time to reply. This NkdkJdXPPEBannerStart Be Careful With This Message From (Rob Sargent <rsarg...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f65c91d16fc04fd4044b524db9431d4455fd10bc4cf0136584b8f801e0092b93e98c8ef864d9d0ad20e1fed468b5cf45c502c1dbea2144040376aa1813426065709ce03dc3895b11bf1062104116d3d6bbbaa7de6465f4815ede75f97828cdee881437677a9b92b8ceff48ce61ae9baee912b827b449fdd42d66386c3a29495d8c623817048730f3f4b015fce1a31d591e12eae9ac9d3e6dfb15d7b634ba80b662ce7997ce5a9468031b556446dbdb7b43c5ddea5c8257f737bec3eb978f51def90a62f5230f09ba43c9ecf6cc2bff2b7f8fc6ab49cbd18ccc8db290b0b7fad3dbbed36fb39b68ea6> Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f65c91d16fc04fd4044b524db9431d4455fd10bc4cf0136584b8f801e0092b93e98c8ef864d9d0ad20e1fed468b5cf45c502c1dbea2144040376aa1813426065709ce03dc3895b11bf1062104116d3d6bbbaa7de6465f4815ede75f97828cdee881437677a9b92b8ceff48ce61ae9baee912b827b449fdd42d66386c3a29495d8c623817048730f3f4b015fce1a31d591e12eae9ac9d3e6dfb15d7b634ba80b662ce7997ce5a9468031b556446dbdb7b43c5ddea5c8257f737bec3eb978f51def90a62f5230f09ba43c9ecf6cc2bff2b7f8fc6ab49cbd18ccc8db290b0b7fad3dbbed36fb39b68ea6> 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 4, 2025, at 8:11 PM, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > Hello Rob, > > I don’t know what a “top post” is or why it should warrant an apology, but I > appreciate your taking the time to reply. This looks interesting. > > I’m currently using Glassfish, which has built in connection pooling. I was > having trouble with its crashing frequently with a message saying that it was > unable to allocate any more connections. Then I learned that the default > pool size was only 32 and that this is the maximum allowed number of > concurrent connections, so I increased this to 1000, and now it runs fine. > I am new at this, though, and any new info is helpful. Thanks. > > Dan Schwartz 1000 is a rather large number of open connections. For one thing they are quite memory intensive. I suspect you are (still) leaking connections - not re-using those with which you have completed a database task. You will likely hit the same error if your system stays up for any length of time. I recommend going back to Chris’s article to get this leak under control. PS This is a bottom post, wherein the new text follows the original. >> --------------------------------------------------------------------- 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>
