Robert, See my replies.
Dan -----Original Message----- From: Robert Turner <rtur...@e-djuster.ca.INVALID> Sent: Tuesday, August 12, 2025 5:06 PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service Dan, On Tue, Aug 12, 2025 at 4:43 PM Daniel Schwartz <d...@danielgschwartz.com> wrote: > Hello again, Robert, > > The Glassfish Pool setup page shows the following defaults: > > Idle Timeout: 300 Seconds > Maximum time that connection can remain idle in the pool > > Max Wait Time: 60000 Milliseconds > Amount of time caller waits before connection timeout is sent > > Not knowing exactly what these mean, I have left them as is. If you > think they should be changed, what would you recommend? > They mean exactly what the descriptions say they mean. The defaults seem reasonable. 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. 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. > > In any case, the pool monitoring system shows: > > AverageConnWaitTime 13 millisecond Aug 8, 2025 3:18:57 PM Aug 12, > 2025 > 12:52:50 AM -- Average wait-time-duration per successful connection > request > > which doesn't seem to be a lot. Connections are happening quickly, as > long as some are available. That seems reasonable as well. Given these, what seems very odd is how many connections you still need, and that you actually max out with a reasonable pool limit (of under 100). Unless you have a really large number of simultaneous connections, or your DB requests are taking a long time, there is no reason your pool size should need to be very big. 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? 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. > > > 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 >
