Dan,
On Tue, Aug 12, 2025 at 10:38 PM Daniel Schwartz <d...@danielgschwartz.com> 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: 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: 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: 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). > > > > > > > Dan > > > > -----Original Message----- > > From: Robert Turner <rtur...@e-djuster.ca.INVALID> > > Sent: Tuesday, August 12, 2025 1:57 PM > > To: Tomcat Users List <users@tomcat.apache.org> > > Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service > > > > inline... > > > > On Tue, Aug 12, 2025 at 1:46 PM Daniel Schwartz > > <d...@danielgschwartz.com> > > 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: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > >
