Robert, See my replies.
Dan -----Original Message----- From: Robert Turner <[email protected]> Sent: Tuesday, August 12, 2025 11:09 PM To: Tomcat Users List <[email protected]> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service Dan, On Tue, Aug 12, 2025 at 10:38 PM Daniel Schwartz <[email protected]> wrote: > > DGS: For "Idle Timeout", does this mean that after 300 seconds, if the > connection hasn't been active, then it is made available for other > connection requests. This would be my interpretation, but I'm not sure. > This normally means that if the connection is unused and sits idle for 300 seconds, then it is disconnected and reclaimed. This releases unused resources and shrinks the number of active connections in the pool. DGS: Thanks for the clarification. > > DGS: For "Max Wait Time", what is a "caller" and what is it waiting for? > These statements are a bit out of context for me. > The caller is the Java caller making the request to get a connection from the pool. DGS: Thanks here too. > DGS: I'm mystified too. However, if a typical BD connection takes > only 13 ms, and an "Idle Timeout" of 300 seconds means that a > connection object can sit there being essentially unused for that > long, then it could be that there are a lot of connection objects > accumulating because the ones that have been used still haven't timed > out. If so, then it might make sense to reduce to this timeout time. Does > this make sense? > For clarity, the 13 ms is the time it takes the pool to return to the caller (Java code) a connection when requested (as opposed to how long the connection is used for). Your other comments are accurate -- you could have many idle connections, however, 300 seconds is fairly reasonable for an idle timeout. What you want to be looking for is why you are peeking so high (maybe a benign connection that does nothing is triggering DB connections -- if so, this could lead to a DoS of your server with minimal effort). Something is either holding on to connections for a long period, or you are getting lots of connections at once. You should be able to tell easily which one it is because you will have access logs, and you can annotate your code with diagnostics as needed. Also, you can simply test on your development computer and see what's going on...without exposing your testing to the wide world of the Internet and the associated risks. DGS: Yes, I have access logs. I will look more closely and see if anything stands out. Within nginx you can block requests from specific IP addresses, but I haven't resorted to this yet. DGS: Am not sure what you mean by "you can annotate your code with diagnostics as needed" or "you can simply test on your development computer and see what's going on". What sort of diagnostics, and what sort of test? > > DGS: As for now, if I keep the maximum pool size at 1000, the system keeps > running. However, right now the vast majority of connection requests are > by web crawlers. I don't know what might happen if I were to get some > real users. > Web crawlers really shouldn't be triggering your DB - esp. for a "one page app" (it looks like you are using React for the front end). DSG: Yes, the front end is React/Next. > > > > > > > Dan > > > > -----Original Message----- > > From: Robert Turner <[email protected]> > > Sent: Tuesday, August 12, 2025 1:57 PM > > To: Tomcat Users List <[email protected]> > > Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service > > > > inline... > > > > On Tue, Aug 12, 2025 at 1:46 PM Daniel Schwartz > > <[email protected]> > > wrote: > > > > > > > > DGS: I was going by what the person at Omnifish had told me. I > > > just checked, and you can't set the maximum pool size to 1. The > > > minimum is > 8. > > > So I did this and within seconds the system stopped working and I > > > got the following in the log file: > > > > > > "Caused by: javax.resource.spi.ResourceAllocationException: > > > Error in allocating a connection. Cause: In-use connections equal > > > max-pool-size and expired max-wait-time. Cannot allocate more > > connections." > > > > > > Also, > > > > > > "Caused by: > com.sun.appserv.connectors.internal.api.PoolingException: > > > In-use connections equal max-pool-size and expired max-wait-time. > > > Cannot allocate more connections." > > > > > > Then I went back and reset the maximum pool size to 1000, and > > > it started working again. > > > > > > Based on the error message and some quick Google searches, there > > > is a > > setting to control the maximum wait time (max-wait-time). The > > default is supposed to be 60 seconds, so that's a red flag right > > there -- do you expect to be holding connections for so long that > > waiting threads / requests would have to wait for more than 60 seconds? > > > > Using a connection for around 60 seconds would be a really long DB > > query, or a very slow database server / instance. You may want to > > validate the Glassfish configuration option, and understand how long > > your requests are holding connections for, etc. Something is still > > very odd with your application's behavior. > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > >
