From: Chuck Caldarale <n82...@gmail.com> Sent: Thursday, August 7, 2025 11:52 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: How to access a REST service
> On 2025 Aug 7, at 21:43, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > I have > just posted everything again, this time with a few modifications. You say, > "Last time you posted it, it was prone to leaking connection." NkdkJdXPPEBannerStart Be Careful With This Message From (Chuck Caldarale <n82...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8ac8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a36d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f> Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8ac8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a36d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f> 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 7, at 21:43, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > I have just posted everything again, this time with a few modifications. You > say, "Last time you posted it, it was prone to leaking connection." Could > you say more exactly where you see saw the leak? You only catch errors of the type SQLException, which means anything else will lose the connection. This is the reason you should always use try - catch - finally (or the newer with-resources syntax) around database manipulations, as recommended in Chris’ blog post. - Chuck > Thanks, > > Dan Schwartz > > -----Original Message----- > From: Robert Turner > <rtur...@e-djuster.ca.INVALID<mailto:rtur...@e-djuster.ca.INVALID>> > Sent: Thursday, August 7, 2025 5:07 PM > To: Tomcat Users List > <users@tomcat.apache.org<mailto:users@tomcat.apache.org>> > Subject: Re: How to access a REST service > > Dan, > > On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> > wrote: > >> Hello Chris, >> >> Thank you for your reply, but I'm still unsure. You seem to be >> implying that I have a memory leak, i.e., many connection objects >> being created that are not being closed. However, I really don't >> think this is happening. My code closes each connection immediately after >> using it. > > > Maybe post your code again. Last time you posted it, it was prone to leaking > connections. If it hasn't changed, that is likely your problem. > > >> >> My understanding is that the only way the maximum pool size of X, >> whatever that is, would be a limitation is if there was an attempt to >> create X+1 simultaneous connections. When you do this in Glassfish, >> it outputs an error message saying that no more connections can be >> created and then crashes. You have to go back in and manually restart it. >> >> I believe that the essential problem, as explained in a previous email >> to Rob Sargent, is that I'm getting several hundred database requests >> per day from web crawlers. I just spent some time reading through my >> ngnix access.log and found that the vast majority of these are from >> GoogleBot. >> My guess it that, due to a time lag between opening and closing >> connections, many connections will be opened simultaneously. This is >> why a small pool size won't work. >> >> Also, I'm advised to not block the web crawlers because this assists >> with SEO. My understanding is that you just have to live with this. >> >> I don't think there is an issue with my code. The only answer I can >> come up with is to have a large maximum pool size, larger that the >> expected number of simultaneous accesses. >> > There is almost definitely a problem with your code (unfortunately), or your > database requests are very slow and triggered by any connection. > > We run servers that handle much more traffic than you are describing and make > thousands of DB requests per minute, and we rarely go over 10 DB connections > being used at a time. > > There is almost for sure something leaking in your code. This is very > unlikely to be a problem with the pooling ("select isn't broken"). You are > looking for unlikely causes to the problem. > > >> >> I originally wrote to this email list because I was thinking of >> shifting from Glassfish to Tomcat, and was trying to learn how to do >> this. I think I do know how to do this now, and might try doing this. >> My understanding is that the connection pooling that works with Tomcat >> doesn't have that same limitation as Glassfish, and one can have >> connections that exist outside the pool. This would resolve the issue >> I'm currently having with Glassfish. >> >> Best regards, >> >> Dan Schwartz >> ...snip.. > > --------------------------------------------------------------------- > 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> > --------------------------------------------------------------------- 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>
