Chris, Again, see my replies marked DSG.
Dan -----Original Message----- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Monday, August 11, 2025 3:21 PM To: users@tomcat.apache.org Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service Daniel, On 8/5/25 3:05 PM, Daniel Schwartz wrote: > I just replied to Rob Sargent regarding this. Did you see that reply? > > Maybe I’m not using Glassfish correctly, but if I set the maximum> pool size > to 1, the system almost immediately outputs an error > message saying that it is unable to allocate any more connections and > crashes. I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse? DGS: By "crashes" I mean that the program terminates, usually just after printing out a stack trace. > That’s why I have set a large maximum pool size. I think you are fixing the symptom and not the problem. Even with a pool size of 1, your server should not crash. The worst thing that should happen is a request fails because a connection could not be immediately obtained from the pool. Most pools will wait some amount of time for a connection, and then time-out and the request fails. I suppose it's possible to configure a pool to require a connection to be immediately available, but that would be an unusual configuration to use IMHO. DGS: According to the people at Onmifish, if you set the maximum pool size to 1, you can have only one connection at a time. So, if there is a request for a second connection, you get that message saying that no more connections can be created, and the system crashes (stops running). The behavior that you describe makes sense (sounds like how things should work), but that evidently isn't true about Glassfish. -chris > From: Niranjan Rao <n...@paymentus.com> > Sent: Tuesday, August 5, 2025 12:54 PM > To: users@tomcat.apache.org > Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service > > On 8/5/25 09:43, Daniel Schwartz wrote: > 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 NkdkJdXPPEBannerStart Be Careful With > This Message From (Niranjan Rao > <n...@paymentus.com>)<https://godaddy1.cloud-protect.net/email-details > /?k=k1&payload=53616c7465645f5f01479cd1d42494181d4c16588b94df4c820e427 > 2265487dd9f78a6c5058acdafc93d62897abd159718ec313c22d09277dbf2fbb536c02 > 6e3f6aee770447b1d4f78dfc54afce74a56553ab348aa1f4cf565bf83964f1f0912334 > 8c4e595d8d9df00b653e7157eedbd6450c9ea7be6c8687659e563a0caaeb8ee75dff4f > a7e4a88d05034bb22037dd4bbe58bf99e736fbdae6b66c1d082b0b30de80c55b5719ab > c475fbe778560908e4d4a57fae4f1567f335f620ae681895613f5e4f54efacefe16c1e > cf319bdaec9f510253a8e47129cd215e8d8cd3c3bf89c2456aab6324c75736d9af5f15 > 50a42> Learn > More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53 > 616c7465645f5f01479cd1d42494181d4c16588b94df4c820e4272265487dd9f78a6c5 > 058acdafc93d62897abd159718ec313c22d09277dbf2fbb536c026e3f6aee770447b1d > 4f78dfc54afce74a56553ab348aa1f4cf565bf83964f1f09123348c4e595d8d9df00b6 > 53e7157eedbd6450c9ea7be6c8687659e563a0caaeb8ee75dff4fa7e4a88d05034bb22 > 037dd4bbe58bf99e736fbdae6b66c1d082b0b30de80c55b5719abc475fbe778560908e > 4d4a57fae4f1567f335f620ae681895613f5e4f54efacefe16c1ecf319bdaec9f51025 > 3a8e47129cd215e8d8cd3c3bf89c2456aab6324c75736d9af5f1550a42> > 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 8/5/25 09:43, Daniel Schwartz wrote: > >> 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 > >> ZjQcmQRYFpfptBannerStart > >> This Message Is From an Untrusted Sender > >> You have not previously corresponded with this sender. > >> ZjQcmQRYFpfptBannerEnd > >> 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 > >> > > > > The default is a reasonable number depending upon traffic. Is your > site > > fairly busy? We manage a fairly busy site with lot database activity > and > > even then we don't have to go 1000 connections which essentially might > > boil down to 1000 concurrent requests. Are you really getting that > many > > requests simultaneously? As others have indicated there is a good > chance > > you have connection and/or other resource leaks in your code. There > are > > some debugging hints posted like setting max connections to 1 in your > > dev environment and see if it works cleanly. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org