Daniel,
On 8/7/25 4:59 PM, Daniel Schwartz wrote:
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.
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.
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.
My guess is that Tomcat and Glassfish differ only in their default
configurations, but that the feature-sets are fairly equivalent.
I would get some instrumentation going before you start changing
anything. It would be good to be able to see the state of the connection
pool. Using something like JMX is definitely possible with Tomcat; I'm
unsure of how to check Glassfish.
-chris
---Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Thursday, August 7, 2025 2:58 PM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Daniel,
On 8/5/25 12:43 PM, Daniel Schwartz wrote:
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.
This is correct.
Once a database session terminates, then that connection object becomes
available for future use.
Correct, as long as we agree on the definition of "database session". In the case of both JDBC and
connection pools based upon JDBC connections, the definition of the "end of a session" is
"calling Connection.close".
If you never call Connection.close, then every connection leaks, and most pools
have features to help deal with those circumstances so that badly-written
applications don't run out of resources.
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?
More or less, though the pool may grown and shrink slightly around that value.
The pool Tomcat uses has features for logging and closing "abandoned
connections" which are those which are checked-out of the pool but not
properly-returned. I highly recommend enabling those features to investigate what is
happening in your environment.
Otherwise, your 1000 connections will eventually be exhausted... it will just
take much longer than the default 32 where you were observing that behavior.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
