You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Daniel Schwartz <da...@danielgschwartz.com> on 2025/08/01 00:28:12 UTC
RE: How to access a REST service
Hello Mark,
Thanks for taking the time to reply. Please see my notes below, marked "DGS".
-----Original Message-----
From: Mark Thomas <ma...@apache.org>
Sent: Thursday, July 31, 2025 4:32 AM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
On 31/07/2025 05:10, Daniel Schwartz wrote:
> I have a REST webservice written in Java that runs on the Glassfish server, but I started having problems with the JDBC pooling system. It kept crashing, saying that it was unable to allocate any more connection objects. This made no sense to me, as I had set the maximum pool size to 1000, and I surely was not getting that many simultaneous connections. Also, I consulted with some Glassfish experts at a company called OmniFish, and this didn't help.
>
> So I decided to shift to Tomcat, which doesn't require connection pooling.
Umm...
The requirement for connection pooling comes from your application, not the container. Like Glassfish, Tomcat supports connection pooling if you want to use it.
DGS: I initially tried to rewrite my Glassfish app to by-pass the connection pooling to access MySQL directly and got error messages complaining that connection pooling had not been set up. It seems that you have to use connection pooling. At least this is what I concluded.
The chances are you do want to use connection pooling as it will improve your application's performance.
DGS: Yes, I would like to, but I was having problems with this that I couldn't figure out.
From your description of your application's behaviour on Glassfish, it sounds like the application has a connection leak. You might find it is a better use of your time working on finding and fixing that leak rather than porting the application to Tomcat (where the leak will still be present).
DGS: Someone else suggested the leak issue, but I believe that I am closing every database connection immediately after using it, so there shouldn't be a link. I have copied some relevant code fragments at the end of this message. Maybe you could look to see if there is an issue with this.
DGS: It would be simpler for me to just stay with Glassfish, if I could only stop it from crashing.
DGS: In any case, I have found out that some hacker has found a way to submit bogus queries through my website, but they are doing this less than 100 times per day, and certainly not 1000 at the same time. However, I did recently notice that the maximum pool size had somehow been set back to the default of 32, so maybe this is why the crashing started back up. Since I set it back to 1000, there have been no subsequent crashes for 2-3 days now.
> I have implemented my system in both IntelliJ IDEA and VSCode, with
> suitable changes to make a direct connection to MySQL. Both of these
> produce a file called HolidaysRESTJSON-1.0-SNAPSHOT.war. This deploys
> in Tomcat (I'm using tomcat-9.0.107), but when I try to access it with
> my test URL,
>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_H
> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_countr
> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzo
> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=nSgNUwSqfNb_FwrQmpLJdMUvWIQm1oNqS
> Ocqbl8CX4EzoTIFqySerc91W-TTV0ga&s=5mkyVUuj6wpySF-BT4slF7BjEi38D8jisUdS
> Vmu5Exo&e=
>
> I get a 404 error. It is supposed to return a list of countries. This did work with my Glassfish version, however. So it should work with Tomcat.
>
> The question is: Why not?
Insufficient information to provide a definitive answer. We can guess, but it is little more than that.
> Is there something wrong with my URL?
Probably.
> How would I know?
You wrote the application so you defined the URL mapping for your servlet.
At a guess, you need to remove "/webresources" from the URL.
DGS: I tried this, and it didn't help.
Things you could provide that might help us help you:
- clean logs of Tomcat starting and you making a single request
- the web.xml for you application
- any information related to defining the URL that is meant to return the list of countries.
DGS: I plan to look at some sample Tomcat REST apps and see if I can figure out why mine isn't working. It might only require some minor code changes. If this doesn't work, I will send you the logs, web.xml, etc. In the meantime, I would appreciate it if you could tell me if the following code fragments look okay.
Mark
--------------------------------------------------------------------------------------------------------------
Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
--------------------------------------------------------------------------
public class HolidaysRESTJSONResource {
DataSource dataSource;
public HolidaysRESTJSONResource() {
dataSource = DataSourceSingleton.getInstance().dataSource;
}
@GET
@Path("/countries")
@Produces(MediaType.APPLICATION_JSON)
public String getJsonCountries() {
...
Connection connection;
try {
connection = dataSource.getConnection();
TempDataStorage.countryList = GetCountryList.doIt(connection);
connection.close();
...
}
--------------------------------------------------------------------------
The constructor for HolidaysRESTJSONResource creates a DataSource by creating an instance of the following DataSourceSingleton class and retrieving the value of the DataSource instance variable. I borrowed this code from somewhere. It seems to work. The MySql database is called "holidays".
--------------------------------------------------------------------------
public class DataSourceSingleton {
private static DataSourceSingleton instance = null;
public DataSource dataSource = null;
private DataSourceSingleton() {
try {
InitialContext ctx = new InitialContext();
dataSource = (DataSource) ctx.lookup("jdbc/holidays");
} catch (NamingException e) {
System.out.println(e);
}
}
public static DataSourceSingleton getInstance() {
if (instance == null) {
instance = new DataSourceSingleton();
}
return instance;
}
}
--------------------------------------------------------------------------
Back in HolidaysRESTJSONResource, in the method getJsonCountries(), the DataSource object, called "dataSource", is used to create the connection object, and this is used in a method call GetCountryList.doIt() to retrieve a list of countries from the database. Then this connection object is closed. I think that this is all that is needed to prevent memory leaks. Is this correct? I do this for every such method call that accesses the database.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Harri,
On 8/5/25 2:40 AM, Harri Pesonen wrote:
> Chris's article is fine except that it does not use the try-with-
> resources feature of Java language:
>
> try (Connection conn = getConnection()) {
> try (Statement stmt = conn.createStatement()) {
> try (ResultSet rs = stmt.executeQuery(sql)) {
> ...
> }
> }
> }
Please check the publication date on that post: it's a few years before
try-with-resources was generally available.
Also, you can use multiple try-with-resources clauses, like this:
try (Connection conn = getConnection();
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(sql)) {
// Stuff
}
I find try-with-resources less useful with JDBC-related code, as it's
very rarely as simple as the example you have above.
> That will make sure that every SQL resource is freed correctly.
>
> Other important thing is that you should free the connection as fast
> as possible. Don't make long lasting operations while you have the
> connection open. Instead you could read the SQL result to memory,
> close the connection, and then do additional work.
+1
> Third thing is what Chris is also saying, avoid taking more than one
> connection at a time. It will end up in deadlock when you run out of
> connections. And it also breaks the previous rule.
This is precisely why I recommend setting maxActive="1" in development
environments.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Harri Pesonen <ha...@sinch.com.INVALID>.
Hello, my cents on this issue.
Chris's article is fine except that it does not use the try-with-resources feature of Java language:
try (Connection conn = getConnection()) {
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery(sql)) {
...
}
}
}
That will make sure that every SQL resource is freed correctly.
Other important thing is that you should free the connection as fast as possible. Don't make long lasting operations while you have the connection open. Instead you could read the SQL result to memory, close the connection, and then do additional work.
Third thing is what Chris is also saying, avoid taking more than one connection at a time. It will end up in deadlock when you run our of connections. And it also breaks the previous rule.
-Harri
-----Original Message-----
From: Rob Sargent <rs...@xmission.com>
Sent: tiistai 5. elokuuta 2025 7.57
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
> On Aug 4, 2025, at 8:11 PM, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Hello Rob,
>
> I don’t know what a “top post” is or why it should warrant an apology, but I appreciate your taking the time to reply. This looks interesting.
>
> I’m currently using Glassfish, which has built in connection pooling. I was having trouble with its crashing frequently with a message saying that it was unable to allocate any more connections. Then I learned that the default pool size was only 32 and that this is the maximum allowed number of concurrent connections, so I increased this to 1000, and now it runs fine. I am new at this, though, and any new info is helpful. Thanks.
>
> Dan Schwartz
1000 is a rather large number of open connections. For one thing they are quite memory intensive. I suspect you are (still) leaking connections - not re-using those with which you have completed a database task. You will likely hit the same error if your system stays up for any length of time.
I recommend going back to Chris’s article to get this leak under control.
PS
This is a bottom post, wherein the new text follows the original.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
I just saw this.
From: Rob Sargent <rs...@xmission.com>
Sent: Monday, August 11, 2025 10:17 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
> On Aug 11, 2025, at 7:54 PM, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > Rob, > > The system has never crashed, so I've seen a stack trace. > > Dan > (Assuming you meant “ never seen” ) Back when you
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f57733086b86841fd87dcf2a76d85eb43a8f2c1dbbe5f2ea22dac889797dc512d2aaab23b460b50de1510e7518d767b83abd19dca0c24f38004396fe59a4bfa11a5db1b2fd791a67fdacaa485060e27cfc981019526e008a3e184ac377ea4a6c0ca2c8bfb13aba4c7bfbbad140c3098b94289032fbefbd9880ec1cf13e68812497de13b7e10520cbe0b6b2e4f74831ebd82baa6e432572a3ae7a09a91ca3e2414735e4c35085b8d62ee10caf6990dc8ab54525f39f9cf95c83da4246b80148c6a8ff8ed1cdf0fd56a47f859186627ba69cd2c1fd98cd9defaa68ecb7b0e8d7a51488342c1869630c9>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f57733086b86841fd87dcf2a76d85eb43a8f2c1dbbe5f2ea22dac889797dc512d2aaab23b460b50de1510e7518d767b83abd19dca0c24f38004396fe59a4bfa11a5db1b2fd791a67fdacaa485060e27cfc981019526e008a3e184ac377ea4a6c0ca2c8bfb13aba4c7bfbbad140c3098b94289032fbefbd9880ec1cf13e68812497de13b7e10520cbe0b6b2e4f74831ebd82baa6e432572a3ae7a09a91ca3e2414735e4c35085b8d62ee10caf6990dc8ab54525f39f9cf95c83da4246b80148c6a8ff8ed1cdf0fd56a47f859186627ba69cd2c1fd98cd9defaa68ecb7b0e8d7a51488342c1869630c9>
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 Aug 11, 2025, at 7:54 PM, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Rob,
>
> The system has never crashed, so I've seen a stack trace.
>
> Dan
>
(Assuming you meant “ never seen” )
DSG: Right. My mistake.
Back when you were running with 32 db connections didn’t your system stop working when it ran out of connections?
And if so was there any stack trace then, or other report?
DGS: There was no stack trace, because the Java was running perfectly. The system stopped because Glassfish stopped working when it couldn’t create any more connections.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
> On Aug 11, 2025, at 7:54 PM, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Rob,
>
> The system has never crashed, so I've seen a stack trace.
>
> Dan
>
(Assuming you meant “ never seen” )
Back when you were running with 32 db connections didn’t your system stop working when it ran out of connections?
And if so was there any stack trace then, or other report?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Rob,
The system has never crashed, so I've seen a stack trace.
Dan
From: Rob Sargent <rs...@xmission.com>
Sent: Monday, August 11, 2025 9:51 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse? > > DGS: By "crashes" I mean that the program
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f8d7e46644b9201586fc34c3d024361d970440002217b5d2a8ecf6cfc64ae46f9cd18255d84087e0a3225bda04eb3bea424e456281c8579c55ea4e36196947b0d4da242a4800ed13f6211fdc5928851eba101e021520caee60ce9a473afbe61b073d3a461b534d852c23142af84e0c416e63021937d6b7d285e23ab179b79326bb9e7fa38b275e7eba808e2ec881c4f539c3af30579683dcf654a626264b758dd57b2219a169010f57fc2047a824ad4ef8e3c7f7c090e8b47edf4d7f1ac05d0bc7c5644da0d67459f0fdcc14fbc1eae888244851f5ca900a6ca559b67182692e88ebf18fae2cfd68c>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f8d7e46644b9201586fc34c3d024361d970440002217b5d2a8ecf6cfc64ae46f9cd18255d84087e0a3225bda04eb3bea424e456281c8579c55ea4e36196947b0d4da242a4800ed13f6211fdc5928851eba101e021520caee60ce9a473afbe61b073d3a461b534d852c23142af84e0c416e63021937d6b7d285e23ab179b79326bb9e7fa38b275e7eba808e2ec881c4f539c3af30579683dcf654a626264b758dd57b2219a169010f57fc2047a824ad4ef8e3c7f7c090e8b47edf4d7f1ac05d0bc7c5644da0d67459f0fdcc14fbc1eae888244851f5ca900a6ca559b67182692e88ebf18fae2cfd68c>
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
I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse?
>
> DGS: By "crashes" I mean that the program terminates, usually just after printing out a stack trace.
>
I am sure I am not the only one who would like to see that stack trace
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Harri Pesonen <ha...@sinch.com.INVALID>.
Application should not crash if you fail to get database connection from pool.
Instead it should wait until the configured timeout is reached, and then it will throw exception, which is SQLException if I recall correctly.
At that point you code will catch the exception and log it, but it will not crash.
https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html#Common_Attributes
* maxWait
* (int) The maximum number of milliseconds that the pool will wait (when there are no available connections) for a connection to be returned before throwing an exception. Default value is 30000 (30 seconds)
But I can't find similar setting from Glassfish (Payara):
https://docs.payara.fish/community/docs/5.193/documentation/payara-server/advanced-jdbc/advanced-connection-pool-properties.html
So I assume that Glassfish will throw exception immediately when it runs out of connections.
-Harri
-----Original Message-----
From: Rob Sargent <rs...@xmission.com>
Sent: tiistai 12. elokuuta 2025 4.51
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse?
>
> DGS: By "crashes" I mean that the program terminates, usually just after printing out a stack trace.
>
I am sure I am not the only one who would like to see that stack trace
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse?
>
> DGS: By "crashes" I mean that the program terminates, usually just after printing out a stack trace.
>
I am sure I am not the only one who would like to see that stack trace
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 14, at 16:42, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Please see the reply is just sent to Chris. I think that this answers your questions.
>
> I don't know why people thought I was using servlets.
Likely because both Tomcat and GlassFish are servlet containers, and you were asking questions on the Tomcat mailing list.
In actuality, you are using servlets, but under the covers. The GlassFish implementation of RESTful services wraps your application code in servlets.
> It's a REST web service. I thought that this was clear.
REST web services are often implemented as servlets, so REST does not preclude your use of servlets.
> My code currently catches SQL exceptions, and prints out an error message when/if it gets one; and if some other type of exception is thrown, the JVM will output a stack trace and terminate.
This is a misconception on your part. GlassFish is a complex beast, with many threads capable of handling multiple concurrent requests, DB connections, and all the associated management thereof. An exception in application code (your RESTful web service) would only cause that request to be aborted - it would not shut down the JVM (unless something is seriously broken or badly misconfigured in GlassFish).
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
On 8/15/25 21:03, Daniel Schwartz wrote:
> Today I decided to run a test where I cleared out Glassfish so I could start from scratch. I executed one REST request using the URL I posted recently, which returns a list of countries. Then I looked at the Glassfish JDBC pool monitor. A PDF of this is attached. You will see that it says the following:
>
> 1. NumConnAcquired, 1 count, Number of logical connection
>
> 2. NumConnReleased, 1 count, Number of logical connections released to the pool.
>
> 3. NumConnCreated, 8 count, The number of physical connections that were created since the last reset.
>
> 4. NumConnFree, 8count, The total number of free connections in the pool as of the last sampling.
>
> I believe that this is why the minimum pool size is 8; each logical connection requires 8 physical connections.
I believe you are misinterpreting this report. The 8 connections are
the pool. Your test used one of the 8, and returned it to the pool. No
connection leek. Yet.
> This leads me to believe that this is why the number of connections in my connection pool is much larger than what one would expect. Assuming that Tomcat only requires one connection object per query, this implies that Glassfish requires 8 times that amount. So, while a normal pool size for Tomcat might be 20 connections, in Glassfish this same activity would require 160 connections.
>
> In any case, I'm now 100% sure that my program doesn't, and never did, have a memory leak. I have modified my code according to Chris's recommendations, as this surely is good advice, but it hasn't changed the performance, since no exceptions were ever being thrown.
>
> It appears to me that Glassfish is performing normally according to its internal design, and there really is no problem as long as I keep the maximum pool size large enough.
>
> What do you think?
>
> Dan
I think that if you repeat that experiment with pool size of 1000
thousand, you will see line 3 of the report will have "NumConnCreated,
1000 count". And you haven't started leaking connections yet.
I think if you take Chris's advice and really hammer all your services
with curl or similar you will get NumPotentialConnLeak greater than 0.
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 15, at 23:00, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Chuck,
>
> Okay, here is the text of the attachment.
Thanks.
<snip/>
> Regarding your statement "What is more likely is that the GlassFish connection pool simply initializes the configured minimum number of connections on the first attempt to acquire a connection.", I have no idea hat this means.
To quote from the GlassFish doc for the asadmin utility:
--steadypoolsize
The minimum and initial number of connections maintained in the pool. The default value is 8.
--maxpoolsize
The maximum number of connections that can be created. The default value is 32.
When the pool is first accessed by your web service code to acquire a connection, the pool creates steady-pool-size instances, not just the one your code is asking for. The pool will maintain at least steady-pool-size connections (idle plus active) in the pool. Connections can be removed from the pool if they fail, but the pool will be replenished as needed to keep steady-pool-size around.
Also, there’s no evidence in the doc that 8 is the minimum value that can be set. If you’re lowering the maximum (max-pool-size), it must be set at least as large as steady-pool-size; setting both to one should find any connection leaks pretty quickly. (Looks like Robert Turner demonstrated that while I was writing this.)
- Chuck
> Dan
>
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Friday, August 15, 2025 11:39 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
>> On 2025 Aug 15, at 22:03, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > I think I found the answer. > > A few days ago, someone suggested that I try setting the Glassfish maximum pool size to 1 and see what happens.
> NkdkJdXPPEBannerStart
> Be Careful With This Message
> From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd>
> Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd>
> 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 15, at 22:03, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
>>
>
>> I think I found the answer.
>
>>
>
>> A few days ago, someone suggested that I try setting the Glassfish maximum pool size to 1 and see what happens. I reported back that in Glassfish the minimum pool size is 8, to which someone responded that this seems strange. I really didn't know. But now I do.
>
>>
>
>> Today I decided to run a test where I cleared out Glassfish so I could start from scratch. I executed one REST request using the URL I posted recently, which returns a list of countries. Then I looked at the Glassfish JDBC pool monitor. A PDF of this is attached.
>
>
>
>
>
> The list strips nearly all attachments, for safely reasons. You need to post the text.
>
>
>
>
>
>> You will see that it says the following:
>
>>
>
>> 1. NumConnAcquired, 1 count, Number of logical connection
>
>>
>
>> 2. NumConnReleased, 1 count, Number of logical connections released to the pool.
>
>>
>
>> 3. NumConnCreated, 8 count, The number of physical connections that were created since the last reset.
>
>>
>
>> 4. NumConnFree, 8count, The total number of free connections in the pool as of the last sampling.
>
>>
>
>> I believe that this is why the minimum pool size is 8; each logical connection requires 8 physical connections.
>
>>
>
>> This leads me to believe that this is why the number of connections in my connection pool is much larger than what one would expect. Assuming that Tomcat only requires one connection object per query, this implies that Glassfish requires 8 times that amount.
>
>
>
>
>
> I think that is extremely unlikely. What is more likely is that the GlassFish connection pool simply initializes the configured minimum number of connections on the first attempt to acquire a connection.
>
>
>
> You can test this by making concurrent requests and seeing what happens to the pool counters. Try inserting a delay in your code between opening a connection and closing it; something like Thread.currentThread().sleep(10000) would likely suffice. Then initiate independent requests from several browser tabs in parallel; the 10-second delay should allow time for each request to grab its own connection from the pool while the other requests are still active.
>
>
>
>
>
>> So, while a normal pool size for Tomcat might be 20 connections, in Glassfish this same activity would require 160 connections.
>
>>
>
>> In any case, I'm now 100% sure that my program doesn't, and never did, have a memory leak. I have modified my code according to Chris's recommendations, as this surely is good advice, but it hasn't changed the performance, since no exceptions were ever being thrown.
>
>
>
>
>
> Did you apply the try-catch-finally pattern to all DB-related objects, such as statements, prepared statements, and result sets?
>
>
>
> - Chuck
>
>
>
>
>
>> It appears to me that Glassfish is performing normally according to its internal design, and there really is no problem as long as I keep the maximum pool size large enough.
>
>>
>
>> What do you think?
>
>>
>
>> Dan
>
>>
>
>> -----Original Message-----
>
>> From: Christopher Schultz <ch...@christopherschultz.net>>
>
>> Sent: Friday, August 15, 2025 1:07 PM
>
>> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
>>
>
>> Dan,
>
>>
>
>> The only reason we are all looking for resource leaks (technically not memory leaks, but leaks nonetheless) is because it's the best explanation for why your connection pool seems to be running dry.
>
>>
>
>> I don't think that switching to Tomcat (or TomEE) is going to make any difference.
>
>>
>
>> -chris
>
>>
>
>> On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>
>>>
>
>>>
>
>>> -----Original Message-----
>
>>> From: Christopher Schultz <ch...@christopherschultz.net>>
>
>>> Sent: Friday, August 15, 2025 12:18 PM
>
>>> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>
>>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
>>>
>
>>> Daniel,
>
>>>
>
>>> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>
>>>> Robert (and all),
>
>>>>
>
>>>> I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
>
>>>>
>
>>>> I have this system running on a PC identified as localhost. The test URL is:
>
>>>>
>
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_
>
>>>> H
>
>>>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_count
>
>>>> r
>
>>>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxz
>
>>>> o
>
>>>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1rfTe
>
>>>> d
>
>>>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JSDa9
>
>>>> P
>
>>>> xsSFgB4&e=
>
>>>>
>
>>>> I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
>
>>>>
>
>>>> Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
>
>>>>
>
>>>> I take this to mean that exceptions are not being "swallowed" by my program. When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
>
>>>>
>
>>>> The actual code fragments and outputs are copied below.
>
>>>>
>
>>>> ----------------------------------------------------------------
>
>>>> The code that throws the SQL exception
>
>>>> ----------------------------------------------------------------
>
>>>> @GET
>
>>>> @Path("/countries")
>
>>>> @Produces(MediaType.APPLICATION_JSON)
>
>>>> public String getJsonCountries() {
>
>>>> if (TempDataStorage.countryList == null) {
>
>>>> Connection connection = null;
>
>>>> try {
>
>>>> connection = dataSource.getConnection();
>
>>>> System.out.println("countries connection has been opened");
>
>>>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>
>>>> throw new SQLException("testing sql exception");
>
>>>> // connection.close();
>
>>>> // System.out.println("countries connection has been closed");
>
>>>> } catch (SQLException e) {
>
>>>> System.out.println(e);
>
>>>> System.out.println("catching sql exception");
>
>>>> if (connection != null) {
>
>>>> try {
>
>>>> connection.close();
>
>>>> } catch (SQLException ex) {
>
>>>> System.out.println(ex);
>
>>>> }
>
>>>> }
>
>>>> }
>
>>>> }
>
>>>
>
>>> 100% connection leak every time, guaranteed.
>
>>>
>
>>> You are never closing the connection, because it's been commented out.
>
>>> Perhaps this was just for testing, because I see you are throwing an exception.
>
>>>
>
>>> DGS: When I put in the throw statement, I had to comment out those two lines because the Java compiler complains that they are unreachable. This was just to test for what would happen if an SQL exception was thrown, in which case, yes, there will be a memory. The point is that my program never throws SQL exceptions, because if it did, I would know about it.
>
>>>
>
>>> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>
>>>
>
>>> DGS: Sounds like good advice. I'll do this and see if it makes a difference.
>
>>>
>
>>>> ------------------------------------------------------------------
>
>>>> The output in the server.log file
>
>>>> ------------------------------------------------------------------
>
>>>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue: 800] [[
>
>>>> countries connection has been opened]]
>
>>>>
>
>>>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>
>>>> java.sql.SQLException: testing sql exception
>
>>>> at
>
>>>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResourc
>
>>>> e
>
>>>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>
>>>>
>
>>>> ... stack trace ...
>
>>>>
>
>>>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>
>>>> catching sql exception]]
>
>>>
>
>>> ... and the server does not crash. You can make any request without restarting Glassfish, right?
>
>>>
>
>>>> ----------------------------------------------------------------
>
>>>> The code that divides by zero
>
>>>> ----------------------------------------------------------------
>
>>>> @GET
>
>>>> @Path("/countries")
>
>>>> @Produces(MediaType.APPLICATION_JSON)
>
>>>> public String getJsonCountries() {
>
>>>> if (TempDataStorage.countryList == null) {
>
>>>> Connection connection = null;
>
>>>> try {
>
>>>> connection = dataSource.getConnection();
>
>>>> System.out.println("countries connection has been opened");
>
>>>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>
>>>> float something = 1/0;
>
>>>> connection.close();
>
>>>> System.out.println("countries connection has been closed");
>
>>>> } catch (SQLException e) {
>
>>>> System.out.println(e);
>
>>>> System.out.println("catching sql exception");
>
>>>> if (connection != null) {
>
>>>> try {
>
>>>> connection.close();
>
>>>> } catch (SQLException ex) {
>
>>>> System.out.println(ex);
>
>>>> }
>
>>>> }
>
>>>> }
>
>>>> }
>
>>>
>
>>>
>
>>> 100% connection leak every time, guaranteed.
>
>>>
>
>>> You are never closing the connection, because your code is throwing an uncaught exception (divide by zero) Perhaps this was just for testing, because I see you are intentionally dividing by zero.
>
>>>
>
>>> DGS: Right. This was to test for what would happen if a non-SQL exception were thrown, i.e., one that is not caught in the catch clause. This created a 505 error and the program quit running. Here the point is that, if something like this were to happen, I would certainly know about it, and it has never happened, so no memory leak is being created in this way.
>
>>>
>
>>> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>
>>>
>
>>> DGS: Thanks again. I'll do this and see if it makes any difference in the connection pooling.
>
>>>
>
>>> -chris
>
>>>
>
>>>
>
>>> ---------------------------------------------------------------------
>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>
>>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
>>>
>
>>>
>
>>> ---------------------------------------------------------------------
>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>
>>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
>>>
>
>>
>
>>
>
>> ---------------------------------------------------------------------
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>
>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
>>
>
>>
>
>> ---------------------------------------------------------------------
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>
>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 16, at 00:02, Robert Turner <rt...@e-djuster.ca.INVALID> wrote:
>
> Dan,
>
> What's your thread pool size?
>
> With the default of 5, I can never get the high watermark for the
> connection above 5 (as I would expect). If I bump up the thread pool max
> size, and decrease the maximum db connection pool size, I can then get
> connections to queue, etc.
>
> They behave exactly as I would expect and I can never trigger a message
> about being unable to obtain a connection.
>
> I added a sleep of 200ms in the previous code I shared while holding the
> connection to simulate being slow.
>
> Everything worked without issue. I can fire thousands of connections at it
> with no running out of connection problems. Requests queue up and wait for
> a connection to be released.
>
> There must be something wrong with how you are managing and using the
> connections.
>
> Could you provide a sample of the code that uses the connection?
Seeing the exact configuration of the JDBC pool would also be useful, but a quick perusal of the GlassFish asadmin doc didn’t come up with a way to display that.
Also, here’s an interesting config item that might be useful in tracking down problems:
--wrapjdbcobjects
Specifies whether the pooling infrastructure provides wrapped JDBC objects to applications. By providing wrapped JDBC objects, the pooling infrastructure prevents connection leaks by ensuring that applications use logical connections from the connection pool, not physical connections. The use of logical connections ensures that the connections are returned to the connection pool when they are closed. However, the provision of wrapped JDBC objects can impair the performance of applications. The default value is true.
The pooling infrastructure provides wrapped objects for implementations of the following interfaces in the JDBC API:
java.sql.CallableStatement
java.sql.DatabaseMetaData
java.sql.PreparedStatement
java.sql.ResultSet
java.sql.Statement
Possible values of --wrapjdbcobjects are as follows:
false
The pooling infrastructure does not provide wrapped JDBC objects to applications. (default).
true
The pooling infrastructure provides wrapped JDBC objects to applications.
Not sure what the default setting actually is, since the general description says it’s true, but the specific description of false says that’s the default. (The GlassFish doc leaves a bit to be desired…)
Explicitly setting wrap-jdbc-objects to true should take care of non-connection resource leaks, and I suspect performance isn’t a serious concern at this stage.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Here is my file GetCountryList.java. I have sent the code for the fragment that retrieves the list of countries. Yes, there are others, for getting the states, cities, and holiday lists, but these are all conceptually very similar and I have used the same code structure for all of them.
-------------------------------------------------------------
package com.worldholidaysandevents.restjsonwebservice;
import java.util.ArrayList;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
public class GetCountryList {
public static ArrayList<String> doIt(Connection connection) {
PreparedStatement getCountries = null;
ResultSet resultSet;
ArrayList<String> countryList = new ArrayList();
try {
getCountries = connection.prepareStatement(
"SELECT Name FROM countries ORDER BY Name");
resultSet = getCountries.executeQuery();
while (resultSet.next()) {
countryList.add(resultSet.getString("Name"));
}
} catch (SQLException e) {
System.out.println(e.getStackTrace());
} catch (Exception e) {
System.out.println(e.getStackTrace());
} finally {
try {
if (getCountries != null) {
getCountries.close();
}
} catch (Exception e) {
System.out.println(e.getStackTrace());
}
}
return countryList;
}
}
From: Chuck Caldarale <n8...@gmail.com>
Sent: Saturday, August 16, 2025 1:19 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 16, at 11:35, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > Working through the numerous replies ... > > -----Original Message----- > From: Robert Turner <rt...@e-djuster.ca.INVALID>> >
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fe5ddd8f8c456acd411856bce1fc00557b387a35fa011951ea72d245198a3728359fd4fc73151f370c0e368485739d043ecff55adc20084a406e8736a9260f9225738f0f1f3d2c640f3ecd476dfd262b631b02690981516c72c4a01f6166ac77c60906d82ff874d2d71234b391a17b9a7f46424cd0c7720b1f424ce80970822d3bd32df830858add24fa43915db82ab3e29e672fc0844d872bdfd1876ee3fd0f001507244df4a514e7c7c5cebe0c9d032eec81bb497d42b6b74e5425dc5961c3720163bde31b0e906c632c8299ab1728177e513afd691b25a5caac9627902dfde61d8ac9b403ba2ae>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fe5ddd8f8c456acd411856bce1fc00557b387a35fa011951ea72d245198a3728359fd4fc73151f370c0e368485739d043ecff55adc20084a406e8736a9260f9225738f0f1f3d2c640f3ecd476dfd262b631b02690981516c72c4a01f6166ac77c60906d82ff874d2d71234b391a17b9a7f46424cd0c7720b1f424ce80970822d3bd32df830858add24fa43915db82ab3e29e672fc0844d872bdfd1876ee3fd0f001507244df4a514e7c7c5cebe0c9d032eec81bb497d42b6b74e5425dc5961c3720163bde31b0e906c632c8299ab1728177e513afd691b25a5caac9627902dfde61d8ac9b403ba2ae>
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 16, at 11:35, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Working through the numerous replies ...
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>>
> Sent: Saturday, August 16, 2025 1:03 AM
> To: Tomcat Users List <us...@tomcat.apache.org>>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Dan,
>
> What's your thread pool size?
>
> DGS: I don't know how to determine this.
GlassFish does seem to be somewhat limited in its reporting of the configuration details. The 4.1 doc is even worse than the current 7.0 - wordy, but sparse details. They may be a GlassFish management page that reports DB and thread pool settings, but I haven’t found it yet.
> Could you provide a sample of the code that uses the connection?
>
> DGS: Here is the current version of the code fragment that retrieves the list of countries.
I think what Robert is looking for is the code in GetCountryList, not the code that acquires the connection object.
> The method call "GetCountryList.doIt(connection);" does create a prepared statement, but this is always closed immediately after use. In any case, the DB connection is always closed in the code below, as far as I can tell. I've never seen an exception thrown in the running code, so I don't see any possibility for a memory leak.
What about the other actual usage of the connection object? I believe you have stated that there are 4 such instances.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 16, at 11:35, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Working through the numerous replies ...
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Saturday, August 16, 2025 1:03 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Dan,
>
> What's your thread pool size?
>
> DGS: I don't know how to determine this.
GlassFish does seem to be somewhat limited in its reporting of the configuration details. The 4.1 doc is even worse than the current 7.0 - wordy, but sparse details. They may be a GlassFish management page that reports DB and thread pool settings, but I haven’t found it yet.
> Could you provide a sample of the code that uses the connection?
>
> DGS: Here is the current version of the code fragment that retrieves the list of countries.
I think what Robert is looking for is the code in GetCountryList, not the code that acquires the connection object.
> The method call "GetCountryList.doIt(connection);" does create a prepared statement, but this is always closed immediately after use. In any case, the DB connection is always closed in the code below, as far as I can tell. I've never seen an exception thrown in the running code, so I don't see any possibility for a memory leak.
What about the other actual usage of the connection object? I believe you have stated that there are 4 such instances.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Working through the numerous replies ...
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Saturday, August 16, 2025 1:03 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Dan,
What's your thread pool size?
DGS: I don't know how to determine this.
With the default of 5, I can never get the high watermark for the connection above 5 (as I would expect). If I bump up the thread pool max size, and decrease the maximum db connection pool size, I can then get connections to queue, etc.
They behave exactly as I would expect and I can never trigger a message about being unable to obtain a connection.
I added a sleep of 200ms in the previous code I shared while holding the connection to simulate being slow.
Everything worked without issue. I can fire thousands of connections at it with no running out of connection problems. Requests queue up and wait for a connection to be released.
There must be something wrong with how you are managing and using the connections.
Could you provide a sample of the code that uses the connection?
DGS: Here is the current version of the code fragment that retrieves the list of countries. The method call "GetCountryList.doIt(connection);" does create a prepared statement, but this is always closed immediately after use. In any case, the DB connection is always closed in the code below, as far as I can tell. I've never seen an exception thrown in the running code, so I don't see any possibility for a memory leak.
@Path("holidaysandevents")
public class HolidaysRESTJSONResource {
@Context
private UriInfo context;
DataSource dataSource;
public HolidaysRESTJSONResource() {
dataSource = DataSourceSingleton.getInstance().dataSource;
}
@GET
@Path("/countries")
@Produces(MediaType.APPLICATION_JSON)
public String getJsonCountries() {
if (TempDataStorage.countryList == null) {
Connection connection = null;
try {
connection = dataSource.getConnection();
TempDataStorage.countryList = GetCountryList.doIt(connection);
} catch (SQLException e) {
System.out.println(e.getStackTrace());
} finally {
if (connection != null) {
try {
connection.close();
} catch (SQLException ex) {
System.out.println(ex.getStackTrace());
}
}
}
}
Robert
On Sat, Aug 16, 2025, 00:35 Robert Turner <rt...@e-djuster.ca> wrote:
> Dan,
>
> FWIW, I just set up test Glassfish server, and made a trivial app to
> acquire and release a connection from the pool.
>
> I configured the connection with a minimum and starting size of 1.
>
> I tested with 1 connection, and it did exactly what I expected.
> Acquired and released 1 connection. No more connections were allocated.
>
> The setting for the minimum size is also the initial size (no
> surprise), and I could set that value to 1.
>
> My code to acquire the connection was this trivial code:
>
> final InitialContext ic = new InitialContext(); final DataSource ds =
> (DataSource) ic.lookup("test1"); try (Connection conn =
> ds.getConnection()) { } catch (SQLException e) {
> throw new Runtime exception(e);
> }
>
> So, I don't agree with your "conclusion" about 8 connections per.
>
> Robert
>
>
>
> On Sat, Aug 16, 2025, 00:02 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
>> Chuck,
>>
>> Okay, here is the text of the attachment.
>>
>> Instance Name:
>> server
>>
>>
>>
>>
>> Resource : HolidaysConnectionPool Application :
>> HolidaysRESTJSON-1.0-SNAPSHOT
>>
>> Monitor (14 Statistics)
>> JDBC Connection Pool Statistics : HolidaysConnectionPool Name Value
>> Start Time Last Sample Time Details Description NumConnCreated
>> 8 count
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> --
>> The number of physical connections that were created since the last reset.
>> NumConnFree
>> 8count
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> High Water Mark: 8 count
>> Low Water Mark: 0 count
>> The total number of free connections in the pool as of the last sampling.
>> NumConnReleased
>> 1 count
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> --
>> Number of logical connections released to the pool.
>> NumPotentialConnLeak
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of potential connection leaks
>> NumConnFailedValidation
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> The total number of connections in the connection pool that failed
>> validation from the start time until the last sample time.
>> ConnRequestWaitTime
>> 485millisecond
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> High Water Mark: 485 millisecond
>> Low Water Mark: 0 millisecond
>> The longest and shortest wait times of connection requests. The
>> current value indicates the wait time of the last request that was
>> serviced by the pool.
>> NumConnAcquired
>> 1 count
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> --
>> Number of logical connections acquired from the pool.
>> AverageConnWaitTime
>> 485 millisecond
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:33 AM
>> --
>> Average wait-time-duration per successful connection request
>> NumConnDestroyed
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of physical connections that were destroyed since the last reset.
>> NumConnSuccessfullyMatched
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of connections succesfully matched
>> NumConnNotSuccessfullyMatched
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of connections rejected during matching NumConnUsed 0count Aug
>> 15, 2025 1:26:20 AM Aug 15, 2025 1:26:21 AM High Water Mark: 1 count
>> Low Water Mark: 0 count Provides connection usage statistics. The
>> total number of connections that are currently being used, as well as
>> information about the maximum number of connections that were used
>> (the high water mark).
>> WaitQueueLength
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of connection requests in the queue waiting to be serviced.
>> NumConnTimedOut
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> The total number of connections in the pool that timed out between
>> the start time and the last sample time.
>>
>> Regarding your statement "What is more likely is that the GlassFish
>> connection pool simply initializes the configured minimum number of
>> connections on the first attempt to acquire a connection.", I have no
>> idea hat this means.
>>
>> Dan
>>
>> From: Chuck Caldarale <n8...@gmail.com>
>> Sent: Friday, August 15, 2025 11:39 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> > On 2025 Aug 15, at 22:03, Daniel Schwartz <dan@danielgschwartz.com
>> <ma...@danielgschwartz.com>> wrote: > > I think I found the answer.
>> > > A few days ago, someone suggested that I try setting the
>> > > Glassfish
>> maximum pool size to 1 and see what happens.
>> NkdkJdXPPEBannerStart
>> Be Careful With This Message
>> From (Chuck Caldarale <n8...@gmail.com>)<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c
>> 7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a2
>> 3d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb
>> 98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e
>> 1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc87547
>> 79156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d5482
>> 92c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd
>> 617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd
>> >
>> Learn More<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c
>> 7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a2
>> 3d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb
>> 98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e
>> 1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc87547
>> 79156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d5482
>> 92c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd
>> 617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd
>> >
>> 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 15, at 22:03, Daniel Schwartz <dan@danielgschwartz.com
>> <ma...@danielgschwartz.com>> wrote:
>>
>> >
>>
>> > I think I found the answer.
>>
>> >
>>
>> > A few days ago, someone suggested that I try setting the Glassfish
>> maximum pool size to 1 and see what happens. I reported back that in
>> Glassfish the minimum pool size is 8, to which someone responded that
>> this seems strange. I really didn't know. But now I do.
>>
>> >
>>
>> > Today I decided to run a test where I cleared out Glassfish so I
>> > could
>> start from scratch. I executed one REST request using the URL I
>> posted recently, which returns a list of countries. Then I looked at
>> the Glassfish JDBC pool monitor. A PDF of this is attached.
>>
>>
>>
>>
>>
>> The list strips nearly all attachments, for safely reasons. You need
>> to post the text.
>>
>>
>>
>>
>>
>> > You will see that it says the following:
>>
>> >
>>
>> > 1. NumConnAcquired, 1 count, Number of logical connection
>>
>> >
>>
>> > 2. NumConnReleased, 1 count, Number of logical connections released
>> > to
>> the pool.
>>
>> >
>>
>> > 3. NumConnCreated, 8 count, The number of physical connections that
>> were created since the last reset.
>>
>> >
>>
>> > 4. NumConnFree, 8count, The total number of free connections in the
>> pool as of the last sampling.
>>
>> >
>>
>> > I believe that this is why the minimum pool size is 8; each logical
>> connection requires 8 physical connections.
>>
>> >
>>
>> > This leads me to believe that this is why the number of connections
>> > in
>> my connection pool is much larger than what one would expect.
>> Assuming that Tomcat only requires one connection object per query,
>> this implies that Glassfish requires 8 times that amount.
>>
>>
>>
>>
>>
>> I think that is extremely unlikely. What is more likely is that the
>> GlassFish connection pool simply initializes the configured minimum
>> number of connections on the first attempt to acquire a connection.
>>
>>
>>
>> You can test this by making concurrent requests and seeing what
>> happens to the pool counters. Try inserting a delay in your code
>> between opening a connection and closing it; something like
>> Thread.currentThread().sleep(10000) would likely suffice. Then
>> initiate independent requests from several browser tabs in parallel;
>> the 10-second delay should allow time for each request to grab its
>> own connection from the pool while the other requests are still active.
>>
>>
>>
>>
>>
>> > So, while a normal pool size for Tomcat might be 20 connections, in
>> Glassfish this same activity would require 160 connections.
>>
>> >
>>
>> > In any case, I'm now 100% sure that my program doesn't, and never
>> > did,
>> have a memory leak. I have modified my code according to Chris's
>> recommendations, as this surely is good advice, but it hasn't changed
>> the performance, since no exceptions were ever being thrown.
>>
>>
>>
>>
>>
>> Did you apply the try-catch-finally pattern to all DB-related
>> objects, such as statements, prepared statements, and result sets?
>>
>>
>>
>> - Chuck
>>
>>
>>
>>
>>
>> > It appears to me that Glassfish is performing normally according to
>> > its
>> internal design, and there really is no problem as long as I keep the
>> maximum pool size large enough.
>>
>> >
>>
>> > What do you think?
>>
>> >
>>
>> > Dan
>>
>> >
>>
>> > -----Original Message-----
>>
>> > From: Christopher Schultz <chris@christopherschultz.net<mailto:
>> chris@christopherschultz.net>>
>>
>> > Sent: Friday, August 15, 2025 1:07 PM
>>
>> > To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> >
>>
>> > Dan,
>>
>> >
>>
>> > The only reason we are all looking for resource leaks (technically
>> > not
>> memory leaks, but leaks nonetheless) is because it's the best
>> explanation for why your connection pool seems to be running dry.
>>
>> >
>>
>> > I don't think that switching to Tomcat (or TomEE) is going to make
>> > any
>> difference.
>>
>> >
>>
>> > -chris
>>
>> >
>>
>> > On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>>
>> >>
>>
>> >>
>>
>> >> -----Original Message-----
>>
>> >> From: Christopher Schultz <chris@christopherschultz.net<mailto:
>> chris@christopherschultz.net>>
>>
>> >> Sent: Friday, August 15, 2025 12:18 PM
>>
>> >> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>> >> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> >>
>>
>> >> Daniel,
>>
>> >>
>>
>> >> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>>
>> >>> Robert (and all),
>>
>> >>>
>>
>> >>> I will work on answers your various questions. However, I
>> >>> decided to
>> first explore the comment (by someone) that a servlet can "swallow"
>> an exception, which I take to mean that it can throw an exception
>> without reporting the exception or terminating the program.
>>
>> >>>
>>
>> >>> I have this system running on a PC identified as localhost. The
>> >>> test
>> URL is:
>>
>> >>>
>>
>> >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8
>> >>> 080_
>>
>> >>> H
>>
>> >>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_c
>> >>> ount
>>
>> >>> r
>>
>> >>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCa
>> >>> lLxz
>>
>> >>> o
>>
>> >>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1
>> >>> rfTe
>>
>> >>> d
>>
>> >>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4J
>> >>> SDa9
>>
>> >>> P
>>
>> >>> xsSFgB4&e=
>>
>> >>>
>>
>> >>> I ran two tests. First, I wrote in code to throw an SQL
>> >>> exception,
>> which did get caught in my catch clause, which printed out some
>> messages and a stack trace. The web browser showed the retrieved
>> list of countries, but nothing else.
>>
>> >>>
>>
>> >>> Second, I replaced the line that throws the SQL exception by one
>> >>> that
>> tries to do a division by zero. This of course was not caught, but
>> it did print out a stack trace and reported a 505 error in the
>> browser, and the program did terminate.
>>
>> >>>
>>
>> >>> I take this to mean that exceptions are not being "swallowed" by
>> >>> my
>> program. When/if an exception occurs, there is definitely some
>> indication of this, either in the server.log or the browser. Because
>> I have never seen either of these actions, I'm fairly sure that my
>> program is not throwing exceptions and all database connections are
>> being closed immediately after they are used, i.e., no memory leaks in this respect.
>>
>> >>>
>>
>> >>> The actual code fragments and outputs are copied below.
>>
>> >>>
>>
>> >>> ----------------------------------------------------------------
>>
>> >>> The code that throws the SQL exception
>>
>> >>> ----------------------------------------------------------------
>>
>> >>> @GET
>>
>> >>> @Path("/countries")
>>
>> >>> @Produces(MediaType.APPLICATION_JSON)
>>
>> >>> public String getJsonCountries() {
>>
>> >>> if (TempDataStorage.countryList == null) {
>>
>> >>> Connection connection = null;
>>
>> >>> try {
>>
>> >>> connection = dataSource.getConnection();
>>
>> >>> System.out.println("countries connection has
>> >>> been
>> opened");
>>
>> >>> TempDataStorage.countryList =
>> GetCountryList.doIt(connection);
>>
>> >>> throw new SQLException("testing sql exception");
>>
>> >>> // connection.close();
>>
>> >>> // System.out.println("countries connection has been
>> closed");
>>
>> >>> } catch (SQLException e) {
>>
>> >>> System.out.println(e);
>>
>> >>> System.out.println("catching sql exception");
>>
>> >>> if (connection != null) {
>>
>> >>> try {
>>
>> >>> connection.close();
>>
>> >>> } catch (SQLException ex) {
>>
>> >>> System.out.println(ex);
>>
>> >>> }
>>
>> >>> }
>>
>> >>> }
>>
>> >>> }
>>
>> >>
>>
>> >> 100% connection leak every time, guaranteed.
>>
>> >>
>>
>> >> You are never closing the connection, because it's been commented out.
>>
>> >> Perhaps this was just for testing, because I see you are throwing
>> >> an
>> exception.
>>
>> >>
>>
>> >> DGS: When I put in the throw statement, I had to comment out those
>> >> two
>> lines because the Java compiler complains that they are unreachable.
>> This was just to test for what would happen if an SQL exception was
>> thrown, in which case, yes, there will be a memory. The point is
>> that my program never throws SQL exceptions, because if it did, I would know about it.
>>
>> >>
>>
>> >> The conn.close() *MUST* be in a finally {} block. Do not put it in
>> >> the
>> try block. Do not put it in the catch block. Always put it in the
>> finally block.
>>
>> >>
>>
>> >> DGS: Sounds like good advice. I'll do this and see if it makes a
>> difference.
>>
>> >>
>>
>> >>> -----------------------------------------------------------------
>> >>> -
>>
>> >>> The output in the server.log file
>>
>> >>> -----------------------------------------------------------------
>> >>> -
>>
>> >>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid:
>> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue:
>> 800] [[
>>
>> >>> countries connection has been opened]]
>>
>> >>>
>>
>> >>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid:
>> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue:
>> 800] [[
>>
>> >>> java.sql.SQLException: testing sql exception
>>
>> >>> at
>>
>> >>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONRes
>> >>> ourc
>>
>> >>> e
>>
>> >>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>>
>> >>>
>>
>> >>> ... stack trace ...
>>
>> >>>
>>
>> >>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid:
>> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue:
>> 800] [[
>>
>> >>> catching sql exception]]
>>
>> >>
>>
>> >> ... and the server does not crash. You can make any request
>> >> without
>> restarting Glassfish, right?
>>
>> >>
>>
>> >>> ----------------------------------------------------------------
>>
>> >>> The code that divides by zero
>>
>> >>> ----------------------------------------------------------------
>>
>> >>> @GET
>>
>> >>> @Path("/countries")
>>
>> >>> @Produces(MediaType.APPLICATION_JSON)
>>
>> >>> public String getJsonCountries() {
>>
>> >>> if (TempDataStorage.countryList == null) {
>>
>> >>> Connection connection = null;
>>
>> >>> try {
>>
>> >>> connection = dataSource.getConnection();
>>
>> >>> System.out.println("countries connection has
>> >>> been
>> opened");
>>
>> >>> TempDataStorage.countryList =
>> GetCountryList.doIt(connection);
>>
>> >>> float something = 1/0;
>>
>> >>> connection.close();
>>
>> >>> System.out.println("countries connection has
>> >>> been
>> closed");
>>
>> >>> } catch (SQLException e) {
>>
>> >>> System.out.println(e);
>>
>> >>> System.out.println("catching sql exception");
>>
>> >>> if (connection != null) {
>>
>> >>> try {
>>
>> >>> connection.close();
>>
>> >>> } catch (SQLException ex) {
>>
>> >>> System.out.println(ex);
>>
>> >>> }
>>
>> >>> }
>>
>> >>> }
>>
>> >>> }
>>
>> >>
>>
>> >>
>>
>> >> 100% connection leak every time, guaranteed.
>>
>> >>
>>
>> >> You are never closing the connection, because your code is
>> >> throwing an
>> uncaught exception (divide by zero) Perhaps this was just for
>> testing, because I see you are intentionally dividing by zero.
>>
>> >>
>>
>> >> DGS: Right. This was to test for what would happen if a non-SQL
>> exception were thrown, i.e., one that is not caught in the catch clause.
>> This created a 505 error and the program quit running. Here the
>> point is that, if something like this were to happen, I would
>> certainly know about it, and it has never happened, so no memory leak
>> is being created in this way.
>>
>> >>
>>
>> >> The conn.close() *MUST* be in a finally {} block. Do not put it in
>> >> the
>> try block. Do not put it in the catch block. Always put it in the
>> finally block.
>>
>> >>
>>
>> >> DGS: Thanks again. I'll do this and see if it makes any
>> >> difference in
>> the connection pooling.
>>
>> >>
>>
>> >> -chris
>>
>> >>
>>
>> >>
>>
>> >> ------------------------------------------------------------------
>> >> ---
>>
>> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>> >>
>>
>> >>
>>
>> >> ------------------------------------------------------------------
>> >> ---
>>
>> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>> >>
>>
>> >
>>
>> >
>>
>> > -------------------------------------------------------------------
>> > --
>>
>> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>> >
>>
>> >
>>
>> > -------------------------------------------------------------------
>> > --
>>
>> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Dan,
What's your thread pool size?
With the default of 5, I can never get the high watermark for the
connection above 5 (as I would expect). If I bump up the thread pool max
size, and decrease the maximum db connection pool size, I can then get
connections to queue, etc.
They behave exactly as I would expect and I can never trigger a message
about being unable to obtain a connection.
I added a sleep of 200ms in the previous code I shared while holding the
connection to simulate being slow.
Everything worked without issue. I can fire thousands of connections at it
with no running out of connection problems. Requests queue up and wait for
a connection to be released.
There must be something wrong with how you are managing and using the
connections.
Could you provide a sample of the code that uses the connection?
Robert
On Sat, Aug 16, 2025, 00:35 Robert Turner <rt...@e-djuster.ca> wrote:
> Dan,
>
> FWIW, I just set up test Glassfish server, and made a trivial app to
> acquire and release a connection from the pool.
>
> I configured the connection with a minimum and starting size of 1.
>
> I tested with 1 connection, and it did exactly what I expected. Acquired
> and released 1 connection. No more connections were allocated.
>
> The setting for the minimum size is also the initial size (no surprise),
> and I could set that value to 1.
>
> My code to acquire the connection was this trivial code:
>
> final InitialContext ic = new InitialContext();
> final DataSource ds = (DataSource) ic.lookup("test1");
> try (Connection conn = ds.getConnection()) {
> } catch (SQLException e) {
> throw new Runtime exception(e);
> }
>
> So, I don't agree with your "conclusion" about 8 connections per.
>
> Robert
>
>
>
> On Sat, Aug 16, 2025, 00:02 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
>> Chuck,
>>
>> Okay, here is the text of the attachment.
>>
>> Instance Name:
>> server
>>
>>
>>
>>
>> Resource : HolidaysConnectionPool Application :
>> HolidaysRESTJSON-1.0-SNAPSHOT
>>
>> Monitor (14 Statistics)
>> JDBC Connection Pool Statistics : HolidaysConnectionPool
>> Name
>> Value
>> Start Time
>> Last Sample Time
>> Details
>> Description
>> NumConnCreated
>> 8 count
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> --
>> The number of physical connections that were created since the last reset.
>> NumConnFree
>> 8count
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> High Water Mark: 8 count
>> Low Water Mark: 0 count
>> The total number of free connections in the pool as of the last sampling.
>> NumConnReleased
>> 1 count
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> --
>> Number of logical connections released to the pool.
>> NumPotentialConnLeak
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of potential connection leaks
>> NumConnFailedValidation
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> The total number of connections in the connection pool that failed
>> validation from the start time until the last sample time.
>> ConnRequestWaitTime
>> 485millisecond
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> High Water Mark: 485 millisecond
>> Low Water Mark: 0 millisecond
>> The longest and shortest wait times of connection requests. The current
>> value indicates the wait time of the last request that was serviced by the
>> pool.
>> NumConnAcquired
>> 1 count
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> --
>> Number of logical connections acquired from the pool.
>> AverageConnWaitTime
>> 485 millisecond
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:33 AM
>> --
>> Average wait-time-duration per successful connection request
>> NumConnDestroyed
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of physical connections that were destroyed since the last reset.
>> NumConnSuccessfullyMatched
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of connections succesfully matched
>> NumConnNotSuccessfullyMatched
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of connections rejected during matching
>> NumConnUsed
>> 0count
>> Aug 15, 2025 1:26:20 AM
>> Aug 15, 2025 1:26:21 AM
>> High Water Mark: 1 count
>> Low Water Mark: 0 count
>> Provides connection usage statistics. The total number of connections
>> that are currently being used, as well as information about the maximum
>> number of connections that were used (the high water mark).
>> WaitQueueLength
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> Number of connection requests in the queue waiting to be serviced.
>> NumConnTimedOut
>> 0 count
>> Aug 15, 2025 1:26:20 AM
>> --
>> --
>> The total number of connections in the pool that timed out between the
>> start time and the last sample time.
>>
>> Regarding your statement "What is more likely is that the GlassFish
>> connection pool simply initializes the configured minimum number of
>> connections on the first attempt to acquire a connection.", I have no idea
>> hat this means.
>>
>> Dan
>>
>> From: Chuck Caldarale <n8...@gmail.com>
>> Sent: Friday, August 15, 2025 11:39 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> > On 2025 Aug 15, at 22:03, Daniel Schwartz <dan@danielgschwartz.com
>> <ma...@danielgschwartz.com>> wrote: > > I think I found the answer.
>> > > A few days ago, someone suggested that I try setting the Glassfish
>> maximum pool size to 1 and see what happens.
>> NkdkJdXPPEBannerStart
>> Be Careful With This Message
>> From (Chuck Caldarale <n8...@gmail.com>)<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd
>> >
>> Learn More<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd
>> >
>> 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 15, at 22:03, Daniel Schwartz <dan@danielgschwartz.com
>> <ma...@danielgschwartz.com>> wrote:
>>
>> >
>>
>> > I think I found the answer.
>>
>> >
>>
>> > A few days ago, someone suggested that I try setting the Glassfish
>> maximum pool size to 1 and see what happens. I reported back that in
>> Glassfish the minimum pool size is 8, to which someone responded that this
>> seems strange. I really didn't know. But now I do.
>>
>> >
>>
>> > Today I decided to run a test where I cleared out Glassfish so I could
>> start from scratch. I executed one REST request using the URL I posted
>> recently, which returns a list of countries. Then I looked at the
>> Glassfish JDBC pool monitor. A PDF of this is attached.
>>
>>
>>
>>
>>
>> The list strips nearly all attachments, for safely reasons. You need to
>> post the text.
>>
>>
>>
>>
>>
>> > You will see that it says the following:
>>
>> >
>>
>> > 1. NumConnAcquired, 1 count, Number of logical connection
>>
>> >
>>
>> > 2. NumConnReleased, 1 count, Number of logical connections released to
>> the pool.
>>
>> >
>>
>> > 3. NumConnCreated, 8 count, The number of physical connections that
>> were created since the last reset.
>>
>> >
>>
>> > 4. NumConnFree, 8count, The total number of free connections in the
>> pool as of the last sampling.
>>
>> >
>>
>> > I believe that this is why the minimum pool size is 8; each logical
>> connection requires 8 physical connections.
>>
>> >
>>
>> > This leads me to believe that this is why the number of connections in
>> my connection pool is much larger than what one would expect. Assuming
>> that Tomcat only requires one connection object per query, this implies
>> that Glassfish requires 8 times that amount.
>>
>>
>>
>>
>>
>> I think that is extremely unlikely. What is more likely is that the
>> GlassFish connection pool simply initializes the configured minimum number
>> of connections on the first attempt to acquire a connection.
>>
>>
>>
>> You can test this by making concurrent requests and seeing what happens
>> to the pool counters. Try inserting a delay in your code between opening a
>> connection and closing it; something like
>> Thread.currentThread().sleep(10000) would likely suffice. Then initiate
>> independent requests from several browser tabs in parallel; the 10-second
>> delay should allow time for each request to grab its own connection from
>> the pool while the other requests are still active.
>>
>>
>>
>>
>>
>> > So, while a normal pool size for Tomcat might be 20 connections, in
>> Glassfish this same activity would require 160 connections.
>>
>> >
>>
>> > In any case, I'm now 100% sure that my program doesn't, and never did,
>> have a memory leak. I have modified my code according to Chris's
>> recommendations, as this surely is good advice, but it hasn't changed the
>> performance, since no exceptions were ever being thrown.
>>
>>
>>
>>
>>
>> Did you apply the try-catch-finally pattern to all DB-related objects,
>> such as statements, prepared statements, and result sets?
>>
>>
>>
>> - Chuck
>>
>>
>>
>>
>>
>> > It appears to me that Glassfish is performing normally according to its
>> internal design, and there really is no problem as long as I keep the
>> maximum pool size large enough.
>>
>> >
>>
>> > What do you think?
>>
>> >
>>
>> > Dan
>>
>> >
>>
>> > -----Original Message-----
>>
>> > From: Christopher Schultz <chris@christopherschultz.net<mailto:
>> chris@christopherschultz.net>>
>>
>> > Sent: Friday, August 15, 2025 1:07 PM
>>
>> > To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> >
>>
>> > Dan,
>>
>> >
>>
>> > The only reason we are all looking for resource leaks (technically not
>> memory leaks, but leaks nonetheless) is because it's the best explanation
>> for why your connection pool seems to be running dry.
>>
>> >
>>
>> > I don't think that switching to Tomcat (or TomEE) is going to make any
>> difference.
>>
>> >
>>
>> > -chris
>>
>> >
>>
>> > On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>>
>> >>
>>
>> >>
>>
>> >> -----Original Message-----
>>
>> >> From: Christopher Schultz <chris@christopherschultz.net<mailto:
>> chris@christopherschultz.net>>
>>
>> >> Sent: Friday, August 15, 2025 12:18 PM
>>
>> >> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>> >> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> >>
>>
>> >> Daniel,
>>
>> >>
>>
>> >> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>>
>> >>> Robert (and all),
>>
>> >>>
>>
>> >>> I will work on answers your various questions. However, I decided to
>> first explore the comment (by someone) that a servlet can "swallow" an
>> exception, which I take to mean that it can throw an exception without
>> reporting the exception or terminating the program.
>>
>> >>>
>>
>> >>> I have this system running on a PC identified as localhost. The test
>> URL is:
>>
>> >>>
>>
>> >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_
>>
>> >>> H
>>
>> >>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_count
>>
>> >>> r
>>
>> >>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxz
>>
>> >>> o
>>
>> >>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1rfTe
>>
>> >>> d
>>
>> >>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JSDa9
>>
>> >>> P
>>
>> >>> xsSFgB4&e=
>>
>> >>>
>>
>> >>> I ran two tests. First, I wrote in code to throw an SQL exception,
>> which did get caught in my catch clause, which printed out some messages
>> and a stack trace. The web browser showed the retrieved list of countries,
>> but nothing else.
>>
>> >>>
>>
>> >>> Second, I replaced the line that throws the SQL exception by one that
>> tries to do a division by zero. This of course was not caught, but it did
>> print out a stack trace and reported a 505 error in the browser, and the
>> program did terminate.
>>
>> >>>
>>
>> >>> I take this to mean that exceptions are not being "swallowed" by my
>> program. When/if an exception occurs, there is definitely some indication
>> of this, either in the server.log or the browser. Because I have never
>> seen either of these actions, I'm fairly sure that my program is not
>> throwing exceptions and all database connections are being closed
>> immediately after they are used, i.e., no memory leaks in this respect.
>>
>> >>>
>>
>> >>> The actual code fragments and outputs are copied below.
>>
>> >>>
>>
>> >>> ----------------------------------------------------------------
>>
>> >>> The code that throws the SQL exception
>>
>> >>> ----------------------------------------------------------------
>>
>> >>> @GET
>>
>> >>> @Path("/countries")
>>
>> >>> @Produces(MediaType.APPLICATION_JSON)
>>
>> >>> public String getJsonCountries() {
>>
>> >>> if (TempDataStorage.countryList == null) {
>>
>> >>> Connection connection = null;
>>
>> >>> try {
>>
>> >>> connection = dataSource.getConnection();
>>
>> >>> System.out.println("countries connection has been
>> opened");
>>
>> >>> TempDataStorage.countryList =
>> GetCountryList.doIt(connection);
>>
>> >>> throw new SQLException("testing sql exception");
>>
>> >>> // connection.close();
>>
>> >>> // System.out.println("countries connection has been
>> closed");
>>
>> >>> } catch (SQLException e) {
>>
>> >>> System.out.println(e);
>>
>> >>> System.out.println("catching sql exception");
>>
>> >>> if (connection != null) {
>>
>> >>> try {
>>
>> >>> connection.close();
>>
>> >>> } catch (SQLException ex) {
>>
>> >>> System.out.println(ex);
>>
>> >>> }
>>
>> >>> }
>>
>> >>> }
>>
>> >>> }
>>
>> >>
>>
>> >> 100% connection leak every time, guaranteed.
>>
>> >>
>>
>> >> You are never closing the connection, because it's been commented out.
>>
>> >> Perhaps this was just for testing, because I see you are throwing an
>> exception.
>>
>> >>
>>
>> >> DGS: When I put in the throw statement, I had to comment out those two
>> lines because the Java compiler complains that they are unreachable. This
>> was just to test for what would happen if an SQL exception was thrown, in
>> which case, yes, there will be a memory. The point is that my program
>> never throws SQL exceptions, because if it did, I would know about it.
>>
>> >>
>>
>> >> The conn.close() *MUST* be in a finally {} block. Do not put it in the
>> try block. Do not put it in the catch block. Always put it in the finally
>> block.
>>
>> >>
>>
>> >> DGS: Sounds like good advice. I'll do this and see if it makes a
>> difference.
>>
>> >>
>>
>> >>> ------------------------------------------------------------------
>>
>> >>> The output in the server.log file
>>
>> >>> ------------------------------------------------------------------
>>
>> >>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid:
>> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue:
>> 800] [[
>>
>> >>> countries connection has been opened]]
>>
>> >>>
>>
>> >>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid:
>> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue:
>> 800] [[
>>
>> >>> java.sql.SQLException: testing sql exception
>>
>> >>> at
>>
>> >>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResourc
>>
>> >>> e
>>
>> >>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>>
>> >>>
>>
>> >>> ... stack trace ...
>>
>> >>>
>>
>> >>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid:
>> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue:
>> 800] [[
>>
>> >>> catching sql exception]]
>>
>> >>
>>
>> >> ... and the server does not crash. You can make any request without
>> restarting Glassfish, right?
>>
>> >>
>>
>> >>> ----------------------------------------------------------------
>>
>> >>> The code that divides by zero
>>
>> >>> ----------------------------------------------------------------
>>
>> >>> @GET
>>
>> >>> @Path("/countries")
>>
>> >>> @Produces(MediaType.APPLICATION_JSON)
>>
>> >>> public String getJsonCountries() {
>>
>> >>> if (TempDataStorage.countryList == null) {
>>
>> >>> Connection connection = null;
>>
>> >>> try {
>>
>> >>> connection = dataSource.getConnection();
>>
>> >>> System.out.println("countries connection has been
>> opened");
>>
>> >>> TempDataStorage.countryList =
>> GetCountryList.doIt(connection);
>>
>> >>> float something = 1/0;
>>
>> >>> connection.close();
>>
>> >>> System.out.println("countries connection has been
>> closed");
>>
>> >>> } catch (SQLException e) {
>>
>> >>> System.out.println(e);
>>
>> >>> System.out.println("catching sql exception");
>>
>> >>> if (connection != null) {
>>
>> >>> try {
>>
>> >>> connection.close();
>>
>> >>> } catch (SQLException ex) {
>>
>> >>> System.out.println(ex);
>>
>> >>> }
>>
>> >>> }
>>
>> >>> }
>>
>> >>> }
>>
>> >>
>>
>> >>
>>
>> >> 100% connection leak every time, guaranteed.
>>
>> >>
>>
>> >> You are never closing the connection, because your code is throwing an
>> uncaught exception (divide by zero) Perhaps this was just for testing,
>> because I see you are intentionally dividing by zero.
>>
>> >>
>>
>> >> DGS: Right. This was to test for what would happen if a non-SQL
>> exception were thrown, i.e., one that is not caught in the catch clause.
>> This created a 505 error and the program quit running. Here the point is
>> that, if something like this were to happen, I would certainly know about
>> it, and it has never happened, so no memory leak is being created in this
>> way.
>>
>> >>
>>
>> >> The conn.close() *MUST* be in a finally {} block. Do not put it in the
>> try block. Do not put it in the catch block. Always put it in the finally
>> block.
>>
>> >>
>>
>> >> DGS: Thanks again. I'll do this and see if it makes any difference in
>> the connection pooling.
>>
>> >>
>>
>> >> -chris
>>
>> >>
>>
>> >>
>>
>> >> ---------------------------------------------------------------------
>>
>> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>> >>
>>
>> >>
>>
>> >> ---------------------------------------------------------------------
>>
>> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>> >>
>>
>> >
>>
>> >
>>
>> > ---------------------------------------------------------------------
>>
>> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>> >
>>
>> >
>>
>> > ---------------------------------------------------------------------
>>
>> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>>
>>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Okay, well I'm glad you got it migrated to try-with-resources. This will
definitely avoid the leaks you were having (assuming you put them
everywhere you acquire connections). Because you have made this change, no
matter what exception may have occured (even if you didn't see it), you
will always release the connection now.
You may now want to enable statement leak detection.... And see what else
you might be leaking....
You never mentioned you were having compiler issues or that you had even
tried using try-with-resources, so from my perspective it looked like
resistance or something...
FWIW, you never found the original problem, which of course is concerning
because it means you still think you had no leaks. You definitely did have
leaks even if you didn't realize such. It would benefit you to identify the
original cause so as to see that there were indeed leaks and identify what
was causing them. I strongly suspect the bots were triggering an unchecked
exception, and without leak detection, you would never have noticed if it
weren't for the pool exhaustion.
Note that the high water mark in the connection pool data tells you the
highest number of connections that were open at once. Notice this is 2.
This is in keeping with what one would expect for such an application with
low traffic. Your statistics now look much better.
Your interpretation before was flawed because leak detection was disabled
before, so the value for NumPotentialConnLeak would have never changed, and
thus you were lulled into a false sense of confidence. Now, however, with
leak detection enabled, your interpretation is now correct.
And yes, this one change, will have made this difference, because there was
a leak...as we have said all along.
Robert
On Mon, Aug 18, 2025, 22:23 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Everyone,
>
> I wasn't resisting using the try-with-resources construct, only when I
> tried to do this, I was getting compiler errors. But I evidently wasn't
> doing it right, because I tried it again and this time it worked.
>
> Following is the new code for getting the list of countries. It uses this
> construct and in addition has an extra catch clause for any kind of
> exception. I have done this in all six places where a connection is being
> created.
>
> I restarted Glassfish earlier today and dropped in the new .war file. It
> has been running for 6-8 hours now. The log files show no evidence of any
> exceptions being thrown. The current contents of the JDBC monitor page are
> copied below. I don't know how to interpret most of this, but I do note
> that the number of connections released equals the number acquired. Also,
> I have set the Connection Leak Timeout to be 10 seconds, and the
> NumPotentialConnLeak is still at 0.
>
> In addition, I did some further experimenting with the pool size, and now
> I find that if I set the minimum back to 8 and the maximum to 32, which are
> the defaults, the system keeps running and doesn't output that "can't
> allocate more connections" message. For me this is very puzzling. Did my
> code changes have anything to do with this?
>
> Anyway, my interpretation of all this is as before, that there are no
> memory leaks. Is this correct?
>
> I'm trying to upgrade to the current version of Glassfish, but haven't
> gotten this working yet.
>
> Dan
>
>
> -----------------------------------------------------------------------------
> @Path("holidaysandevents")
> public class HolidaysRESTJSONResource {
>
> @Context
> private UriInfo context;
>
> DataSource dataSource;
>
> public HolidaysRESTJSONResource() {
> dataSource = DataSourceSingleton.getInstance().dataSource;
> }
>
> @GET
> @Path("/countries")
> @Produces(MediaType.APPLICATION_JSON)
> public String getJsonCountries() {
> if (TempDataStorage.countryList == null) {
> // Connection connection = null;
> try (Connection connection = dataSource.getConnection()){
> // connection = dataSource.getConnection();
> TempDataStorage.countryList =
> GetCountryList.doIt(connection);
> } catch (SQLException e) {
> System.out.println("Sql Exception" + e.getStackTrace());
> } catch (Exception e) {
> System.out.println("Other Exception" + e.getStackTrace());
> }
>
> //finally {
> // if (connection != null) {
> // try {
> // connection.close();
> // } catch (SQLException e) {
> // System.out.println(e.getStackTrace());
> // }
> // }
> // }
> }
> StringListWrapper listWrapper = new StringListWrapper();
> listWrapper.setTheList(TempDataStorage.countryList);
> return new Gson().toJson(listWrapper);
> }
>
> ---------------------------------------------------------------------------------
> Resource Monitoring
> Click Configure Monitoring and enable monitoring for a component or
> service by selecting either LOW or HIGH. See the Online Help for more
> information.
>
> Instance Name:
> server
>
> Resource :
> HolidaysConnectionPool
> Application :
> Monitor (14 Statistics)
> Collapse Group JDBC Connection Pool Statistics : HolidaysConnectionPool
>
> NumConnCreated 20 count Aug 18, 2025 5:47:56 PM Aug 19, 2025
> 12:37:57 AM -- The number of physical connections that were
> created since the last reset.
> NumConnFree 1count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM
> High Water Mark: 3 count
> Low Water Mark: 0 count
> The total number of free connections in the pool as of the last sampling.
> NumConnReleased 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025
> 1:48:33 AM -- Number of logical connections released to the pool.
> NumPotentialConnLeak 0 count Aug 18, 2025 5:47:56 PM -- --
> Number of potential connection leaks
> NumConnFailedValidation 0 count Aug 18, 2025 5:47:56 PM -- --
> The total number of connections in the connection pool that failed
> validation from the start time until the last sample time.
> ConnRequestWaitTime 0millisecond Aug 18, 2025 5:47:56 PM Aug 19,
> 2025 1:48:33 AM High Water Mark: 921 millisecond
> Low Water Mark: 0 millisecond
> The longest and shortest wait times of connection requests. The current
> value indicates the wait time of the last request that was serviced by the
> pool.
> NumConnAcquired 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025
> 1:48:33 AM -- Number of logical connections acquired from the pool.
> AverageConnWaitTime 12 millisecond Aug 18, 2025 5:47:56 PM Aug 19,
> 2025 1:49:00 AM -- Average wait-time-duration per successful
> connection request
> NumConnDestroyed 19 count Aug 18, 2025 5:47:56 PM Aug 19,
> 2025 12:37:57 AM -- Number of physical connections that were
> destroyed since the last reset.
> NumConnSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM --
> -- Number of connections succesfully matched
> NumConnNotSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM --
> -- Number of connections rejected during matching
> NumConnUsed 0count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM
> High Water Mark: 2 count
> Low Water Mark: 0 count
> Provides connection usage statistics. The total number of connections that
> are currently being used, as well as information about the maximum number
> of connections that were used (the high water mark).
> WaitQueueLength 0 count Aug 18, 2025 5:47:56 PM -- -- Number of
> connection requests in the queue waiting to be serviced.
> NumConnTimedOut 0 count Aug 18, 2025 5:47:56 PM -- -- The total
> number of connections in the pool that timed out between the start time and
> the last sample time.
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Monday, August 18, 2025 11:13 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> For instance, what happens when the year parameter for the "calender"
> request is not a number?
> Or if parameters are missing?
> Have you tested these situations?
>
> On Mon, Aug 18, 2025 at 10:52 AM Robert Turner <rt...@e-djuster.ca>
> wrote:
>
> > Daniel,
> >
> > You have a leak - this we are certain of. You just don't yet know what
> > causes it (it's clearly not a "standard use case" and the robots are
> > likely triggering it).
> >
> > If I have my bets it is an unhandled unchecked exception (I'd even
> > guess that it is likely a NumberFormatException) while processing one
> > of your operations. Since you are reluctant to move your code to
> > "try-with-resources" handling of the resource objects (which would
> > make the code easier to read and avoid this problem), you will
> > continue to see the problem unless you ensure that you are catching all
> exceptions (e.g.
> > Throwable) (which is a bad practice in general).
> >
> > The 388 connection cound is the existing leaked connections from
> > previous operations since you last started the Glassfish server and
> > pool. I did suggest you restart Glassfish after adjusting that
> > parameter to reset the numbers and the systems.
> >
> > From my testing, I am very confident that the different versions will
> > not behave differently in the context of your application.
> >
> > Please have some confidence that we do know what we are talking about.
> > Your problem is common and not unique.
> >
> > If I get some time, and with your permission, I might try to look at
> > your server operations and see if I can trigger it for you... but if
> > you share the code for all the operations (no need to share the DB
> > queries, just the Java code), I bet we can find it quickly. However,
> > us solving it for you avoids you benefiting from the learning experience.
> >
> > Robert
> >
> >
> > On Mon, Aug 18, 2025 at 10:44 AM Daniel Schwartz
> > <da...@danielgschwartz.com>
> > wrote:
> >
> >> Chris,
> >>
> >> I thought it was you. I too have a job and family, and this is only
> >> a side project, so my time also is limited.
> >>
> >> Anyway, I'm wondering if there really is a problem, or whether this
> >> is just normal Glassfish behavior. Yesterday I changed the Glassfish
> >> settings so that leak monitoring is activated, and today I got:
> >>
> >> NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- --
> >> Number of potential connection leaks
> >>
> >> Also, this value:
> >>
> >> NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 18, 2025
> >> 2:34:54 PM High Water Mark: 390 count Low Water Mark: 0 count
> >> Provides connection usage statistics. The total number of connections
> >> that are currently being used, as well as information about the
> >> maximum number of connections that were used (the high water mark).
> >>
> >> Has remained unchanged at 388.
> >>
> >> There has been suspicion that my system has a memory leak, but all
> >> indications are that this is not happening.
> >>
> >> I'm currently trying to upgrade to the current version of Glassfish
> >> to see if this behaves differently, but haven't gotten it working yet.
> >>
> >> Dan
> >>
> >>
> >> -----Original Message-----
> >> From: Christopher Schultz <ch...@christopherschultz.net>
> >> Sent: Monday, August 18, 2025 10:29 AM
> >> To: users@tomcat.apache.org
> >> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >>
> >> Daniel,
> >>
> >> On 8/16/25 10:57 PM, Daniel Schwartz wrote:
> >> > There was a Chris too, but I think he made his recommendation and
> >> > left.
> >> I'm still here, but I do have a job and a family. Rob, Robert and
> >> Chuck were making plenty of noise so I decided to reduce the clutter.
> >>
> >> > I'm coming to think that his advice was the best, namely, to just
> >> > live with the current situation as long as it is working.
> >> I gave no such advice. I think you should chase this down until you
> >> understand the cause and have it fixed.
> >>
> >> -chris
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Thanks for sharing the outcome. I'm glad you got to the bottom of it
properly.
On Sat, Aug 23, 2025, 16:52 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Robert, and all who have responded to my postings,
>
> You were correct! There was a memory leak.
>
> Robert suggested that I go back and take another look at the original
> version of my program. I did this and saw that I had been overlooking some
> exceptions that were being thrown. These were occasional one-liners, null
> pointer exceptions, somewhat buried in a lengthy log file. On digging
> deeper, I found that these were being thrown in a segment of the code that
> followed a connection-open statement, but before the corresponding
> connection-close statement, so the close statement was being skipped,
> thereby constituting a memory leak.
>
> The exceptions are being thrown by queries submitted by web crawlers,
> which by-pass the user interface and submit bogus requests; for example,
> asking for holidays information for a city called "Scotland". This invokes
> an internal table lookup (not a db query) that tries to return an ID for
> the city, and not finding one, it returns "null". This in turn causes a
> null pointer exception.
>
> This problem was indeed resolved either by using the try-with-resources
> construct or moving the db connection-close operation into a finally
> clause. Both of these seem to work. The exceptions are still being
> thrown, but the program keeps running with no memory leak.
>
> Thanks again to everyone for your comments. It's been very helpful, and I
> have learned a lot in the process.
>
> Dan
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Tuesday, August 19, 2025 8:27 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Daniel,
>
> If you would like to validate your theory, simply remove the
> try-with-resources and revert to your previous logic. However, I strongly
> believe your theory is completely incorrect and makes no sense to me at all.
>
> I'm glad it's working much better for you now. Best of luck,
>
> Robert
>
> On Tue, Aug 19, 2025 at 8:21 PM Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
> > Chuck, Robert, Chris,
> >
> > I believe that this issue is finally resolved. My system has been
> > running flawlessly for most of two days now with the minimum and
> > maximum pool sizes set to the defaults of 8 and 32 respectively. It is
> still getting frequent
> > hits by web crawlers and it is handling this with no problem. So I'm
> > prepared to just leave it at this.
> >
> > After all that has been said and done, I suspect that the problem all
> > along was that, after many months of running Glassfish with no
> > maintenance, the system developed some internal glitch that made it
> > create 250+ connection objects that weren't being removed. But when I
> > shut Glassfish down yesterday, deleted the .war file, and then
> > restarted it with an empty domain, it reset itself and resumed running
> > normally. Anyway, this is my speculation at this point.
> >
> > I did do a test today to see if the production version running on AWS
> > will report thrown exceptions and found that it does. As an
> > experiment I put the line "float something = 1/0;" in the method that
> > retrieves the list of countries and then ran my test query. It
> > retrieved the list of countries and output the expected "Other
> exception" message in the system.log file.
> > Based on this, I believe that the system was never throwing any
> > exceptions. There was some speculation that exceptions were being
> > "swallowed", i.e., being thrown without any reports, but this doesn't
> > seem to be happening. The fact that I have never seen any such
> > exception reports I take as confirmation that this was never the problem.
> >
> > Also, before I ran my test today, which required replacing the current
> > .war file with my test .war file, I checked the current contents of
> > the JDBC pooling monitor and saw that the number of connections
> > released equaled the number acquired, and the number of potential
> > leaks was still at zero. I take this as further confirmation that
> everything is now okay.
> >
> > I do appreciate your observation that my JDBC pool size was abnormally
> > high and that this was something that needed to be addressed. Whether
> > this had to do with my code changes or the issue I just described, I'm
> > thankful for everyone's efforts and that the issue now seems to be
> resolved.
> >
> > Best regards,
> >
> > Dan
> >
> > From: Chuck Caldarale <n8...@gmail.com>
> > Sent: Tuesday, August 19, 2025 1:33 AM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >
> > > On 2025 Aug 18, at 21:22, Daniel Schwartz <dan@danielgschwartz.com
> > <ma...@danielgschwartz.com>> wrote: > > I wasn't resisting using
> > the try-with-resources construct, only when I tried to do this, I was
> > getting compiler errors. But I evidently wasn't doing
> > NkdkJdXPPEBannerStart Be Careful With This Message From (Chuck
> > Caldarale <n8...@gmail.com>)<
> > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> > 465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f
> > 4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c22
> > 46118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d495
> > 3459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90e
> > b09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137
> > c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232c
> > cb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034
> > >
> > Learn More<
> > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> > 465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f
> > 4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c22
> > 46118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d495
> > 3459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90e
> > b09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137
> > c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232c
> > cb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034
> > >
> > 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 18, at 21:22, Daniel Schwartz <dan@danielgschwartz.com
> > <ma...@danielgschwartz.com>> wrote:
> >
> > >
> >
> > > I wasn't resisting using the try-with-resources construct, only when
> > > I
> > tried to do this, I was getting compiler errors. But I evidently
> > wasn't doing it right, because I tried it again and this time it worked.
> >
> > >
> >
> > > Following is the new code for getting the list of countries. It
> > > uses
> > this construct and in addition has an extra catch clause for any kind
> > of exception. I have done this in all six places where a connection
> > is being created.
> >
> > >
> >
> > > I restarted Glassfish earlier today and dropped in the new .war file.
> > It has been running for 6-8 hours now. The log files show no evidence
> > of any exceptions being thrown.
> >
> >
> >
> >
> >
> > When you’re running GlassFish in your production environment, is it
> > running as a service? If so, you’re not going to see anything written
> > via System.out (or System.err), unless GlassFish has an option to
> > redirect that to its internal logging mechanism. Tomcat has such an
> > option, and GlassFish started as a fork of Tomcat many years ago, so
> > such an option may well exist.
> >
> >
> >
> >
> >
> > > The current contents of the JDBC monitor page are copied below. I
> > > don't
> > know how to interpret most of this, but I do note that the number of
> > connections released equals the number acquired. Also, I have set the
> > Connection Leak Timeout to be 10 seconds, and the NumPotentialConnLeak
> > is still at 0.
> >
> >
> >
> >
> >
> > However, there are a couple of stats that might be a bit concerning:
> > of the 20 physical connections created, only 1 is free and 19 were
> destroyed.
> > I would think that a pool would destroy connections only when it had
> > to (eg, the connection is considered unsafe for reuse), although
> > GlassFish does appear to have a mode where it discards connections
> > after a while just in case. There’s also something odd with having
> > only 1 free connection, since the pool is supposed to maintain a
> > minimum of 8. Or were these statistics captured when the minimum was set
> to 1?
> >
> >
> >
> >
> >
> > > In addition, I did some further experimenting with the pool size,
> > > and
> > now I find that if I set the minimum back to 8 and the maximum to 32,
> > which are the defaults, the system keeps running and doesn't output
> > that "can't allocate more connections" message. For me this is very
> > puzzling. Did my code changes have anything to do with this?
> >
> >
> >
> >
> >
> > Not much else changed, so in all likelihood, yes. Note that the
> > highest number of connections concurrently used is just 2, which is
> > what we’d expect for an app like yours.
> >
> >
> >
> >
> >
> > > Anyway, my interpretation of all this is as before, that there are
> > > no
> > memory leaks. Is this correct?
> >
> >
> >
> >
> >
> > There don’t appear to be any with your revised code, at least up to
> > this point (other than perhaps those 19 destroyed connections), but
> > let it run for a few days and see what happens if the web crawlers
> > start feeding garbage to your web service again.
> >
> >
> >
> > - Chuck
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> > users-unsubscribe@tomcat.apache.org>
> >
> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> > users-help@tomcat.apache.org>
> >
> >
> >
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Robert, and all who have responded to my postings,
You were correct! There was a memory leak.
Robert suggested that I go back and take another look at the original version of my program. I did this and saw that I had been overlooking some exceptions that were being thrown. These were occasional one-liners, null pointer exceptions, somewhat buried in a lengthy log file. On digging deeper, I found that these were being thrown in a segment of the code that followed a connection-open statement, but before the corresponding connection-close statement, so the close statement was being skipped, thereby constituting a memory leak.
The exceptions are being thrown by queries submitted by web crawlers, which by-pass the user interface and submit bogus requests; for example, asking for holidays information for a city called "Scotland". This invokes an internal table lookup (not a db query) that tries to return an ID for the city, and not finding one, it returns "null". This in turn causes a null pointer exception.
This problem was indeed resolved either by using the try-with-resources construct or moving the db connection-close operation into a finally clause. Both of these seem to work. The exceptions are still being thrown, but the program keeps running with no memory leak.
Thanks again to everyone for your comments. It's been very helpful, and I have learned a lot in the process.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Tuesday, August 19, 2025 8:27 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Daniel,
If you would like to validate your theory, simply remove the try-with-resources and revert to your previous logic. However, I strongly believe your theory is completely incorrect and makes no sense to me at all.
I'm glad it's working much better for you now. Best of luck,
Robert
On Tue, Aug 19, 2025 at 8:21 PM Daniel Schwartz <da...@danielgschwartz.com>
wrote:
> Chuck, Robert, Chris,
>
> I believe that this issue is finally resolved. My system has been
> running flawlessly for most of two days now with the minimum and
> maximum pool sizes set to the defaults of 8 and 32 respectively. It is still getting frequent
> hits by web crawlers and it is handling this with no problem. So I'm
> prepared to just leave it at this.
>
> After all that has been said and done, I suspect that the problem all
> along was that, after many months of running Glassfish with no
> maintenance, the system developed some internal glitch that made it
> create 250+ connection objects that weren't being removed. But when I
> shut Glassfish down yesterday, deleted the .war file, and then
> restarted it with an empty domain, it reset itself and resumed running
> normally. Anyway, this is my speculation at this point.
>
> I did do a test today to see if the production version running on AWS
> will report thrown exceptions and found that it does. As an
> experiment I put the line "float something = 1/0;" in the method that
> retrieves the list of countries and then ran my test query. It
> retrieved the list of countries and output the expected "Other exception" message in the system.log file.
> Based on this, I believe that the system was never throwing any
> exceptions. There was some speculation that exceptions were being
> "swallowed", i.e., being thrown without any reports, but this doesn't
> seem to be happening. The fact that I have never seen any such
> exception reports I take as confirmation that this was never the problem.
>
> Also, before I ran my test today, which required replacing the current
> .war file with my test .war file, I checked the current contents of
> the JDBC pooling monitor and saw that the number of connections
> released equaled the number acquired, and the number of potential
> leaks was still at zero. I take this as further confirmation that everything is now okay.
>
> I do appreciate your observation that my JDBC pool size was abnormally
> high and that this was something that needed to be addressed. Whether
> this had to do with my code changes or the issue I just described, I'm
> thankful for everyone's efforts and that the issue now seems to be resolved.
>
> Best regards,
>
> Dan
>
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Tuesday, August 19, 2025 1:33 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> > On 2025 Aug 18, at 21:22, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote: > > I wasn't resisting using
> the try-with-resources construct, only when I tried to do this, I was
> getting compiler errors. But I evidently wasn't doing
> NkdkJdXPPEBannerStart Be Careful With This Message From (Chuck
> Caldarale <n8...@gmail.com>)<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f
> 4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c22
> 46118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d495
> 3459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90e
> b09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137
> c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232c
> cb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034
> >
> Learn More<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f
> 4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c22
> 46118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d495
> 3459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90e
> b09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137
> c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232c
> cb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034
> >
> 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 18, at 21:22, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote:
>
> >
>
> > I wasn't resisting using the try-with-resources construct, only when
> > I
> tried to do this, I was getting compiler errors. But I evidently
> wasn't doing it right, because I tried it again and this time it worked.
>
> >
>
> > Following is the new code for getting the list of countries. It
> > uses
> this construct and in addition has an extra catch clause for any kind
> of exception. I have done this in all six places where a connection
> is being created.
>
> >
>
> > I restarted Glassfish earlier today and dropped in the new .war file.
> It has been running for 6-8 hours now. The log files show no evidence
> of any exceptions being thrown.
>
>
>
>
>
> When you’re running GlassFish in your production environment, is it
> running as a service? If so, you’re not going to see anything written
> via System.out (or System.err), unless GlassFish has an option to
> redirect that to its internal logging mechanism. Tomcat has such an
> option, and GlassFish started as a fork of Tomcat many years ago, so
> such an option may well exist.
>
>
>
>
>
> > The current contents of the JDBC monitor page are copied below. I
> > don't
> know how to interpret most of this, but I do note that the number of
> connections released equals the number acquired. Also, I have set the
> Connection Leak Timeout to be 10 seconds, and the NumPotentialConnLeak
> is still at 0.
>
>
>
>
>
> However, there are a couple of stats that might be a bit concerning:
> of the 20 physical connections created, only 1 is free and 19 were destroyed.
> I would think that a pool would destroy connections only when it had
> to (eg, the connection is considered unsafe for reuse), although
> GlassFish does appear to have a mode where it discards connections
> after a while just in case. There’s also something odd with having
> only 1 free connection, since the pool is supposed to maintain a
> minimum of 8. Or were these statistics captured when the minimum was set to 1?
>
>
>
>
>
> > In addition, I did some further experimenting with the pool size,
> > and
> now I find that if I set the minimum back to 8 and the maximum to 32,
> which are the defaults, the system keeps running and doesn't output
> that "can't allocate more connections" message. For me this is very
> puzzling. Did my code changes have anything to do with this?
>
>
>
>
>
> Not much else changed, so in all likelihood, yes. Note that the
> highest number of connections concurrently used is just 2, which is
> what we’d expect for an app like yours.
>
>
>
>
>
> > Anyway, my interpretation of all this is as before, that there are
> > no
> memory leaks. Is this correct?
>
>
>
>
>
> There don’t appear to be any with your revised code, at least up to
> this point (other than perhaps those 19 destroyed connections), but
> let it run for a few days and see what happens if the web crawlers
> start feeding garbage to your web service again.
>
>
>
> - Chuck
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Robert,
I'm just speculating, and I might try your suggestion and see what happens. In any case, I agree that using try-with-resources makes sense, and I appreciate this advice. The net result of all this conversation is that my code is in a lot better shape than before.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Tuesday, August 19, 2025 8:27 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Daniel,
If you would like to validate your theory, simply remove the try-with-resources and revert to your previous logic. However, I strongly believe your theory is completely incorrect and makes no sense to me at all.
I'm glad it's working much better for you now. Best of luck,
Robert
On Tue, Aug 19, 2025 at 8:21 PM Daniel Schwartz <da...@danielgschwartz.com>
wrote:
> Chuck, Robert, Chris,
>
> I believe that this issue is finally resolved. My system has been
> running flawlessly for most of two days now with the minimum and
> maximum pool sizes set to the defaults of 8 and 32 respectively. It is still getting frequent
> hits by web crawlers and it is handling this with no problem. So I'm
> prepared to just leave it at this.
>
> After all that has been said and done, I suspect that the problem all
> along was that, after many months of running Glassfish with no
> maintenance, the system developed some internal glitch that made it
> create 250+ connection objects that weren't being removed. But when I
> shut Glassfish down yesterday, deleted the .war file, and then
> restarted it with an empty domain, it reset itself and resumed running
> normally. Anyway, this is my speculation at this point.
>
> I did do a test today to see if the production version running on AWS
> will report thrown exceptions and found that it does. As an
> experiment I put the line "float something = 1/0;" in the method that
> retrieves the list of countries and then ran my test query. It
> retrieved the list of countries and output the expected "Other exception" message in the system.log file.
> Based on this, I believe that the system was never throwing any
> exceptions. There was some speculation that exceptions were being
> "swallowed", i.e., being thrown without any reports, but this doesn't
> seem to be happening. The fact that I have never seen any such
> exception reports I take as confirmation that this was never the problem.
>
> Also, before I ran my test today, which required replacing the current
> .war file with my test .war file, I checked the current contents of
> the JDBC pooling monitor and saw that the number of connections
> released equaled the number acquired, and the number of potential
> leaks was still at zero. I take this as further confirmation that everything is now okay.
>
> I do appreciate your observation that my JDBC pool size was abnormally
> high and that this was something that needed to be addressed. Whether
> this had to do with my code changes or the issue I just described, I'm
> thankful for everyone's efforts and that the issue now seems to be resolved.
>
> Best regards,
>
> Dan
>
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Tuesday, August 19, 2025 1:33 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> > On 2025 Aug 18, at 21:22, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote: > > I wasn't resisting using
> the try-with-resources construct, only when I tried to do this, I was
> getting compiler errors. But I evidently wasn't doing
> NkdkJdXPPEBannerStart Be Careful With This Message From (Chuck
> Caldarale <n8...@gmail.com>)<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f
> 4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c22
> 46118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d495
> 3459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90e
> b09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137
> c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232c
> cb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034
> >
> Learn More<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f
> 4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c22
> 46118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d495
> 3459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90e
> b09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137
> c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232c
> cb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034
> >
> 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 18, at 21:22, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote:
>
> >
>
> > I wasn't resisting using the try-with-resources construct, only when
> > I
> tried to do this, I was getting compiler errors. But I evidently
> wasn't doing it right, because I tried it again and this time it worked.
>
> >
>
> > Following is the new code for getting the list of countries. It
> > uses
> this construct and in addition has an extra catch clause for any kind
> of exception. I have done this in all six places where a connection
> is being created.
>
> >
>
> > I restarted Glassfish earlier today and dropped in the new .war file.
> It has been running for 6-8 hours now. The log files show no evidence
> of any exceptions being thrown.
>
>
>
>
>
> When you’re running GlassFish in your production environment, is it
> running as a service? If so, you’re not going to see anything written
> via System.out (or System.err), unless GlassFish has an option to
> redirect that to its internal logging mechanism. Tomcat has such an
> option, and GlassFish started as a fork of Tomcat many years ago, so
> such an option may well exist.
>
>
>
>
>
> > The current contents of the JDBC monitor page are copied below. I
> > don't
> know how to interpret most of this, but I do note that the number of
> connections released equals the number acquired. Also, I have set the
> Connection Leak Timeout to be 10 seconds, and the NumPotentialConnLeak
> is still at 0.
>
>
>
>
>
> However, there are a couple of stats that might be a bit concerning:
> of the 20 physical connections created, only 1 is free and 19 were destroyed.
> I would think that a pool would destroy connections only when it had
> to (eg, the connection is considered unsafe for reuse), although
> GlassFish does appear to have a mode where it discards connections
> after a while just in case. There’s also something odd with having
> only 1 free connection, since the pool is supposed to maintain a
> minimum of 8. Or were these statistics captured when the minimum was set to 1?
>
>
>
>
>
> > In addition, I did some further experimenting with the pool size,
> > and
> now I find that if I set the minimum back to 8 and the maximum to 32,
> which are the defaults, the system keeps running and doesn't output
> that "can't allocate more connections" message. For me this is very
> puzzling. Did my code changes have anything to do with this?
>
>
>
>
>
> Not much else changed, so in all likelihood, yes. Note that the
> highest number of connections concurrently used is just 2, which is
> what we’d expect for an app like yours.
>
>
>
>
>
> > Anyway, my interpretation of all this is as before, that there are
> > no
> memory leaks. Is this correct?
>
>
>
>
>
> There don’t appear to be any with your revised code, at least up to
> this point (other than perhaps those 19 destroyed connections), but
> let it run for a few days and see what happens if the web crawlers
> start feeding garbage to your web service again.
>
>
>
> - Chuck
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Daniel,
If you would like to validate your theory, simply remove the
try-with-resources and revert to your previous logic. However, I strongly
believe your theory is completely incorrect and makes no sense to me at all.
I'm glad it's working much better for you now. Best of luck,
Robert
On Tue, Aug 19, 2025 at 8:21 PM Daniel Schwartz <da...@danielgschwartz.com>
wrote:
> Chuck, Robert, Chris,
>
> I believe that this issue is finally resolved. My system has been running
> flawlessly for most of two days now with the minimum and maximum pool sizes
> set to the defaults of 8 and 32 respectively. It is still getting frequent
> hits by web crawlers and it is handling this with no problem. So I'm
> prepared to just leave it at this.
>
> After all that has been said and done, I suspect that the problem all
> along was that, after many months of running Glassfish with no maintenance,
> the system developed some internal glitch that made it create 250+
> connection objects that weren't being removed. But when I shut Glassfish
> down yesterday, deleted the .war file, and then restarted it with an empty
> domain, it reset itself and resumed running normally. Anyway, this is my
> speculation at this point.
>
> I did do a test today to see if the production version running on AWS will
> report thrown exceptions and found that it does. As an experiment I put
> the line "float something = 1/0;" in the method that retrieves the list of
> countries and then ran my test query. It retrieved the list of countries
> and output the expected "Other exception" message in the system.log file.
> Based on this, I believe that the system was never throwing any
> exceptions. There was some speculation that exceptions were being
> "swallowed", i.e., being thrown without any reports, but this doesn't seem
> to be happening. The fact that I have never seen any such exception
> reports I take as confirmation that this was never the problem.
>
> Also, before I ran my test today, which required replacing the current
> .war file with my test .war file, I checked the current contents of the
> JDBC pooling monitor and saw that the number of connections released
> equaled the number acquired, and the number of potential leaks was still at
> zero. I take this as further confirmation that everything is now okay.
>
> I do appreciate your observation that my JDBC pool size was abnormally
> high and that this was something that needed to be addressed. Whether this
> had to do with my code changes or the issue I just described, I'm thankful
> for everyone's efforts and that the issue now seems to be resolved.
>
> Best regards,
>
> Dan
>
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Tuesday, August 19, 2025 1:33 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> > On 2025 Aug 18, at 21:22, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote: > > I wasn't resisting using the
> try-with-resources construct, only when I tried to do this, I was getting
> compiler errors. But I evidently wasn't doing
> NkdkJdXPPEBannerStart
> Be Careful With This Message
> From (Chuck Caldarale <n8...@gmail.com>)<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c2246118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d4953459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90eb09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232ccb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034
> >
> Learn More<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c2246118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d4953459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90eb09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232ccb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034
> >
> 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 18, at 21:22, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote:
>
> >
>
> > I wasn't resisting using the try-with-resources construct, only when I
> tried to do this, I was getting compiler errors. But I evidently wasn't
> doing it right, because I tried it again and this time it worked.
>
> >
>
> > Following is the new code for getting the list of countries. It uses
> this construct and in addition has an extra catch clause for any kind of
> exception. I have done this in all six places where a connection is being
> created.
>
> >
>
> > I restarted Glassfish earlier today and dropped in the new .war file.
> It has been running for 6-8 hours now. The log files show no evidence of
> any exceptions being thrown.
>
>
>
>
>
> When you’re running GlassFish in your production environment, is it
> running as a service? If so, you’re not going to see anything written via
> System.out (or System.err), unless GlassFish has an option to redirect that
> to its internal logging mechanism. Tomcat has such an option, and GlassFish
> started as a fork of Tomcat many years ago, so such an option may well
> exist.
>
>
>
>
>
> > The current contents of the JDBC monitor page are copied below. I don't
> know how to interpret most of this, but I do note that the number of
> connections released equals the number acquired. Also, I have set the
> Connection Leak Timeout to be 10 seconds, and the NumPotentialConnLeak is
> still at 0.
>
>
>
>
>
> However, there are a couple of stats that might be a bit concerning: of
> the 20 physical connections created, only 1 is free and 19 were destroyed.
> I would think that a pool would destroy connections only when it had to
> (eg, the connection is considered unsafe for reuse), although GlassFish
> does appear to have a mode where it discards connections after a while just
> in case. There’s also something odd with having only 1 free connection,
> since the pool is supposed to maintain a minimum of 8. Or were these
> statistics captured when the minimum was set to 1?
>
>
>
>
>
> > In addition, I did some further experimenting with the pool size, and
> now I find that if I set the minimum back to 8 and the maximum to 32, which
> are the defaults, the system keeps running and doesn't output that "can't
> allocate more connections" message. For me this is very puzzling. Did my
> code changes have anything to do with this?
>
>
>
>
>
> Not much else changed, so in all likelihood, yes. Note that the highest
> number of connections concurrently used is just 2, which is what we’d
> expect for an app like yours.
>
>
>
>
>
> > Anyway, my interpretation of all this is as before, that there are no
> memory leaks. Is this correct?
>
>
>
>
>
> There don’t appear to be any with your revised code, at least up to this
> point (other than perhaps those 19 destroyed connections), but let it run
> for a few days and see what happens if the web crawlers start feeding
> garbage to your web service again.
>
>
>
> - Chuck
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chuck, Robert, Chris,
I believe that this issue is finally resolved. My system has been running flawlessly for most of two days now with the minimum and maximum pool sizes set to the defaults of 8 and 32 respectively. It is still getting frequent hits by web crawlers and it is handling this with no problem. So I'm prepared to just leave it at this.
After all that has been said and done, I suspect that the problem all along was that, after many months of running Glassfish with no maintenance, the system developed some internal glitch that made it create 250+ connection objects that weren't being removed. But when I shut Glassfish down yesterday, deleted the .war file, and then restarted it with an empty domain, it reset itself and resumed running normally. Anyway, this is my speculation at this point.
I did do a test today to see if the production version running on AWS will report thrown exceptions and found that it does. As an experiment I put the line "float something = 1/0;" in the method that retrieves the list of countries and then ran my test query. It retrieved the list of countries and output the expected "Other exception" message in the system.log file. Based on this, I believe that the system was never throwing any exceptions. There was some speculation that exceptions were being "swallowed", i.e., being thrown without any reports, but this doesn't seem to be happening. The fact that I have never seen any such exception reports I take as confirmation that this was never the problem.
Also, before I ran my test today, which required replacing the current .war file with my test .war file, I checked the current contents of the JDBC pooling monitor and saw that the number of connections released equaled the number acquired, and the number of potential leaks was still at zero. I take this as further confirmation that everything is now okay.
I do appreciate your observation that my JDBC pool size was abnormally high and that this was something that needed to be addressed. Whether this had to do with my code changes or the issue I just described, I'm thankful for everyone's efforts and that the issue now seems to be resolved.
Best regards,
Dan
From: Chuck Caldarale <n8...@gmail.com>
Sent: Tuesday, August 19, 2025 1:33 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 18, at 21:22, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > I wasn't resisting using the try-with-resources construct, only when I tried to do this, I was getting compiler errors. But I evidently wasn't doing
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c2246118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d4953459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90eb09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232ccb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f51a287f6939989554348daf64676e0bf5f4ffa1456b85165104baabd11d2f4f5bc0540d6b7871afb306ea1aca1c07fdba45a24a58aaaf383c3a1273ce3b65804c2246118bcb75f9a17caf373b92d7f2d854d41c3082963c5f125ae63845f041a91581d4953459459aa2c4234a2139a28123b2078ebbe1692068d6901194786f9343be17d758d90eb09e3dae7ff54cd3793b11432fdf9d37bd8db5d655c3c25c0886896cda9112c4fb9137c2d65eecb0c1a06af06bf9910a86cefb6cb06aeddf8c5b5c98eb750cbd2d035efc232ccb97a5a636e0ea51701e39e165cf615cbe618288fc0f3b7969034>
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 18, at 21:22, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> I wasn't resisting using the try-with-resources construct, only when I tried to do this, I was getting compiler errors. But I evidently wasn't doing it right, because I tried it again and this time it worked.
>
> Following is the new code for getting the list of countries. It uses this construct and in addition has an extra catch clause for any kind of exception. I have done this in all six places where a connection is being created.
>
> I restarted Glassfish earlier today and dropped in the new .war file. It has been running for 6-8 hours now. The log files show no evidence of any exceptions being thrown.
When you’re running GlassFish in your production environment, is it running as a service? If so, you’re not going to see anything written via System.out (or System.err), unless GlassFish has an option to redirect that to its internal logging mechanism. Tomcat has such an option, and GlassFish started as a fork of Tomcat many years ago, so such an option may well exist.
> The current contents of the JDBC monitor page are copied below. I don't know how to interpret most of this, but I do note that the number of connections released equals the number acquired. Also, I have set the Connection Leak Timeout to be 10 seconds, and the NumPotentialConnLeak is still at 0.
However, there are a couple of stats that might be a bit concerning: of the 20 physical connections created, only 1 is free and 19 were destroyed. I would think that a pool would destroy connections only when it had to (eg, the connection is considered unsafe for reuse), although GlassFish does appear to have a mode where it discards connections after a while just in case. There’s also something odd with having only 1 free connection, since the pool is supposed to maintain a minimum of 8. Or were these statistics captured when the minimum was set to 1?
> In addition, I did some further experimenting with the pool size, and now I find that if I set the minimum back to 8 and the maximum to 32, which are the defaults, the system keeps running and doesn't output that "can't allocate more connections" message. For me this is very puzzling. Did my code changes have anything to do with this?
Not much else changed, so in all likelihood, yes. Note that the highest number of connections concurrently used is just 2, which is what we’d expect for an app like yours.
> Anyway, my interpretation of all this is as before, that there are no memory leaks. Is this correct?
There don’t appear to be any with your revised code, at least up to this point (other than perhaps those 19 destroyed connections), but let it run for a few days and see what happens if the web crawlers start feeding garbage to your web service again.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 18, at 21:22, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> I wasn't resisting using the try-with-resources construct, only when I tried to do this, I was getting compiler errors. But I evidently wasn't doing it right, because I tried it again and this time it worked.
>
> Following is the new code for getting the list of countries. It uses this construct and in addition has an extra catch clause for any kind of exception. I have done this in all six places where a connection is being created.
>
> I restarted Glassfish earlier today and dropped in the new .war file. It has been running for 6-8 hours now. The log files show no evidence of any exceptions being thrown.
When you’re running GlassFish in your production environment, is it running as a service? If so, you’re not going to see anything written via System.out (or System.err), unless GlassFish has an option to redirect that to its internal logging mechanism. Tomcat has such an option, and GlassFish started as a fork of Tomcat many years ago, so such an option may well exist.
> The current contents of the JDBC monitor page are copied below. I don't know how to interpret most of this, but I do note that the number of connections released equals the number acquired. Also, I have set the Connection Leak Timeout to be 10 seconds, and the NumPotentialConnLeak is still at 0.
However, there are a couple of stats that might be a bit concerning: of the 20 physical connections created, only 1 is free and 19 were destroyed. I would think that a pool would destroy connections only when it had to (eg, the connection is considered unsafe for reuse), although GlassFish does appear to have a mode where it discards connections after a while just in case. There’s also something odd with having only 1 free connection, since the pool is supposed to maintain a minimum of 8. Or were these statistics captured when the minimum was set to 1?
> In addition, I did some further experimenting with the pool size, and now I find that if I set the minimum back to 8 and the maximum to 32, which are the defaults, the system keeps running and doesn't output that "can't allocate more connections" message. For me this is very puzzling. Did my code changes have anything to do with this?
Not much else changed, so in all likelihood, yes. Note that the highest number of connections concurrently used is just 2, which is what we’d expect for an app like yours.
> Anyway, my interpretation of all this is as before, that there are no memory leaks. Is this correct?
There don’t appear to be any with your revised code, at least up to this point (other than perhaps those 19 destroyed connections), but let it run for a few days and see what happens if the web crawlers start feeding garbage to your web service again.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Btw, Hantsy, this is not helpful to this thread and only introduces more
things to learn that aren't part of the problem the OP is trying to solve.
On Mon, Aug 18, 2025, 22:44 hantsy bai <ha...@gmail.com> wrote:
> When using Glassfish you can define your own DataSource
> via @DataSourceDefinition, and inject it via @Resource annotation, which is
> supported since Java EE 7.
>
> For example,
>
> @DataSourceDefinition(name="jndiname here", .....)
> @ApplicaitonScoped
> class DatabaseConfig{}
>
> use it like this,
> @Resource(lookup="jndi name") DataSource ds
>
> More simply, since Java EE 7, default resources are available for
> DataSource, JMS etc.
>
> You can inject the default DataSource directly via
>
> @Resource DataSource datasource
>
> ---
>
> Regards,
>
> *Hantsy Bai*
>
> Self-employed consultant, fullstack developer, agile coach,
> freelancer/remote worker
>
> GitHub: https://github.com/hantsy
>
> Twitter: https://twitter.com/@hantsy
> Medium: https://medium.com/@hantsy
>
>
> On Tue, Aug 19, 2025 at 10:23 AM Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
> > Everyone,
> >
> > I wasn't resisting using the try-with-resources construct, only when I
> > tried to do this, I was getting compiler errors. But I evidently wasn't
> > doing it right, because I tried it again and this time it worked.
> >
> > Following is the new code for getting the list of countries. It uses
> this
> > construct and in addition has an extra catch clause for any kind of
> > exception. I have done this in all six places where a connection is
> being
> > created.
> >
> > I restarted Glassfish earlier today and dropped in the new .war file. It
> > has been running for 6-8 hours now. The log files show no evidence of
> any
> > exceptions being thrown. The current contents of the JDBC monitor page
> are
> > copied below. I don't know how to interpret most of this, but I do note
> > that the number of connections released equals the number acquired.
> Also,
> > I have set the Connection Leak Timeout to be 10 seconds, and the
> > NumPotentialConnLeak is still at 0.
> >
> > In addition, I did some further experimenting with the pool size, and now
> > I find that if I set the minimum back to 8 and the maximum to 32, which
> are
> > the defaults, the system keeps running and doesn't output that "can't
> > allocate more connections" message. For me this is very puzzling. Did
> my
> > code changes have anything to do with this?
> >
> > Anyway, my interpretation of all this is as before, that there are no
> > memory leaks. Is this correct?
> >
> > I'm trying to upgrade to the current version of Glassfish, but haven't
> > gotten this working yet.
> >
> > Dan
> >
> >
> >
> -----------------------------------------------------------------------------
> > @Path("holidaysandevents")
> > public class HolidaysRESTJSONResource {
> >
> > @Context
> > private UriInfo context;
> >
> > DataSource dataSource;
> >
> > public HolidaysRESTJSONResource() {
> > dataSource = DataSourceSingleton.getInstance().dataSource;
> > }
> >
> > @GET
> > @Path("/countries")
> > @Produces(MediaType.APPLICATION_JSON)
> > public String getJsonCountries() {
> > if (TempDataStorage.countryList == null) {
> > // Connection connection = null;
> > try (Connection connection = dataSource.getConnection()){
> > // connection = dataSource.getConnection();
> > TempDataStorage.countryList =
> > GetCountryList.doIt(connection);
> > } catch (SQLException e) {
> > System.out.println("Sql Exception" + e.getStackTrace());
> > } catch (Exception e) {
> > System.out.println("Other Exception" +
> e.getStackTrace());
> > }
> >
> > //finally {
> > // if (connection != null) {
> > // try {
> > // connection.close();
> > // } catch (SQLException e) {
> > // System.out.println(e.getStackTrace());
> > // }
> > // }
> > // }
> > }
> > StringListWrapper listWrapper = new StringListWrapper();
> > listWrapper.setTheList(TempDataStorage.countryList);
> > return new Gson().toJson(listWrapper);
> > }
> >
> >
> ---------------------------------------------------------------------------------
> > Resource Monitoring
> > Click Configure Monitoring and enable monitoring for a component or
> > service by selecting either LOW or HIGH. See the Online Help for more
> > information.
> >
> > Instance Name:
> > server
> >
> > Resource :
> > HolidaysConnectionPool
> > Application :
> > Monitor (14 Statistics)
> > Collapse Group JDBC Connection Pool Statistics : HolidaysConnectionPool
> >
> > NumConnCreated 20 count Aug 18, 2025 5:47:56 PM Aug 19, 2025
> > 12:37:57 AM -- The number of physical connections that were
> > created since the last reset.
> > NumConnFree 1count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM
> > High Water Mark: 3 count
> > Low Water Mark: 0 count
> > The total number of free connections in the pool as of the last sampling.
> > NumConnReleased 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025
> > 1:48:33 AM -- Number of logical connections released to the pool.
> > NumPotentialConnLeak 0 count Aug 18, 2025 5:47:56 PM -- --
> > Number of potential connection leaks
> > NumConnFailedValidation 0 count Aug 18, 2025 5:47:56 PM -- --
> > The total number of connections in the connection pool that failed
> > validation from the start time until the last sample time.
> > ConnRequestWaitTime 0millisecond Aug 18, 2025 5:47:56 PM Aug 19,
> > 2025 1:48:33 AM High Water Mark: 921 millisecond
> > Low Water Mark: 0 millisecond
> > The longest and shortest wait times of connection requests. The current
> > value indicates the wait time of the last request that was serviced by
> the
> > pool.
> > NumConnAcquired 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025
> > 1:48:33 AM -- Number of logical connections acquired from the pool.
> > AverageConnWaitTime 12 millisecond Aug 18, 2025 5:47:56 PM Aug 19,
> > 2025 1:49:00 AM -- Average wait-time-duration per successful
> > connection request
> > NumConnDestroyed 19 count Aug 18, 2025 5:47:56 PM Aug 19,
> > 2025 12:37:57 AM -- Number of physical connections that were
> > destroyed since the last reset.
> > NumConnSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM --
> > -- Number of connections succesfully matched
> > NumConnNotSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM --
> > -- Number of connections rejected during matching
> > NumConnUsed 0count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM
> > High Water Mark: 2 count
> > Low Water Mark: 0 count
> > Provides connection usage statistics. The total number of connections
> that
> > are currently being used, as well as information about the maximum number
> > of connections that were used (the high water mark).
> > WaitQueueLength 0 count Aug 18, 2025 5:47:56 PM -- -- Number of
> > connection requests in the queue waiting to be serviced.
> > NumConnTimedOut 0 count Aug 18, 2025 5:47:56 PM -- -- The total
> > number of connections in the pool that timed out between the start time
> and
> > the last sample time.
> >
> > -----Original Message-----
> > From: Robert Turner <rt...@e-djuster.ca.INVALID>
> > Sent: Monday, August 18, 2025 11:13 AM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >
> > For instance, what happens when the year parameter for the "calender"
> > request is not a number?
> > Or if parameters are missing?
> > Have you tested these situations?
> >
> > On Mon, Aug 18, 2025 at 10:52 AM Robert Turner <rt...@e-djuster.ca>
> > wrote:
> >
> > > Daniel,
> > >
> > > You have a leak - this we are certain of. You just don't yet know what
> > > causes it (it's clearly not a "standard use case" and the robots are
> > > likely triggering it).
> > >
> > > If I have my bets it is an unhandled unchecked exception (I'd even
> > > guess that it is likely a NumberFormatException) while processing one
> > > of your operations. Since you are reluctant to move your code to
> > > "try-with-resources" handling of the resource objects (which would
> > > make the code easier to read and avoid this problem), you will
> > > continue to see the problem unless you ensure that you are catching all
> > exceptions (e.g.
> > > Throwable) (which is a bad practice in general).
> > >
> > > The 388 connection cound is the existing leaked connections from
> > > previous operations since you last started the Glassfish server and
> > > pool. I did suggest you restart Glassfish after adjusting that
> > > parameter to reset the numbers and the systems.
> > >
> > > From my testing, I am very confident that the different versions will
> > > not behave differently in the context of your application.
> > >
> > > Please have some confidence that we do know what we are talking about.
> > > Your problem is common and not unique.
> > >
> > > If I get some time, and with your permission, I might try to look at
> > > your server operations and see if I can trigger it for you... but if
> > > you share the code for all the operations (no need to share the DB
> > > queries, just the Java code), I bet we can find it quickly. However,
> > > us solving it for you avoids you benefiting from the learning
> experience.
> > >
> > > Robert
> > >
> > >
> > > On Mon, Aug 18, 2025 at 10:44 AM Daniel Schwartz
> > > <da...@danielgschwartz.com>
> > > wrote:
> > >
> > >> Chris,
> > >>
> > >> I thought it was you. I too have a job and family, and this is only
> > >> a side project, so my time also is limited.
> > >>
> > >> Anyway, I'm wondering if there really is a problem, or whether this
> > >> is just normal Glassfish behavior. Yesterday I changed the Glassfish
> > >> settings so that leak monitoring is activated, and today I got:
> > >>
> > >> NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- --
> > >> Number of potential connection leaks
> > >>
> > >> Also, this value:
> > >>
> > >> NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 18, 2025
> > >> 2:34:54 PM High Water Mark: 390 count Low Water Mark: 0 count
> > >> Provides connection usage statistics. The total number of connections
> > >> that are currently being used, as well as information about the
> > >> maximum number of connections that were used (the high water mark).
> > >>
> > >> Has remained unchanged at 388.
> > >>
> > >> There has been suspicion that my system has a memory leak, but all
> > >> indications are that this is not happening.
> > >>
> > >> I'm currently trying to upgrade to the current version of Glassfish
> > >> to see if this behaves differently, but haven't gotten it working yet.
> > >>
> > >> Dan
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Christopher Schultz <ch...@christopherschultz.net>
> > >> Sent: Monday, August 18, 2025 10:29 AM
> > >> To: users@tomcat.apache.org
> > >> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> > >>
> > >> Daniel,
> > >>
> > >> On 8/16/25 10:57 PM, Daniel Schwartz wrote:
> > >> > There was a Chris too, but I think he made his recommendation and
> > >> > left.
> > >> I'm still here, but I do have a job and a family. Rob, Robert and
> > >> Chuck were making plenty of noise so I decided to reduce the clutter.
> > >>
> > >> > I'm coming to think that his advice was the best, namely, to just
> > >> > live with the current situation as long as it is working.
> > >> I gave no such advice. I think you should chase this down until you
> > >> understand the cause and have it fixed.
> > >>
> > >> -chris
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: users-help@tomcat.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by hantsy bai <ha...@gmail.com>.
When using Glassfish you can define your own DataSource
via @DataSourceDefinition, and inject it via @Resource annotation, which is
supported since Java EE 7.
For example,
@DataSourceDefinition(name="jndiname here", .....)
@ApplicaitonScoped
class DatabaseConfig{}
use it like this,
@Resource(lookup="jndi name") DataSource ds
More simply, since Java EE 7, default resources are available for
DataSource, JMS etc.
You can inject the default DataSource directly via
@Resource DataSource datasource
---
Regards,
*Hantsy Bai*
Self-employed consultant, fullstack developer, agile coach,
freelancer/remote worker
GitHub: https://github.com/hantsy
Twitter: https://twitter.com/@hantsy
Medium: https://medium.com/@hantsy
On Tue, Aug 19, 2025 at 10:23 AM Daniel Schwartz <da...@danielgschwartz.com>
wrote:
> Everyone,
>
> I wasn't resisting using the try-with-resources construct, only when I
> tried to do this, I was getting compiler errors. But I evidently wasn't
> doing it right, because I tried it again and this time it worked.
>
> Following is the new code for getting the list of countries. It uses this
> construct and in addition has an extra catch clause for any kind of
> exception. I have done this in all six places where a connection is being
> created.
>
> I restarted Glassfish earlier today and dropped in the new .war file. It
> has been running for 6-8 hours now. The log files show no evidence of any
> exceptions being thrown. The current contents of the JDBC monitor page are
> copied below. I don't know how to interpret most of this, but I do note
> that the number of connections released equals the number acquired. Also,
> I have set the Connection Leak Timeout to be 10 seconds, and the
> NumPotentialConnLeak is still at 0.
>
> In addition, I did some further experimenting with the pool size, and now
> I find that if I set the minimum back to 8 and the maximum to 32, which are
> the defaults, the system keeps running and doesn't output that "can't
> allocate more connections" message. For me this is very puzzling. Did my
> code changes have anything to do with this?
>
> Anyway, my interpretation of all this is as before, that there are no
> memory leaks. Is this correct?
>
> I'm trying to upgrade to the current version of Glassfish, but haven't
> gotten this working yet.
>
> Dan
>
>
> -----------------------------------------------------------------------------
> @Path("holidaysandevents")
> public class HolidaysRESTJSONResource {
>
> @Context
> private UriInfo context;
>
> DataSource dataSource;
>
> public HolidaysRESTJSONResource() {
> dataSource = DataSourceSingleton.getInstance().dataSource;
> }
>
> @GET
> @Path("/countries")
> @Produces(MediaType.APPLICATION_JSON)
> public String getJsonCountries() {
> if (TempDataStorage.countryList == null) {
> // Connection connection = null;
> try (Connection connection = dataSource.getConnection()){
> // connection = dataSource.getConnection();
> TempDataStorage.countryList =
> GetCountryList.doIt(connection);
> } catch (SQLException e) {
> System.out.println("Sql Exception" + e.getStackTrace());
> } catch (Exception e) {
> System.out.println("Other Exception" + e.getStackTrace());
> }
>
> //finally {
> // if (connection != null) {
> // try {
> // connection.close();
> // } catch (SQLException e) {
> // System.out.println(e.getStackTrace());
> // }
> // }
> // }
> }
> StringListWrapper listWrapper = new StringListWrapper();
> listWrapper.setTheList(TempDataStorage.countryList);
> return new Gson().toJson(listWrapper);
> }
>
> ---------------------------------------------------------------------------------
> Resource Monitoring
> Click Configure Monitoring and enable monitoring for a component or
> service by selecting either LOW or HIGH. See the Online Help for more
> information.
>
> Instance Name:
> server
>
> Resource :
> HolidaysConnectionPool
> Application :
> Monitor (14 Statistics)
> Collapse Group JDBC Connection Pool Statistics : HolidaysConnectionPool
>
> NumConnCreated 20 count Aug 18, 2025 5:47:56 PM Aug 19, 2025
> 12:37:57 AM -- The number of physical connections that were
> created since the last reset.
> NumConnFree 1count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM
> High Water Mark: 3 count
> Low Water Mark: 0 count
> The total number of free connections in the pool as of the last sampling.
> NumConnReleased 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025
> 1:48:33 AM -- Number of logical connections released to the pool.
> NumPotentialConnLeak 0 count Aug 18, 2025 5:47:56 PM -- --
> Number of potential connection leaks
> NumConnFailedValidation 0 count Aug 18, 2025 5:47:56 PM -- --
> The total number of connections in the connection pool that failed
> validation from the start time until the last sample time.
> ConnRequestWaitTime 0millisecond Aug 18, 2025 5:47:56 PM Aug 19,
> 2025 1:48:33 AM High Water Mark: 921 millisecond
> Low Water Mark: 0 millisecond
> The longest and shortest wait times of connection requests. The current
> value indicates the wait time of the last request that was serviced by the
> pool.
> NumConnAcquired 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025
> 1:48:33 AM -- Number of logical connections acquired from the pool.
> AverageConnWaitTime 12 millisecond Aug 18, 2025 5:47:56 PM Aug 19,
> 2025 1:49:00 AM -- Average wait-time-duration per successful
> connection request
> NumConnDestroyed 19 count Aug 18, 2025 5:47:56 PM Aug 19,
> 2025 12:37:57 AM -- Number of physical connections that were
> destroyed since the last reset.
> NumConnSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM --
> -- Number of connections succesfully matched
> NumConnNotSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM --
> -- Number of connections rejected during matching
> NumConnUsed 0count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM
> High Water Mark: 2 count
> Low Water Mark: 0 count
> Provides connection usage statistics. The total number of connections that
> are currently being used, as well as information about the maximum number
> of connections that were used (the high water mark).
> WaitQueueLength 0 count Aug 18, 2025 5:47:56 PM -- -- Number of
> connection requests in the queue waiting to be serviced.
> NumConnTimedOut 0 count Aug 18, 2025 5:47:56 PM -- -- The total
> number of connections in the pool that timed out between the start time and
> the last sample time.
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Monday, August 18, 2025 11:13 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> For instance, what happens when the year parameter for the "calender"
> request is not a number?
> Or if parameters are missing?
> Have you tested these situations?
>
> On Mon, Aug 18, 2025 at 10:52 AM Robert Turner <rt...@e-djuster.ca>
> wrote:
>
> > Daniel,
> >
> > You have a leak - this we are certain of. You just don't yet know what
> > causes it (it's clearly not a "standard use case" and the robots are
> > likely triggering it).
> >
> > If I have my bets it is an unhandled unchecked exception (I'd even
> > guess that it is likely a NumberFormatException) while processing one
> > of your operations. Since you are reluctant to move your code to
> > "try-with-resources" handling of the resource objects (which would
> > make the code easier to read and avoid this problem), you will
> > continue to see the problem unless you ensure that you are catching all
> exceptions (e.g.
> > Throwable) (which is a bad practice in general).
> >
> > The 388 connection cound is the existing leaked connections from
> > previous operations since you last started the Glassfish server and
> > pool. I did suggest you restart Glassfish after adjusting that
> > parameter to reset the numbers and the systems.
> >
> > From my testing, I am very confident that the different versions will
> > not behave differently in the context of your application.
> >
> > Please have some confidence that we do know what we are talking about.
> > Your problem is common and not unique.
> >
> > If I get some time, and with your permission, I might try to look at
> > your server operations and see if I can trigger it for you... but if
> > you share the code for all the operations (no need to share the DB
> > queries, just the Java code), I bet we can find it quickly. However,
> > us solving it for you avoids you benefiting from the learning experience.
> >
> > Robert
> >
> >
> > On Mon, Aug 18, 2025 at 10:44 AM Daniel Schwartz
> > <da...@danielgschwartz.com>
> > wrote:
> >
> >> Chris,
> >>
> >> I thought it was you. I too have a job and family, and this is only
> >> a side project, so my time also is limited.
> >>
> >> Anyway, I'm wondering if there really is a problem, or whether this
> >> is just normal Glassfish behavior. Yesterday I changed the Glassfish
> >> settings so that leak monitoring is activated, and today I got:
> >>
> >> NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- --
> >> Number of potential connection leaks
> >>
> >> Also, this value:
> >>
> >> NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 18, 2025
> >> 2:34:54 PM High Water Mark: 390 count Low Water Mark: 0 count
> >> Provides connection usage statistics. The total number of connections
> >> that are currently being used, as well as information about the
> >> maximum number of connections that were used (the high water mark).
> >>
> >> Has remained unchanged at 388.
> >>
> >> There has been suspicion that my system has a memory leak, but all
> >> indications are that this is not happening.
> >>
> >> I'm currently trying to upgrade to the current version of Glassfish
> >> to see if this behaves differently, but haven't gotten it working yet.
> >>
> >> Dan
> >>
> >>
> >> -----Original Message-----
> >> From: Christopher Schultz <ch...@christopherschultz.net>
> >> Sent: Monday, August 18, 2025 10:29 AM
> >> To: users@tomcat.apache.org
> >> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >>
> >> Daniel,
> >>
> >> On 8/16/25 10:57 PM, Daniel Schwartz wrote:
> >> > There was a Chris too, but I think he made his recommendation and
> >> > left.
> >> I'm still here, but I do have a job and a family. Rob, Robert and
> >> Chuck were making plenty of noise so I decided to reduce the clutter.
> >>
> >> > I'm coming to think that his advice was the best, namely, to just
> >> > live with the current situation as long as it is working.
> >> I gave no such advice. I think you should chase this down until you
> >> understand the cause and have it fixed.
> >>
> >> -chris
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Everyone,
I wasn't resisting using the try-with-resources construct, only when I tried to do this, I was getting compiler errors. But I evidently wasn't doing it right, because I tried it again and this time it worked.
Following is the new code for getting the list of countries. It uses this construct and in addition has an extra catch clause for any kind of exception. I have done this in all six places where a connection is being created.
I restarted Glassfish earlier today and dropped in the new .war file. It has been running for 6-8 hours now. The log files show no evidence of any exceptions being thrown. The current contents of the JDBC monitor page are copied below. I don't know how to interpret most of this, but I do note that the number of connections released equals the number acquired. Also, I have set the Connection Leak Timeout to be 10 seconds, and the NumPotentialConnLeak is still at 0.
In addition, I did some further experimenting with the pool size, and now I find that if I set the minimum back to 8 and the maximum to 32, which are the defaults, the system keeps running and doesn't output that "can't allocate more connections" message. For me this is very puzzling. Did my code changes have anything to do with this?
Anyway, my interpretation of all this is as before, that there are no memory leaks. Is this correct?
I'm trying to upgrade to the current version of Glassfish, but haven't gotten this working yet.
Dan
-----------------------------------------------------------------------------
@Path("holidaysandevents")
public class HolidaysRESTJSONResource {
@Context
private UriInfo context;
DataSource dataSource;
public HolidaysRESTJSONResource() {
dataSource = DataSourceSingleton.getInstance().dataSource;
}
@GET
@Path("/countries")
@Produces(MediaType.APPLICATION_JSON)
public String getJsonCountries() {
if (TempDataStorage.countryList == null) {
// Connection connection = null;
try (Connection connection = dataSource.getConnection()){
// connection = dataSource.getConnection();
TempDataStorage.countryList = GetCountryList.doIt(connection);
} catch (SQLException e) {
System.out.println("Sql Exception" + e.getStackTrace());
} catch (Exception e) {
System.out.println("Other Exception" + e.getStackTrace());
}
//finally {
// if (connection != null) {
// try {
// connection.close();
// } catch (SQLException e) {
// System.out.println(e.getStackTrace());
// }
// }
// }
}
StringListWrapper listWrapper = new StringListWrapper();
listWrapper.setTheList(TempDataStorage.countryList);
return new Gson().toJson(listWrapper);
}
---------------------------------------------------------------------------------
Resource Monitoring
Click Configure Monitoring and enable monitoring for a component or service by selecting either LOW or HIGH. See the Online Help for more information.
Instance Name:
server
Resource :
HolidaysConnectionPool
Application :
Monitor (14 Statistics)
Collapse Group JDBC Connection Pool Statistics : HolidaysConnectionPool
NumConnCreated 20 count Aug 18, 2025 5:47:56 PM Aug 19, 2025 12:37:57 AM -- The number of physical connections that were created since the last reset.
NumConnFree 1count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM High Water Mark: 3 count
Low Water Mark: 0 count
The total number of free connections in the pool as of the last sampling.
NumConnReleased 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM -- Number of logical connections released to the pool.
NumPotentialConnLeak 0 count Aug 18, 2025 5:47:56 PM -- -- Number of potential connection leaks
NumConnFailedValidation 0 count Aug 18, 2025 5:47:56 PM -- -- The total number of connections in the connection pool that failed validation from the start time until the last sample time.
ConnRequestWaitTime 0millisecond Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM High Water Mark: 921 millisecond
Low Water Mark: 0 millisecond
The longest and shortest wait times of connection requests. The current value indicates the wait time of the last request that was serviced by the pool.
NumConnAcquired 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM -- Number of logical connections acquired from the pool.
AverageConnWaitTime 12 millisecond Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:49:00 AM -- Average wait-time-duration per successful connection request
NumConnDestroyed 19 count Aug 18, 2025 5:47:56 PM Aug 19, 2025 12:37:57 AM -- Number of physical connections that were destroyed since the last reset.
NumConnSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM -- -- Number of connections succesfully matched
NumConnNotSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM -- -- Number of connections rejected during matching
NumConnUsed 0count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM High Water Mark: 2 count
Low Water Mark: 0 count
Provides connection usage statistics. The total number of connections that are currently being used, as well as information about the maximum number of connections that were used (the high water mark).
WaitQueueLength 0 count Aug 18, 2025 5:47:56 PM -- -- Number of connection requests in the queue waiting to be serviced.
NumConnTimedOut 0 count Aug 18, 2025 5:47:56 PM -- -- The total number of connections in the pool that timed out between the start time and the last sample time.
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Monday, August 18, 2025 11:13 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
For instance, what happens when the year parameter for the "calender"
request is not a number?
Or if parameters are missing?
Have you tested these situations?
On Mon, Aug 18, 2025 at 10:52 AM Robert Turner <rt...@e-djuster.ca> wrote:
> Daniel,
>
> You have a leak - this we are certain of. You just don't yet know what
> causes it (it's clearly not a "standard use case" and the robots are
> likely triggering it).
>
> If I have my bets it is an unhandled unchecked exception (I'd even
> guess that it is likely a NumberFormatException) while processing one
> of your operations. Since you are reluctant to move your code to
> "try-with-resources" handling of the resource objects (which would
> make the code easier to read and avoid this problem), you will
> continue to see the problem unless you ensure that you are catching all exceptions (e.g.
> Throwable) (which is a bad practice in general).
>
> The 388 connection cound is the existing leaked connections from
> previous operations since you last started the Glassfish server and
> pool. I did suggest you restart Glassfish after adjusting that
> parameter to reset the numbers and the systems.
>
> From my testing, I am very confident that the different versions will
> not behave differently in the context of your application.
>
> Please have some confidence that we do know what we are talking about.
> Your problem is common and not unique.
>
> If I get some time, and with your permission, I might try to look at
> your server operations and see if I can trigger it for you... but if
> you share the code for all the operations (no need to share the DB
> queries, just the Java code), I bet we can find it quickly. However,
> us solving it for you avoids you benefiting from the learning experience.
>
> Robert
>
>
> On Mon, Aug 18, 2025 at 10:44 AM Daniel Schwartz
> <da...@danielgschwartz.com>
> wrote:
>
>> Chris,
>>
>> I thought it was you. I too have a job and family, and this is only
>> a side project, so my time also is limited.
>>
>> Anyway, I'm wondering if there really is a problem, or whether this
>> is just normal Glassfish behavior. Yesterday I changed the Glassfish
>> settings so that leak monitoring is activated, and today I got:
>>
>> NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- --
>> Number of potential connection leaks
>>
>> Also, this value:
>>
>> NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 18, 2025
>> 2:34:54 PM High Water Mark: 390 count Low Water Mark: 0 count
>> Provides connection usage statistics. The total number of connections
>> that are currently being used, as well as information about the
>> maximum number of connections that were used (the high water mark).
>>
>> Has remained unchanged at 388.
>>
>> There has been suspicion that my system has a memory leak, but all
>> indications are that this is not happening.
>>
>> I'm currently trying to upgrade to the current version of Glassfish
>> to see if this behaves differently, but haven't gotten it working yet.
>>
>> Dan
>>
>>
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>
>> Sent: Monday, August 18, 2025 10:29 AM
>> To: users@tomcat.apache.org
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> Daniel,
>>
>> On 8/16/25 10:57 PM, Daniel Schwartz wrote:
>> > There was a Chris too, but I think he made his recommendation and
>> > left.
>> I'm still here, but I do have a job and a family. Rob, Robert and
>> Chuck were making plenty of noise so I decided to reduce the clutter.
>>
>> > I'm coming to think that his advice was the best, namely, to just
>> > live with the current situation as long as it is working.
>> I gave no such advice. I think you should chase this down until you
>> understand the cause and have it fixed.
>>
>> -chris
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
For instance, what happens when the year parameter for the "calender"
request is not a number?
Or if parameters are missing?
Have you tested these situations?
On Mon, Aug 18, 2025 at 10:52 AM Robert Turner <rt...@e-djuster.ca> wrote:
> Daniel,
>
> You have a leak - this we are certain of. You just don't yet know what
> causes it (it's clearly not a "standard use case" and the robots are likely
> triggering it).
>
> If I have my bets it is an unhandled unchecked exception (I'd even guess
> that it is likely a NumberFormatException) while processing one of your
> operations. Since you are reluctant to move your code to
> "try-with-resources" handling of the resource objects (which would make
> the code easier to read and avoid this problem), you will continue to see
> the problem unless you ensure that you are catching all exceptions (e.g.
> Throwable) (which is a bad practice in general).
>
> The 388 connection cound is the existing leaked connections from previous
> operations since you last started the Glassfish server and pool. I did
> suggest you restart Glassfish after adjusting that parameter to reset the
> numbers and the systems.
>
> From my testing, I am very confident that the different versions will not
> behave differently in the context of your application.
>
> Please have some confidence that we do know what we are talking about.
> Your problem is common and not unique.
>
> If I get some time, and with your permission, I might try to look at your
> server operations and see if I can trigger it for you... but if you share
> the code for all the operations (no need to share the DB queries, just the
> Java code), I bet we can find it quickly. However, us solving it for you
> avoids you benefiting from the learning experience.
>
> Robert
>
>
> On Mon, Aug 18, 2025 at 10:44 AM Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
>> Chris,
>>
>> I thought it was you. I too have a job and family, and this is only a
>> side project, so my time also is limited.
>>
>> Anyway, I'm wondering if there really is a problem, or whether this is
>> just normal Glassfish behavior. Yesterday I changed the Glassfish settings
>> so that leak monitoring is activated, and today I got:
>>
>> NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- --
>> Number of potential connection leaks
>>
>> Also, this value:
>>
>> NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 18, 2025
>> 2:34:54 PM High Water Mark: 390 count
>> Low Water Mark: 0 count
>> Provides connection usage statistics. The total number of connections
>> that are currently being used, as well as information about the maximum
>> number of connections that were used (the high water mark).
>>
>> Has remained unchanged at 388.
>>
>> There has been suspicion that my system has a memory leak, but all
>> indications are that this is not happening.
>>
>> I'm currently trying to upgrade to the current version of Glassfish to
>> see if this behaves differently, but haven't gotten it working yet.
>>
>> Dan
>>
>>
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>
>> Sent: Monday, August 18, 2025 10:29 AM
>> To: users@tomcat.apache.org
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> Daniel,
>>
>> On 8/16/25 10:57 PM, Daniel Schwartz wrote:
>> > There was a Chris too, but I think he made his recommendation and
>> > left.
>> I'm still here, but I do have a job and a family. Rob, Robert and Chuck
>> were making plenty of noise so I decided to reduce the clutter.
>>
>> > I'm coming to think that his advice was the best, namely, to just live
>> > with the current situation as long as it is working.
>> I gave no such advice. I think you should chase this down until you
>> understand the cause and have it fixed.
>>
>> -chris
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Daniel,
You have a leak - this we are certain of. You just don't yet know what
causes it (it's clearly not a "standard use case" and the robots are likely
triggering it).
If I have my bets it is an unhandled unchecked exception (I'd even guess
that it is likely a NumberFormatException) while processing one of your
operations. Since you are reluctant to move your code to
"try-with-resources" handling of the resource objects (which would make
the code easier to read and avoid this problem), you will continue to see
the problem unless you ensure that you are catching all exceptions (e.g.
Throwable) (which is a bad practice in general).
The 388 connection cound is the existing leaked connections from previous
operations since you last started the Glassfish server and pool. I did
suggest you restart Glassfish after adjusting that parameter to reset the
numbers and the systems.
From my testing, I am very confident that the different versions will not
behave differently in the context of your application.
Please have some confidence that we do know what we are talking about. Your
problem is common and not unique.
If I get some time, and with your permission, I might try to look at your
server operations and see if I can trigger it for you... but if you share
the code for all the operations (no need to share the DB queries, just the
Java code), I bet we can find it quickly. However, us solving it for you
avoids you benefiting from the learning experience.
Robert
On Mon, Aug 18, 2025 at 10:44 AM Daniel Schwartz <da...@danielgschwartz.com>
wrote:
> Chris,
>
> I thought it was you. I too have a job and family, and this is only a
> side project, so my time also is limited.
>
> Anyway, I'm wondering if there really is a problem, or whether this is
> just normal Glassfish behavior. Yesterday I changed the Glassfish settings
> so that leak monitoring is activated, and today I got:
>
> NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- --
> Number of potential connection leaks
>
> Also, this value:
>
> NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 18, 2025
> 2:34:54 PM High Water Mark: 390 count
> Low Water Mark: 0 count
> Provides connection usage statistics. The total number of connections that
> are currently being used, as well as information about the maximum number
> of connections that were used (the high water mark).
>
> Has remained unchanged at 388.
>
> There has been suspicion that my system has a memory leak, but all
> indications are that this is not happening.
>
> I'm currently trying to upgrade to the current version of Glassfish to see
> if this behaves differently, but haven't gotten it working yet.
>
> Dan
>
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Monday, August 18, 2025 10:29 AM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Daniel,
>
> On 8/16/25 10:57 PM, Daniel Schwartz wrote:
> > There was a Chris too, but I think he made his recommendation and
> > left.
> I'm still here, but I do have a job and a family. Rob, Robert and Chuck
> were making plenty of noise so I decided to reduce the clutter.
>
> > I'm coming to think that his advice was the best, namely, to just live
> > with the current situation as long as it is working.
> I gave no such advice. I think you should chase this down until you
> understand the cause and have it fixed.
>
> -chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
I thought it was you. I too have a job and family, and this is only a side project, so my time also is limited.
Anyway, I'm wondering if there really is a problem, or whether this is just normal Glassfish behavior. Yesterday I changed the Glassfish settings so that leak monitoring is activated, and today I got:
NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- -- Number of potential connection leaks
Also, this value:
NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 18, 2025 2:34:54 PM High Water Mark: 390 count
Low Water Mark: 0 count
Provides connection usage statistics. The total number of connections that are currently being used, as well as information about the maximum number of connections that were used (the high water mark).
Has remained unchanged at 388.
There has been suspicion that my system has a memory leak, but all indications are that this is not happening.
I'm currently trying to upgrade to the current version of Glassfish to see if this behaves differently, but haven't gotten it working yet.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, August 18, 2025 10:29 AM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Daniel,
On 8/16/25 10:57 PM, Daniel Schwartz wrote:
> There was a Chris too, but I think he made his recommendation and
> left.
I'm still here, but I do have a job and a family. Rob, Robert and Chuck were making plenty of noise so I decided to reduce the clutter.
> I'm coming to think that his advice was the best, namely, to just live
> with the current situation as long as it is working.
I gave no such advice. I think you should chase this down until you understand the cause and have it fixed.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Daniel,
On 8/16/25 10:57 PM, Daniel Schwartz wrote:
> There was a Chris too, but I think he made his recommendation and
> left.
I'm still here, but I do have a job and a family. Rob, Robert and Chuck
were making plenty of noise so I decided to reduce the clutter.
> I'm coming to think that his advice was the best, namely, to just
> live with the current situation as long as it is working.
I gave no such advice. I think you should chase this down until you
understand the cause and have it fixed.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
From: Chuck Caldarale <n8...@gmail.com>
Sent: Saturday, August 16, 2025 1:11 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 16, at 11:20, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > You might be using a different version of Glassfish. I have 4.1 (which I realize is old). It won't let you set the minimum pool size to less than
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fb68816cf49614cda4f16318311f3923530b283fd298b84fc1b98ffd5d5149175a07de6c4ae167e0908052df4454a6d44816c8ad875812516f324216fbba463bd871fa91f47849f28b81ae03e65c3472afe5c68ef717c37340d928a0302a57cf97746ddfa09d92e48cbdeac324ac458fd1ff6e370b30266a351c879bd633dc9fb5e34bcf576711fbe7d23ccee7dba4790e5713a1b088e971f402af170d22ece0573f0bb5becac2bc684e5f49b7ebb8e40a40a47cb159fcf1837845728f86d7802889b923c952434ac6b7205465dbf12e84413d1bb8dd40dc6d942611c97110071a2423164f3043223>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fb68816cf49614cda4f16318311f3923530b283fd298b84fc1b98ffd5d5149175a07de6c4ae167e0908052df4454a6d44816c8ad875812516f324216fbba463bd871fa91f47849f28b81ae03e65c3472afe5c68ef717c37340d928a0302a57cf97746ddfa09d92e48cbdeac324ac458fd1ff6e370b30266a351c879bd633dc9fb5e34bcf576711fbe7d23ccee7dba4790e5713a1b088e971f402af170d22ece0573f0bb5becac2bc684e5f49b7ebb8e40a40a47cb159fcf1837845728f86d7802889b923c952434ac6b7205465dbf12e84413d1bb8dd40dc6d942611c97110071a2423164f3043223>
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 16, at 11:20, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> You might be using a different version of Glassfish. I have 4.1 (which I realize is old). It won't let you set the minimum pool size to less than 8.
Did you actually set the minimum (steady-pool-size) or did you just try changing max-pool-size to 1? You cannot lower the maximum below the value of steady-pool-size.
> If you try to do this, it reports an error and won't let you proceed. The simple test I ran shows that it is creating 8 physical connections for each logical connection.
Again, your conclusion is incorrect. The pool is creating 8 connections because that’s what the minimum is set to. Testing with a delay in your web service code between the connection acquisition and close calls - as Robert T already did - will show the pool size not growing beyond 8 until there are more than 8 concurrent requests being processed.
> This is clearly stated by the monitoring report, and you can’t disagree with that.
The report only shows that 8 connections have been created; there is no indication in the report of anything else.
> I have considered upgrading to a newer version of Glassfish, but this would be another project that I'm not prepared to undertake right now.
But you apparently are prepared to handle all the security risks of running a 11-year old server exposed to the internet. Bad tradeoff.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chuck, Robert, Rob,
There was a Chris too, but I think he made his recommendation and left. I'm coming to think that his advice was the best, namely, to just live with the current situation as long as it is working.
Anyway, today I reviewed my code and ran a few more tests. Here is what I found.
I found one .jar file where I opened three preparedStatements and neglected to close them. I fixed this, but it had no effect on the system performance.
In the main file where I open and close the DB connections, after each open instruction I put in a println statement to output a message like "opened getJsonCountries connection", and right after each close instruction I put in a println statement to output a message like "closed getJsonCountries connection". There are six of these. I then processed a typical query through my client interface and looked in the Glassfish log file, where I saw that every opened connection message was immediately followed by a closed connection message. This verifies that every connection that is opened is also being closed. I take this as confirming that my code is not generating any leaks.
I then went into the Glassfish JDBC monitor and recorded the data that was shown, and then a short while later clicked the refresh button and recorded the new data. Some of the data items had changed and some remained the same. The relevant ones are copied below. Briefly, NumConnCreated remained unchanged at 3989, and NumConnUsed remained unchanged at 388. However, NumConnAcquired changed from 12465 to 12475, a difference of 10, and NumConnReleased changed from 12235 to 12245, also a difference of 10. I take this as further evidence that there is no leak. In fact, I suspect that this is why NumPotentialConnLeak is always 0. In every given time window, the number of connections released equals the number acquired.
Next, I went into the JDBC pool configuration and started experimenting with different values for the maximum pool size. Strangely, I found that that NumConnUsed value of 388 was critical. If the maximum pool size is set to be anything less than or equal to 388, I start getting those messages saying that Glassfish can't allocate any more connections. But if I change the maximum pool size simply by increasing it to 389, the system starts running again. I have left this at 389 for several hours now, and the system keeps running, and the log file shows none of those "can't allocate" messages. Also, the web crawlers are having a heyday, and this isn't causing any problems. Interestingly, I've noted that the ones currently accessing my website are actually making valid queries.
Putting all this together, I'm coming to the conclusion that this is normal Glassfish behavior---there are no memory leaks, and actually no problem. Where that number 388 comes from, I have no idea, but it seems to be internal to the Glassfish system. I understand that people who work with pooling systems view this number as abnormally large, but maybe it's just that different pooling systems behave differently.
Regarding some more recent email: I'm using Java JDK 1.8.0_144. Glassfish 4.1 won't work with any version of Java later than 1.8, but later versions of Glassfish will work with later versions of Java. It might be that later versions of Glassfish behave differently and possibly work with small pool sizes. For my purposes, however, I'm not motivated to make the transition at this time.
Best regards to everyone and thanks for all the interest and advice. It's been a valuable learning experience for me.
Dan
-------------------------------------------------------------
NumConnCreated 3989 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:15:04 PM -- The number of physical connections that were created since the last reset.
NumConnReleased 12235 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:15:04 PM -- Number of logical connections released to the pool.
NumConnAcquired 12465 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:15:04 PM -- Number of logical connections acquired from the pool.
NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 16, 2025 9:15:04 PM High Water Mark: 390 count
Low Water Mark: 0 count
Provides connection usage statistics. The total number of connections that are currently being used, as well as information about the maximum number of connections that were used (the high water mark).
NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- -- Number of potential connection leaks
---------------------------------------------------------------
NumConnCreated 3989 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:15:04 PM -- The number of physical connections that were created since the last reset.
NumConnReleased 12245 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:18:03 PM -- Number of logical connections released to the pool.
NumConnAcquired 12475 count Aug 8, 2025 3:18:57 PM Aug 16, 2025 9:18:03 PM -- Number of logical connections acquired from the pool
NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 16, 2025 9:18:03 PM High Water Mark: 390 count
Low Water Mark: 0 count
Provides connection usage statistics. The total number of connections that are currently being used, as well as information about the maximum number of connections that were used (the high water mark).
NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- -- Number of potential connection leaks
----------------------------------------------------------------
12475 - 12465 = 10 connections acquired
12245 - 12235 = 10 connections released
From: Chuck Caldarale <n8...@gmail.com>
Sent: Saturday, August 16, 2025 3:58 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 16, at 14:52, Robert Turner <rt...@e-djuster.ca.INVALID>> wrote: > > On Sat, Aug 16, 2025, 15:44 Chuck Caldarale <n8...@gmail.com>> wrote: > >> Robert - >> >> (Sorry for top-posting,
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fd826f835b18e7338a04015f49a15b77653863ed0a15fa37ffc4f9894205136912099218a415a34a8ae189d273ade7bf93e5739fc7a770803286fa06b5f50c5277dd932c6c6d6a96007abf8fcc9dd54653431d0b42bb6c1c99874a0e848fca0e5be0e5182fc1206b39fc7aaa8978197723d6940e429952fd3371f324c6ef50f44aa0f1038a1a89ec337ba2c2b5fbc497ae56a80408831d910c0c7ab891b4114e2b6b4eb66e6464952b6293676c34aa1745bf2f09c40a60fc42b27d1429c85a392b85acf42a1d43be0654b8da320873d23500fb3d74c6fb8912f7e104712568f0e8777a337edcdbaf8>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fd826f835b18e7338a04015f49a15b77653863ed0a15fa37ffc4f9894205136912099218a415a34a8ae189d273ade7bf93e5739fc7a770803286fa06b5f50c5277dd932c6c6d6a96007abf8fcc9dd54653431d0b42bb6c1c99874a0e848fca0e5be0e5182fc1206b39fc7aaa8978197723d6940e429952fd3371f324c6ef50f44aa0f1038a1a89ec337ba2c2b5fbc497ae56a80408831d910c0c7ab891b4114e2b6b4eb66e6464952b6293676c34aa1745bf2f09c40a60fc42b27d1429c85a392b85acf42a1d43be0654b8da320873d23500fb3d74c6fb8912f7e104712568f0e8777a337edcdbaf8>
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 16, at 14:52, Robert Turner <rt...@e-djuster.ca.INVALID>> wrote:
>
> On Sat, Aug 16, 2025, 15:44 Chuck Caldarale <n8...@gmail.com>> wrote:
>
>> Robert -
>>
>> (Sorry for top-posting, but this is just about GlassFish 4.1, not Dan’s
>> problem.)
>>
>> GlassFish 4.1 is a bit hard to find these days, but it can be downloaded
>> from here: https://urldefense.proofpoint.com/v2/url?u=https-3A__javaee.github.io_glassfish_download&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=kcwcsXJW1KFHWbZPs5f2PiB8motHlu4wBFKFO8tq1mlpq9con6rdfRkHYhVBSr9Z&s=_KIYlbVezHnWB6M_6YL8idK2o098rn0x11VqikQDiFc&e=
>>
>> Also, 4.1 refuses to run on a modern JVM, resulting in this message:
>>
>> GlassFish requires Java SE version 6. Your JDK is version 0
>>
>> Mine is currently 23.0.2; not sure how far back one will have to go…
>
>
> Thanks for the heads up. That might be a bit tricky then... Maybe that
> won't happen then.
The README says it will run on JDK 8, but makes no mention of anything beyond that. I don’t remember what the current JVM was 11 years ago...
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
I was thinking about this, and did reset it to 10. I'll watch and see if anything happens.
Someone on the Eclipse email list replied. I'll hope he can help.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Sunday, August 17, 2025 8:56 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
IIRC, the setting is the number of seconds before reporting a connection as leaked. So, because most of your connections should be very short-lived, it should probably work. I would typically suggest a larger number as applications often have more variability in their use of connections (so something more like 10 seconds, or a few minutes if the application generates reports). Applications could even have different pools with different settings for use in different use cases.
Unfortunately I cannot really help with the Glassfish migration as I have literally only used it over that past couple of days to assist with your issue. Good luck there. That might be a better topic for a Glassfish mailing list as opposed to this one. The suggestions I made were just general ones for migrating any text configuration from one version to another.
Robert
On Sun, Aug 17, 2025, 20:44 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Okay, I have changed it to "1". Does this seem reasonable? I don't
> know what would be a good setting.
>
> I have found some documentation on the Eclipse website, but it's a bit
> confusing. But I am having contact with someone in that group. Maybe
> he can help. I tried to duplicate the configuration I have for
> version 4.1, but this doesn't seem to work for version 7.0.25.
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Sunday, August 17, 2025 8:19 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Yes, 0 is the default (in both versions) which means leak detection is
> disabled. That is likely why Glassfish has never reported a leak.
>
>
>
> You should be able to update your 4.1 config using the UI or the
> asadmin tool.
>
> I don't know how well copying the setup works between the versions. I
> know I was able to copy bits from the 7.0.25 configuration to the 4.1
> configuration because the UI was having issues for me in 4.1.
>
> I would treat the version 7 migration separately and often it's better
> to start with the new out of box configuration and apply only your
> changes to the new system as often system defaults are changed, or new
> features configured by default. You risk potentially having a less
> modern config if you copy the whole config over.
>
> One way to do this is compare your config to the baseline 4.1 config
> (diff is your friend here), and then only apply the changes to the new
> system, keeping in mind that you may need to adapt and update
> configuration between versions.
>
> Robert
>
> On Sun, Aug 17, 2025, 20:04 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
> > Hi Robert,
> >
> > I just checked. The Connection Leak timeout is set to 0. This
> > evidently is the default.
> >
> > I have been trying to upgrade to the latest version of Glassfish, 7.0.25,
> > on my local PC. Am working on this. I tried to copy the setup I have
> for
> > 4.1, but am finding that the
> > the instructions for setting up connection pooling are different.
> >
> > Dan
> >
> > -----Original Message-----
> > From: Robert Turner <rt...@e-djuster.ca.INVALID>
> > Sent: Sunday, August 17, 2025 2:13 PM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >
> > So, a quick question Dan:
> >
> > Have you enabled Glassfish JDBC pool leak detection? (On the
> > advanced page, under connection settings, the value for "Connection
> > leak
> > timeout")
> >
> > If this has not been set to a non zero value, Glassfish will not
> > report connection leaks.
> >
> > Turn this on, reset your Glassfish server.... And then give it some
> > time and check your stats and logs again...
> >
> > Robert
> >
> > On Sun, Aug 17, 2025, 12:08 Daniel Schwartz
> > <da...@danielgschwartz.com>
> > wrote:
> >
> > > Rob,
> > >
> > > A few years ago, I tried to upgrade to the then current version of
> > > Glassfish and couldn’t get it to work. I’m considering trying
> > > again with the current version.
> > >
> > > Dan
> > >
> > > From: Rob Sargent <rs...@xmission.com>
> > > Sent: Sunday, August 17, 2025 12:04 PM
> > > To: Tomcat Users List <us...@tomcat.apache.org>
> > > Cc: Tomcat Users List <us...@tomcat.apache.org>
> > > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> > >
> > > > On Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > > > <dan@danielgschwartz.com
> > > <ma...@danielgschwartz.com>> wrote: > > In my previous
> > > posting, at the very end, I mentioned that I’m using jdk1.8.0_144
> > > with Glassfish
> > 4.1.
> > > That version of Glassfish won’t with anything
> > > NkdkJdXPPEBannerStart Be Careful With This Message From (Rob
> > > Sargent <rs...@xmission.com>)<
> > > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=536
> > > 16
> > > c7
> > > 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f30
> > > 0a
> > > 50
> > > 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e0
> > > 34
> > > c3
> > > 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad
> > > 18
> > > 28
> > > 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe
> > > 71
> > > d0
> > > 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f
> > > 1c
> > > fd
> > > a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c7321
> > > 0b
> > > 92
> > > 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> > > >
> > > Learn More<
> > > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=536
> > > 16
> > > c7
> > > 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f30
> > > 0a
> > > 50
> > > 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e0
> > > 34
> > > c3
> > > 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad
> > > 18
> > > 28
> > > 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe
> > > 71
> > > d0
> > > 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f
> > > 1c
> > > fd
> > > a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c7321
> > > 0b
> > > 92
> > > 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> > > >
> > > 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 Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > > > <dan@danielgschwartz.com
> > > <ma...@danielgschwartz.com>> wrote:
> > >
> > > >
> > >
> > > > In my previous posting, at the very end, I mentioned that I’m
> > > > using
> > > jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t
> > > with anything later than 1.8.
> > >
> > > >
> > >
> > > > Dan
> > >
> > >
> > >
> > > Are these specs for glassfish and java requirements? A new jdk is
> > > an easy install and a current glassfish would be a real security
> > enhancement.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > -
> > >
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> > > users-unsubscribe@tomcat.apache.org>
> > >
> > > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> > > users-help@tomcat.apache.org>
> > >
> > >
> > >
> >
>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
IIRC, the setting is the number of seconds before reporting a connection as
leaked. So, because most of your connections should be very short-lived, it
should probably work. I would typically suggest a larger number as
applications often have more variability in their use of connections (so
something more like 10 seconds, or a few minutes if the application
generates reports). Applications could even have different pools with
different settings for use in different use cases.
Unfortunately I cannot really help with the Glassfish migration as I have
literally only used it over that past couple of days to assist with your
issue. Good luck there. That might be a better topic for a Glassfish
mailing list as opposed to this one. The suggestions I made were just
general ones for migrating any text configuration from one version to
another.
Robert
On Sun, Aug 17, 2025, 20:44 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Okay, I have changed it to "1". Does this seem reasonable? I don't know
> what would be a good setting.
>
> I have found some documentation on the Eclipse website, but it's a bit
> confusing. But I am having contact with someone in that group. Maybe he
> can help. I tried to duplicate the configuration I have for version 4.1,
> but this doesn't seem to work for version 7.0.25.
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Sunday, August 17, 2025 8:19 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Yes, 0 is the default (in both versions) which means leak detection is
> disabled. That is likely why Glassfish has never reported a leak.
>
>
>
> You should be able to update your 4.1 config using the UI or the asadmin
> tool.
>
> I don't know how well copying the setup works between the versions. I know
> I was able to copy bits from the 7.0.25 configuration to the 4.1
> configuration because the UI was having issues for me in 4.1.
>
> I would treat the version 7 migration separately and often it's better to
> start with the new out of box configuration and apply only your changes to
> the new system as often system defaults are changed, or new features
> configured by default. You risk potentially having a less modern config if
> you copy the whole config over.
>
> One way to do this is compare your config to the baseline 4.1 config (diff
> is your friend here), and then only apply the changes to the new system,
> keeping in mind that you may need to adapt and update configuration between
> versions.
>
> Robert
>
> On Sun, Aug 17, 2025, 20:04 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
> > Hi Robert,
> >
> > I just checked. The Connection Leak timeout is set to 0. This
> > evidently is the default.
> >
> > I have been trying to upgrade to the latest version of Glassfish, 7.0.25,
> > on my local PC. Am working on this. I tried to copy the setup I have
> for
> > 4.1, but am finding that the
> > the instructions for setting up connection pooling are different.
> >
> > Dan
> >
> > -----Original Message-----
> > From: Robert Turner <rt...@e-djuster.ca.INVALID>
> > Sent: Sunday, August 17, 2025 2:13 PM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >
> > So, a quick question Dan:
> >
> > Have you enabled Glassfish JDBC pool leak detection? (On the advanced
> > page, under connection settings, the value for "Connection leak
> > timeout")
> >
> > If this has not been set to a non zero value, Glassfish will not
> > report connection leaks.
> >
> > Turn this on, reset your Glassfish server.... And then give it some
> > time and check your stats and logs again...
> >
> > Robert
> >
> > On Sun, Aug 17, 2025, 12:08 Daniel Schwartz <da...@danielgschwartz.com>
> > wrote:
> >
> > > Rob,
> > >
> > > A few years ago, I tried to upgrade to the then current version of
> > > Glassfish and couldn’t get it to work. I’m considering trying again
> > > with the current version.
> > >
> > > Dan
> > >
> > > From: Rob Sargent <rs...@xmission.com>
> > > Sent: Sunday, August 17, 2025 12:04 PM
> > > To: Tomcat Users List <us...@tomcat.apache.org>
> > > Cc: Tomcat Users List <us...@tomcat.apache.org>
> > > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> > >
> > > > On Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > > > <dan@danielgschwartz.com
> > > <ma...@danielgschwartz.com>> wrote: > > In my previous
> > > posting, at the very end, I mentioned that I’m using jdk1.8.0_144
> > > with Glassfish
> > 4.1.
> > > That version of Glassfish won’t with anything NkdkJdXPPEBannerStart
> > > Be Careful With This Message From (Rob Sargent
> > > <rs...@xmission.com>)<
> > > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616
> > > c7
> > > 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a
> > > 50
> > > 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034
> > > c3
> > > 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18
> > > 28
> > > 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71
> > > d0
> > > 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1c
> > > fd
> > > a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b
> > > 92
> > > 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> > > >
> > > Learn More<
> > > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616
> > > c7
> > > 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a
> > > 50
> > > 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034
> > > c3
> > > 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18
> > > 28
> > > 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71
> > > d0
> > > 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1c
> > > fd
> > > a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b
> > > 92
> > > 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> > > >
> > > 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 Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > > > <dan@danielgschwartz.com
> > > <ma...@danielgschwartz.com>> wrote:
> > >
> > > >
> > >
> > > > In my previous posting, at the very end, I mentioned that I’m
> > > > using
> > > jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t
> > > with anything later than 1.8.
> > >
> > > >
> > >
> > > > Dan
> > >
> > >
> > >
> > > Are these specs for glassfish and java requirements? A new jdk is
> > > an easy install and a current glassfish would be a real security
> > enhancement.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > -
> > >
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> > > users-unsubscribe@tomcat.apache.org>
> > >
> > > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> > > users-help@tomcat.apache.org>
> > >
> > >
> > >
> >
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Thanks. I have changed it to 10. I’ll watch and see if anything happens.
From: Chuck Caldarale <n8...@gmail.com>
Sent: Sunday, August 17, 2025 8:55 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 17, at 19:43, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > Okay, I have changed it to "1". Does this seem reasonable? I don't know what would be a good setting. Rather depends on whether or not
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fde759ff524af3259d449ad12fa525db8d74da85857ab5b662978d0dc7116c71f1606da376a59562f02b907dc4810f21ab65fa9952ea611611939a75aff7f786b876d7158ce3bef3b8160e5c5357e26f36986f8fc98d92ca7287e722b19a1ce92b9a4ec5967fcbefdf8818fdd2473634ff82d673d692922a3fe2b6e21aa4d1efc17dc725b2c0cce5f0174dda597e01657f7af7bc5903f467c4c296a4751a2f2720fb9e88181f756c2d1420ae0c108ecaabcea17b37881fcdb6338640803bab5ba9ae2d24327f7de8291d0d72c2d6aa140a14852c61d565315f0652727c3a42f6ca0e491b1b6e899c1>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fde759ff524af3259d449ad12fa525db8d74da85857ab5b662978d0dc7116c71f1606da376a59562f02b907dc4810f21ab65fa9952ea611611939a75aff7f786b876d7158ce3bef3b8160e5c5357e26f36986f8fc98d92ca7287e722b19a1ce92b9a4ec5967fcbefdf8818fdd2473634ff82d673d692922a3fe2b6e21aa4d1efc17dc725b2c0cce5f0174dda597e01657f7af7bc5903f467c4c296a4751a2f2720fb9e88181f756c2d1420ae0c108ecaabcea17b37881fcdb6338640803bab5ba9ae2d24327f7de8291d0d72c2d6aa140a14852c61d565315f0652727c3a42f6ca0e491b1b6e899c1>
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 17, at 19:43, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Okay, I have changed it to "1". Does this seem reasonable? I don't know what would be a good setting.
Rather depends on whether or not your database server always responds promptly. Might catch a few false positives with a value of just one second; 3 - 5 would be a bit safer.
Also, I would not set the related “leak reclaim” tag to true, since that might end up with a connection object being used twice.
- Chuck
> I have found some documentation on the Eclipse website, but it's a bit confusing. But I am having contact with someone in that group. Maybe he can help. I tried to duplicate the configuration I have for version 4.1, but this doesn't seem to work for version 7.0.25.
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>>
> Sent: Sunday, August 17, 2025 8:19 PM
> To: Tomcat Users List <us...@tomcat.apache.org>>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Yes, 0 is the default (in both versions) which means leak detection is disabled. That is likely why Glassfish has never reported a leak.
>
> You should be able to update your 4.1 config using the UI or the asadmin tool.
>
> I don't know how well copying the setup works between the versions. I know I was able to copy bits from the 7.0.25 configuration to the 4.1 configuration because the UI was having issues for me in 4.1.
>
> I would treat the version 7 migration separately and often it's better to start with the new out of box configuration and apply only your changes to the new system as often system defaults are changed, or new features configured by default. You risk potentially having a less modern config if you copy the whole config over.
>
> One way to do this is compare your config to the baseline 4.1 config (diff is your friend here), and then only apply the changes to the new system, keeping in mind that you may need to adapt and update configuration between versions.
>
> Robert
>
> On Sun, Aug 17, 2025, 20:04 Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
>> Hi Robert,
>>
>> I just checked. The Connection Leak timeout is set to 0. This
>> evidently is the default.
>>
>> I have been trying to upgrade to the latest version of Glassfish, 7.0.25,
>> on my local PC. Am working on this. I tried to copy the setup I have for
>> 4.1, but am finding that the
>> the instructions for setting up connection pooling are different.
>>
>> Dan
>>
>> -----Original Message-----
>> From: Robert Turner <rt...@e-djuster.ca.INVALID>>
>> Sent: Sunday, August 17, 2025 2:13 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>>
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> So, a quick question Dan:
>>
>> Have you enabled Glassfish JDBC pool leak detection? (On the advanced
>> page, under connection settings, the value for "Connection leak
>> timeout")
>>
>> If this has not been set to a non zero value, Glassfish will not
>> report connection leaks.
>>
>> Turn this on, reset your Glassfish server.... And then give it some
>> time and check your stats and logs again...
>>
>> Robert
>>
>> On Sun, Aug 17, 2025, 12:08 Daniel Schwartz <da...@danielgschwartz.com>>
>> wrote:
>>
>>> Rob,
>>>
>>> A few years ago, I tried to upgrade to the then current version of
>>> Glassfish and couldn’t get it to work. I’m considering trying again
>>> with the current version.
>>>
>>> Dan
>>>
>>> From: Rob Sargent <rs...@xmission.com>>
>>> Sent: Sunday, August 17, 2025 12:04 PM
>>> To: Tomcat Users List <us...@tomcat.apache.org>>
>>> Cc: Tomcat Users List <us...@tomcat.apache.org>>
>>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>>
>>>> On Aug 17, 2025, at 9:45 AM, Daniel Schwartz
>>>> <dan@danielgschwartz.com
>>> <ma...@danielgschwartz.com>> wrote: > > In my previous
>>> posting, at the very end, I mentioned that I’m using jdk1.8.0_144
>>> with Glassfish
>> 4.1.
>>> That version of Glassfish won’t with anything NkdkJdXPPEBannerStart
>>> Be Careful With This Message From (Rob Sargent
>>> <rs...@xmission.com>>)<
>>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616
>>> c7
>>> 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a
>>> 50
>>> 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034
>>> c3
>>> 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18
>>> 28
>>> 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71
>>> d0
>>> 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1c
>>> fd
>>> a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b
>>> 92
>>> 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
>>>>
>>> Learn More<
>>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616
>>> c7
>>> 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a
>>> 50
>>> 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034
>>> c3
>>> 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18
>>> 28
>>> 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71
>>> d0
>>> 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1c
>>> fd
>>> a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b
>>> 92
>>> 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
>>>>
>>> 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 Aug 17, 2025, at 9:45 AM, Daniel Schwartz
>>>> <dan@danielgschwartz.com
>>> <ma...@danielgschwartz.com>> wrote:
>>>
>>>>
>>>
>>>> In my previous posting, at the very end, I mentioned that I’m
>>>> using
>>> jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t
>>> with anything later than 1.8.
>>>
>>>>
>>>
>>>> Dan
>>>
>>>
>>>
>>> Are these specs for glassfish and java requirements? A new jdk is
>>> an easy install and a current glassfish would be a real security
>> enhancement.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto<mailto:users-unsubscribe@tomcat.apache.org%3cmailto>:
>>> users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>>
>>>
>>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto<mailto:users-help@tomcat.apache.org%3cmailto>:
>>> users-help@tomcat.apache.org<ma...@tomcat.apache.org>>
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 17, at 19:43, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Okay, I have changed it to "1". Does this seem reasonable? I don't know what would be a good setting.
Rather depends on whether or not your database server always responds promptly. Might catch a few false positives with a value of just one second; 3 - 5 would be a bit safer.
Also, I would not set the related “leak reclaim” tag to true, since that might end up with a connection object being used twice.
- Chuck
> I have found some documentation on the Eclipse website, but it's a bit confusing. But I am having contact with someone in that group. Maybe he can help. I tried to duplicate the configuration I have for version 4.1, but this doesn't seem to work for version 7.0.25.
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Sunday, August 17, 2025 8:19 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Yes, 0 is the default (in both versions) which means leak detection is disabled. That is likely why Glassfish has never reported a leak.
>
> You should be able to update your 4.1 config using the UI or the asadmin tool.
>
> I don't know how well copying the setup works between the versions. I know I was able to copy bits from the 7.0.25 configuration to the 4.1 configuration because the UI was having issues for me in 4.1.
>
> I would treat the version 7 migration separately and often it's better to start with the new out of box configuration and apply only your changes to the new system as often system defaults are changed, or new features configured by default. You risk potentially having a less modern config if you copy the whole config over.
>
> One way to do this is compare your config to the baseline 4.1 config (diff is your friend here), and then only apply the changes to the new system, keeping in mind that you may need to adapt and update configuration between versions.
>
> Robert
>
> On Sun, Aug 17, 2025, 20:04 Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
>> Hi Robert,
>>
>> I just checked. The Connection Leak timeout is set to 0. This
>> evidently is the default.
>>
>> I have been trying to upgrade to the latest version of Glassfish, 7.0.25,
>> on my local PC. Am working on this. I tried to copy the setup I have for
>> 4.1, but am finding that the
>> the instructions for setting up connection pooling are different.
>>
>> Dan
>>
>> -----Original Message-----
>> From: Robert Turner <rt...@e-djuster.ca.INVALID>
>> Sent: Sunday, August 17, 2025 2:13 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> So, a quick question Dan:
>>
>> Have you enabled Glassfish JDBC pool leak detection? (On the advanced
>> page, under connection settings, the value for "Connection leak
>> timeout")
>>
>> If this has not been set to a non zero value, Glassfish will not
>> report connection leaks.
>>
>> Turn this on, reset your Glassfish server.... And then give it some
>> time and check your stats and logs again...
>>
>> Robert
>>
>> On Sun, Aug 17, 2025, 12:08 Daniel Schwartz <da...@danielgschwartz.com>
>> wrote:
>>
>>> Rob,
>>>
>>> A few years ago, I tried to upgrade to the then current version of
>>> Glassfish and couldn’t get it to work. I’m considering trying again
>>> with the current version.
>>>
>>> Dan
>>>
>>> From: Rob Sargent <rs...@xmission.com>
>>> Sent: Sunday, August 17, 2025 12:04 PM
>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>> Cc: Tomcat Users List <us...@tomcat.apache.org>
>>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>>
>>>> On Aug 17, 2025, at 9:45 AM, Daniel Schwartz
>>>> <dan@danielgschwartz.com
>>> <ma...@danielgschwartz.com>> wrote: > > In my previous
>>> posting, at the very end, I mentioned that I’m using jdk1.8.0_144
>>> with Glassfish
>> 4.1.
>>> That version of Glassfish won’t with anything NkdkJdXPPEBannerStart
>>> Be Careful With This Message From (Rob Sargent
>>> <rs...@xmission.com>)<
>>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616
>>> c7
>>> 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a
>>> 50
>>> 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034
>>> c3
>>> 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18
>>> 28
>>> 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71
>>> d0
>>> 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1c
>>> fd
>>> a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b
>>> 92
>>> 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
>>>>
>>> Learn More<
>>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616
>>> c7
>>> 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a
>>> 50
>>> 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034
>>> c3
>>> 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18
>>> 28
>>> 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71
>>> d0
>>> 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1c
>>> fd
>>> a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b
>>> 92
>>> 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
>>>>
>>> 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 Aug 17, 2025, at 9:45 AM, Daniel Schwartz
>>>> <dan@danielgschwartz.com
>>> <ma...@danielgschwartz.com>> wrote:
>>>
>>>>
>>>
>>>> In my previous posting, at the very end, I mentioned that I’m
>>>> using
>>> jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t
>>> with anything later than 1.8.
>>>
>>>>
>>>
>>>> Dan
>>>
>>>
>>>
>>> Are these specs for glassfish and java requirements? A new jdk is
>>> an easy install and a current glassfish would be a real security
>> enhancement.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>>> users-unsubscribe@tomcat.apache.org>
>>>
>>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>>> users-help@tomcat.apache.org>
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Okay, I have changed it to "1". Does this seem reasonable? I don't know what would be a good setting.
I have found some documentation on the Eclipse website, but it's a bit confusing. But I am having contact with someone in that group. Maybe he can help. I tried to duplicate the configuration I have for version 4.1, but this doesn't seem to work for version 7.0.25.
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Sunday, August 17, 2025 8:19 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Yes, 0 is the default (in both versions) which means leak detection is disabled. That is likely why Glassfish has never reported a leak.
You should be able to update your 4.1 config using the UI or the asadmin tool.
I don't know how well copying the setup works between the versions. I know I was able to copy bits from the 7.0.25 configuration to the 4.1 configuration because the UI was having issues for me in 4.1.
I would treat the version 7 migration separately and often it's better to start with the new out of box configuration and apply only your changes to the new system as often system defaults are changed, or new features configured by default. You risk potentially having a less modern config if you copy the whole config over.
One way to do this is compare your config to the baseline 4.1 config (diff is your friend here), and then only apply the changes to the new system, keeping in mind that you may need to adapt and update configuration between versions.
Robert
On Sun, Aug 17, 2025, 20:04 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Hi Robert,
>
> I just checked. The Connection Leak timeout is set to 0. This
> evidently is the default.
>
> I have been trying to upgrade to the latest version of Glassfish, 7.0.25,
> on my local PC. Am working on this. I tried to copy the setup I have for
> 4.1, but am finding that the
> the instructions for setting up connection pooling are different.
>
> Dan
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Sunday, August 17, 2025 2:13 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> So, a quick question Dan:
>
> Have you enabled Glassfish JDBC pool leak detection? (On the advanced
> page, under connection settings, the value for "Connection leak
> timeout")
>
> If this has not been set to a non zero value, Glassfish will not
> report connection leaks.
>
> Turn this on, reset your Glassfish server.... And then give it some
> time and check your stats and logs again...
>
> Robert
>
> On Sun, Aug 17, 2025, 12:08 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
> > Rob,
> >
> > A few years ago, I tried to upgrade to the then current version of
> > Glassfish and couldn’t get it to work. I’m considering trying again
> > with the current version.
> >
> > Dan
> >
> > From: Rob Sargent <rs...@xmission.com>
> > Sent: Sunday, August 17, 2025 12:04 PM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Cc: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >
> > > On Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > > <dan@danielgschwartz.com
> > <ma...@danielgschwartz.com>> wrote: > > In my previous
> > posting, at the very end, I mentioned that I’m using jdk1.8.0_144
> > with Glassfish
> 4.1.
> > That version of Glassfish won’t with anything NkdkJdXPPEBannerStart
> > Be Careful With This Message From (Rob Sargent
> > <rs...@xmission.com>)<
> > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616
> > c7
> > 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a
> > 50
> > 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034
> > c3
> > 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18
> > 28
> > 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71
> > d0
> > 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1c
> > fd
> > a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b
> > 92
> > 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> > >
> > Learn More<
> > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616
> > c7
> > 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a
> > 50
> > 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034
> > c3
> > 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18
> > 28
> > 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71
> > d0
> > 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1c
> > fd
> > a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b
> > 92
> > 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> > >
> > 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 Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > > <dan@danielgschwartz.com
> > <ma...@danielgschwartz.com>> wrote:
> >
> > >
> >
> > > In my previous posting, at the very end, I mentioned that I’m
> > > using
> > jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t
> > with anything later than 1.8.
> >
> > >
> >
> > > Dan
> >
> >
> >
> > Are these specs for glassfish and java requirements? A new jdk is
> > an easy install and a current glassfish would be a real security
> enhancement.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > -
> >
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> > users-unsubscribe@tomcat.apache.org>
> >
> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> > users-help@tomcat.apache.org>
> >
> >
> >
>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Yes, 0 is the default (in both versions) which means leak detection is
disabled. That is likely why Glassfish has never reported a leak.
You should be able to update your 4.1 config using the UI or the asadmin
tool.
I don't know how well copying the setup works between the versions. I know
I was able to copy bits from the 7.0.25 configuration to the 4.1
configuration because the UI was having issues for me in 4.1.
I would treat the version 7 migration separately and often it's better to
start with the new out of box configuration and apply only your changes to
the new system as often system defaults are changed, or new features
configured by default. You risk potentially having a less modern config if
you copy the whole config over.
One way to do this is compare your config to the baseline 4.1 config (diff
is your friend here), and then only apply the changes to the new system,
keeping in mind that you may need to adapt and update configuration between
versions.
Robert
On Sun, Aug 17, 2025, 20:04 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Hi Robert,
>
> I just checked. The Connection Leak timeout is set to 0. This evidently
> is the default.
>
> I have been trying to upgrade to the latest version of Glassfish, 7.0.25,
> on my local PC. Am working on this. I tried to copy the setup I have for
> 4.1, but am finding that the
> the instructions for setting up connection pooling are different.
>
> Dan
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Sunday, August 17, 2025 2:13 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> So, a quick question Dan:
>
> Have you enabled Glassfish JDBC pool leak detection? (On the advanced
> page, under connection settings, the value for "Connection leak timeout")
>
> If this has not been set to a non zero value, Glassfish will not report
> connection leaks.
>
> Turn this on, reset your Glassfish server.... And then give it some time
> and check your stats and logs again...
>
> Robert
>
> On Sun, Aug 17, 2025, 12:08 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
> > Rob,
> >
> > A few years ago, I tried to upgrade to the then current version of
> > Glassfish and couldn’t get it to work. I’m considering trying again
> > with the current version.
> >
> > Dan
> >
> > From: Rob Sargent <rs...@xmission.com>
> > Sent: Sunday, August 17, 2025 12:04 PM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Cc: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >
> > > On Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > > <dan@danielgschwartz.com
> > <ma...@danielgschwartz.com>> wrote: > > In my previous posting,
> > at the very end, I mentioned that I’m using jdk1.8.0_144 with Glassfish
> 4.1.
> > That version of Glassfish won’t with anything NkdkJdXPPEBannerStart Be
> > Careful With This Message From (Rob Sargent <rs...@xmission.com>)<
> > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> > 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a50
> > 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034c3
> > 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad1828
> > 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71d0
> > 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1cfd
> > a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b92
> > 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> > >
> > Learn More<
> > https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> > 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a50
> > 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034c3
> > 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad1828
> > 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71d0
> > 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1cfd
> > a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b92
> > 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> > >
> > 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 Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > > <dan@danielgschwartz.com
> > <ma...@danielgschwartz.com>> wrote:
> >
> > >
> >
> > > In my previous posting, at the very end, I mentioned that I’m using
> > jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t with
> > anything later than 1.8.
> >
> > >
> >
> > > Dan
> >
> >
> >
> > Are these specs for glassfish and java requirements? A new jdk is an
> > easy install and a current glassfish would be a real security
> enhancement.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> > users-unsubscribe@tomcat.apache.org>
> >
> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> > users-help@tomcat.apache.org>
> >
> >
> >
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hi Robert,
I just checked. The Connection Leak timeout is set to 0. This evidently is the default.
I have been trying to upgrade to the latest version of Glassfish, 7.0.25, on my local PC. Am working on this. I tried to copy the setup I have for 4.1, but am finding that the
the instructions for setting up connection pooling are different.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Sunday, August 17, 2025 2:13 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
So, a quick question Dan:
Have you enabled Glassfish JDBC pool leak detection? (On the advanced page, under connection settings, the value for "Connection leak timeout")
If this has not been set to a non zero value, Glassfish will not report connection leaks.
Turn this on, reset your Glassfish server.... And then give it some time and check your stats and logs again...
Robert
On Sun, Aug 17, 2025, 12:08 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Rob,
>
> A few years ago, I tried to upgrade to the then current version of
> Glassfish and couldn’t get it to work. I’m considering trying again
> with the current version.
>
> Dan
>
> From: Rob Sargent <rs...@xmission.com>
> Sent: Sunday, August 17, 2025 12:04 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Cc: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> > On Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote: > > In my previous posting,
> at the very end, I mentioned that I’m using jdk1.8.0_144 with Glassfish 4.1.
> That version of Glassfish won’t with anything NkdkJdXPPEBannerStart Be
> Careful With This Message From (Rob Sargent <rs...@xmission.com>)<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a50
> 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034c3
> 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad1828
> 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71d0
> 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1cfd
> a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b92
> 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> >
> Learn More<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a50
> 1ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034c3
> 7a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad1828
> 6a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71d0
> 9f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1cfd
> a17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b92
> 23f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> >
> 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 Aug 17, 2025, at 9:45 AM, Daniel Schwartz
> > <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote:
>
> >
>
> > In my previous posting, at the very end, I mentioned that I’m using
> jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t with
> anything later than 1.8.
>
> >
>
> > Dan
>
>
>
> Are these specs for glassfish and java requirements? A new jdk is an
> easy install and a current glassfish would be a real security enhancement.
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
So, a quick question Dan:
Have you enabled Glassfish JDBC pool leak detection? (On the advanced page,
under connection settings, the value for "Connection leak timeout")
If this has not been set to a non zero value, Glassfish will not report
connection leaks.
Turn this on, reset your Glassfish server.... And then give it some time
and check your stats and logs again...
Robert
On Sun, Aug 17, 2025, 12:08 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Rob,
>
> A few years ago, I tried to upgrade to the then current version of
> Glassfish and couldn’t get it to work. I’m considering trying again with
> the current version.
>
> Dan
>
> From: Rob Sargent <rs...@xmission.com>
> Sent: Sunday, August 17, 2025 12:04 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Cc: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> > On Aug 17, 2025, at 9:45 AM, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote: > > In my previous posting, at
> the very end, I mentioned that I’m using jdk1.8.0_144 with Glassfish 4.1.
> That version of Glassfish won’t with anything
> NkdkJdXPPEBannerStart
> Be Careful With This Message
> From (Rob Sargent <rs...@xmission.com>)<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a501ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034c37a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18286a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71d09f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1cfda17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b9223f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> >
> Learn More<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a501ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034c37a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18286a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71d09f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1cfda17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b9223f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6
> >
> 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 Aug 17, 2025, at 9:45 AM, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote:
>
> >
>
> > In my previous posting, at the very end, I mentioned that I’m using
> jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t with
> anything later than 1.8.
>
> >
>
> > Dan
>
>
>
> Are these specs for glassfish and java requirements? A new jdk is an easy
> install and a current glassfish would be a real security enhancement.
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Rob,
A few years ago, I tried to upgrade to the then current version of Glassfish and couldn’t get it to work. I’m considering trying again with the current version.
Dan
From: Rob Sargent <rs...@xmission.com>
Sent: Sunday, August 17, 2025 12:04 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On Aug 17, 2025, at 9:45 AM, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > In my previous posting, at the very end, I mentioned that I’m using jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t with anything
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a501ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034c37a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18286a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71d09f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1cfda17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b9223f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fb70309feed1540f62bf005f376466654632bc67d49f0bed3805175f300a501ae2f740bb4af833d74c3785a23f41bdf314722f11baa7ef211e0e17b2cde5c1e034c37a2e487e93b6e168f982896f75359bfa9bc33e0f6f0964ba443f713b7ada4fb6ad18286a887356573683c9e4aef9025af8cb762ba72c9b9122add03ebdc078d6874c9afe71d09f54b8c08dee1776b2dc2f9ae1fe71e47d4d8c5b63ac920101f367cead12d29f0f1cfda17e934d5e1c8141ebeab30754937d86c5c118a22612f7381978a5a78f914c73210b9223f440e75ce7478819bda3bac4d72b9c5c7c950c13f1b5c8968d6>
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 Aug 17, 2025, at 9:45 AM, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> In my previous posting, at the very end, I mentioned that I’m using jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t with anything later than 1.8.
>
> Dan
Are these specs for glassfish and java requirements? A new jdk is an easy install and a current glassfish would be a real security enhancement.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
> On Aug 17, 2025, at 9:45 AM, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> In my previous posting, at the very end, I mentioned that I’m using jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t with anything later than 1.8.
>
> Dan
Are these specs for glassfish and java requirements? A new jdk is an easy install and a current glassfish would be a real security enhancement.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
In my previous posting, at the very end, I mentioned that I’m using jdk1.8.0_144 with Glassfish 4.1. That version of Glassfish won’t with anything later than 1.8.
Dan
From: Chuck Caldarale <n8...@gmail.com>
Sent: Saturday, August 16, 2025 3:58 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 16, at 14:52, Robert Turner <rt...@e-djuster.ca.INVALID>> wrote: > > On Sat, Aug 16, 2025, 15:44 Chuck Caldarale <n8...@gmail.com>> wrote: > >> Robert - >> >> (Sorry for top-posting,
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fd826f835b18e7338a04015f49a15b77653863ed0a15fa37ffc4f9894205136912099218a415a34a8ae189d273ade7bf93e5739fc7a770803286fa06b5f50c5277dd932c6c6d6a96007abf8fcc9dd54653431d0b42bb6c1c99874a0e848fca0e5be0e5182fc1206b39fc7aaa8978197723d6940e429952fd3371f324c6ef50f44aa0f1038a1a89ec337ba2c2b5fbc497ae56a80408831d910c0c7ab891b4114e2b6b4eb66e6464952b6293676c34aa1745bf2f09c40a60fc42b27d1429c85a392b85acf42a1d43be0654b8da320873d23500fb3d74c6fb8912f7e104712568f0e8777a337edcdbaf8>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fd826f835b18e7338a04015f49a15b77653863ed0a15fa37ffc4f9894205136912099218a415a34a8ae189d273ade7bf93e5739fc7a770803286fa06b5f50c5277dd932c6c6d6a96007abf8fcc9dd54653431d0b42bb6c1c99874a0e848fca0e5be0e5182fc1206b39fc7aaa8978197723d6940e429952fd3371f324c6ef50f44aa0f1038a1a89ec337ba2c2b5fbc497ae56a80408831d910c0c7ab891b4114e2b6b4eb66e6464952b6293676c34aa1745bf2f09c40a60fc42b27d1429c85a392b85acf42a1d43be0654b8da320873d23500fb3d74c6fb8912f7e104712568f0e8777a337edcdbaf8>
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 16, at 14:52, Robert Turner <rt...@e-djuster.ca.INVALID>> wrote:
>
> On Sat, Aug 16, 2025, 15:44 Chuck Caldarale <n8...@gmail.com>> wrote:
>
>> Robert -
>>
>> (Sorry for top-posting, but this is just about GlassFish 4.1, not Dan’s
>> problem.)
>>
>> GlassFish 4.1 is a bit hard to find these days, but it can be downloaded
>> from here: https://urldefense.proofpoint.com/v2/url?u=https-3A__javaee.github.io_glassfish_download&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=kcwcsXJW1KFHWbZPs5f2PiB8motHlu4wBFKFO8tq1mlpq9con6rdfRkHYhVBSr9Z&s=_KIYlbVezHnWB6M_6YL8idK2o098rn0x11VqikQDiFc&e=
>>
>> Also, 4.1 refuses to run on a modern JVM, resulting in this message:
>>
>> GlassFish requires Java SE version 6. Your JDK is version 0
>>
>> Mine is currently 23.0.2; not sure how far back one will have to go…
>
>
> Thanks for the heads up. That might be a bit tricky then... Maybe that
> won't happen then.
The README says it will run on JDK 8, but makes no mention of anything beyond that. I don’t remember what the current JVM was 11 years ago...
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 16, at 14:52, Robert Turner <rt...@e-djuster.ca.INVALID> wrote:
>
> On Sat, Aug 16, 2025, 15:44 Chuck Caldarale <n8...@gmail.com> wrote:
>
>> Robert -
>>
>> (Sorry for top-posting, but this is just about GlassFish 4.1, not Dan’s
>> problem.)
>>
>> GlassFish 4.1 is a bit hard to find these days, but it can be downloaded
>> from here: https://javaee.github.io/glassfish/download
>>
>> Also, 4.1 refuses to run on a modern JVM, resulting in this message:
>>
>> GlassFish requires Java SE version 6. Your JDK is version 0
>>
>> Mine is currently 23.0.2; not sure how far back one will have to go…
>
>
> Thanks for the heads up. That might be a bit tricky then... Maybe that
> won't happen then.
The README says it will run on JDK 8, but makes no mention of anything beyond that. I don’t remember what the current JVM was 11 years ago...
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
On Sat, Aug 16, 2025, 15:44 Chuck Caldarale <n8...@gmail.com> wrote:
> Robert -
>
> (Sorry for top-posting, but this is just about GlassFish 4.1, not Dan’s
> problem.)
>
> GlassFish 4.1 is a bit hard to find these days, but it can be downloaded
> from here: https://javaee.github.io/glassfish/download
>
> Also, 4.1 refuses to run on a modern JVM, resulting in this message:
>
> GlassFish requires Java SE version 6. Your JDK is version 0
>
> Mine is currently 23.0.2; not sure how far back one will have to go…
>
> - Chuck
>
Thanks for the heads up. That might be a bit tricky then... Maybe that
won't happen then.
>
>
> > On 2025 Aug 16, at 14:02, Robert Turner <rt...@e-djuster.ca.INVALID>
> wrote:
> >
> > Dan,
> >
> > You are doing well to keep up -- we keep throwing lots at you. I think we
> > all find this issue so bizarre we really want to figure it out. We are,
> > even if it doesn't look like it, slowly eliminating some potential
> causes.
> >
> > I've put a few comments inline, and then a larger update on some testing
> I
> > was doing this morning to try to reproduce what you are observing in your
> > live system.
> >
> > Questions / suggestions for Dan marked with @Dan
> >
> > On Sat, Aug 16, 2025 at 2:31 PM Chuck Caldarale <n828cl@gmail.com
> <ma...@gmail.com>> wrote:
> >
> >>
> >>> On 2025 Aug 16, at 12:44, Daniel Schwartz <da...@danielgschwartz.com>
> >> wrote:
> >>>
> >>> From: Chuck Caldarale <n8...@gmail.com>
> >>> Sent: Saturday, August 16, 2025 1:33 PM
> >>> To: Tomcat Users List <us...@tomcat.apache.org>
> >>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >>>
> >>>> Immediately after doing this, the message copied below started
> >> appearing repeatedly in the server.log and my website stopped
> working---the
> >> DB evidently became inaccessible. However, Glassfish was still running,
> >> and as soon as I set the maximum pool size back to 1000, these messages
> >> stopped coming and the website started working again.
> >>>
> >>> Indicative of an orphaned connection (resource leak).
> >>>
> >>> DGS: Why is this? What do those messages have to do with a resource
> >> leak?
> >>
> >>
> >> When the pool is at its maximum and all connections are in use,
> GlassFish
> >> will hold requests for a configurable amount of time (max-wait,
> defaults to
> >> 60 seconds), and only abort the request and log the situation after the
> >> caller has been suspended for that amount of time. Since your web
> service’s
> >> response time is very quick, this indicates the only allocated
> connection
> >> has stayed in-use for over a minute - something leaked it.
> >>
> >> When the maximum pool size is set to your usual value, GlassFish
> >> eventually cleans things up because it periodically discards all
> existing
> >> connections and acquires new ones just in case they have become unusable
> >> from the DB point of view.
> >>
> >
> > Just to add that there is another situation, but is unlikely based on the
> > default HTTP thread count maximums. It could be that you are getting a
> > large amount of connections faster than they can be processed -- i.e.
> let's
> > say 100 per 10 ms would overflow the connection pool if you had a limit
> of
> > 50 and your average response time was 10 ms. This was why I asked about
> > your settings for HTTP thread limits.
> >
> > I will check Glassfish 4.1 a bit later today, but with Glassfish 7.0.25
> > ("out of the box") the limit on the HTTP processing threads was 5, and
> > without increasing that, it's not possible to have more than 5 typical
> > requests being processed at once. That means that if each request never
> > acquires more than 1 connection (which is the case in all the examples
> you
> > have provided), the connection pool usage should never grow beyond 5.
> >
> > So, unless you have increased the HTTP processing thread limits from
> > defaults to a value larger than the default thread pool maximum size, or
> > the deployment you are using does such, you shouldn't have seen an issue
> > originally if all the connections are being released to the pool. The
> "peak
> > value", as tracked in Glassfish, should never exceed this thread count
> > unless a connection is not being returned to the pool.
> >
> > Thus, the conclusion that there is a leak somewhere, but where... I'm not
> > sure at this point.
> > This is where I think we need to focus on -- possibly by dialing back
> your
> > settings, and also by looking at what's going on with the robot requests
> --
> > are they causing faults that aren't visible"?
> > (more on this at the end)
> >
> > @Dan: It would be a really good idea though (as it's been said, and been
> > acknowledged) to wrap all the connection / statement / result-set
> > acquisitions with try-with-resources. Not only will it rule out leaks
> from
> > those going forward, it will also simplify your code and make it easier
> to
> > read. I would do this sooner so we can try to rule out leaks from those
> > activities.
> >
> >
> >
> >>
> >>> So this is very interesting, and points to a possible line of
> >> investigation. If the web crawlers are throwing garbage at your app,
> that
> >> could possibly be resulting in losing track of connections, statements,
> >> result sets, etc. You should carefully check your error paths and make
> sure
> >> that all DB-related resources are being properly disposed of when
> invalid
> >> input is received.
> >>>
> >>> DGS: I'm fairly sure that all connections and prepared statements are
> >> being closed, but will look again. This would be happening in the code
> >> fragment that tries to retrieve the list of holidays with calculated
> dates
> >> (not the countries). This is somewhat complex and could have problems.
> >>
> >>
> >> Your GetCountryList code from a previous message doesn’t dispose of the
> >> ResultSet object; depending on the implementation details of the JDBC
> >> driver and pool, closing the result set may not be required, but it’s
> >> always good practice to do so. Since the ResultSet object contains a
> >> reference to the Connection (and vice-versa), it may be interfering with
> >> reuse of the connection until a garbage collection happens.
> >>
> >
> >
> > Okay, so while I was in between things this morning I did a whole bunch
> of
> > testing.
> >
> > With Glassfish 7.0.25, with JDK 21, and the latest PostgreSQL JDBC
> driver,
> > I was unable to reproduce the "leak" problem using code very similar to
> > Dan's.
> >
> > I tried all of the following:
> > - enabling and disabling the JDBC object wrapping in Glassfish
> > - using the "singleton" data source or retrieving one each request
> > - not closing the Statement or the ResultSet / or closing them
> > - not closing the Connection or closing it
> >
> > The only situation where I could reproduce a leak (and very quickly) was
> to
> > fail to close the connection. (remove it from the try-with-resources
> > block). I could not get the lack of closing the ResultSet or the
> Statement
> > to trigger a "leak" in the connection pool -- but that doesn't mean one
> can
> > ignore that, only that it didn't definitely cause the issue in my test
> > setup.
> >
> > I was not however running any "real queries". I was just running "SELECT
> 1"
> > each time and returning the integer to the caller. So no data was coming
> > from the client that could be triggering other potential failures.
> >
> > My next plan is to switch to MySQL JDBC (as I noted this is what Dan is
> > using) and see if maybe there is something different with that JDBC
> driver
> > and do the same tests.
> >
> > @Dan: Could you share the exact version of the JDBC driver you are using?
> >
> > And then, I'll try rolling back to Glassfish 4.1.x and see if that makes
> a
> > difference.
> >
> > @Dan: Is there a minor version, or is it 4.1.latest ?
> >
> >
> > Dan: it would also be a good idea to "verify" the parameters coming in
> for
> > "valid values" without using a DB query (if that is possible) so as to
> > avoid the robots triggering DB connections. Ultimately this is a risk of
> a
> > DoS type of attack. You can also employ rate limiting as well to help
> avoid
> > such problems.
> >
> > @Dan: I think we also need to change your "printing to Stdout" to print
> to
> > the Glassfish logger. The problem with printing to Stdout is that only
> the
> > HTTP client making the request that triggers these logs will see them.
> This
> > could be "masking" some errors where you aren't doing the testing
> yourself.
> > (I could be wrong about where Stdout output goes though -- so if you do
> see
> > those in the logs, then ignore this item. I will validate that shortly
> > myself in Glassfish 7.0.25).
> >
> > @Dan: Have you been able to get a rough count of the request rate you are
> > seeing on your server, so we have some idea if it's even possible to be
> > seeing an overload situation or if we can rule that out.
> >
> >
> > Robert
> > (who is clearly spending way too much time on Dan's issue, but is very
> > puzzled and wants to get to the bottom of it, and as a result has now
> used
> > Glassfish for the first time... :) )
>
>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
Robert -
(Sorry for top-posting, but this is just about GlassFish 4.1, not Dan’s problem.)
GlassFish 4.1 is a bit hard to find these days, but it can be downloaded from here: https://javaee.github.io/glassfish/download
Also, 4.1 refuses to run on a modern JVM, resulting in this message:
GlassFish requires Java SE version 6. Your JDK is version 0
Mine is currently 23.0.2; not sure how far back one will have to go…
- Chuck
> On 2025 Aug 16, at 14:02, Robert Turner <rt...@e-djuster.ca.INVALID> wrote:
>
> Dan,
>
> You are doing well to keep up -- we keep throwing lots at you. I think we
> all find this issue so bizarre we really want to figure it out. We are,
> even if it doesn't look like it, slowly eliminating some potential causes.
>
> I've put a few comments inline, and then a larger update on some testing I
> was doing this morning to try to reproduce what you are observing in your
> live system.
>
> Questions / suggestions for Dan marked with @Dan
>
> On Sat, Aug 16, 2025 at 2:31 PM Chuck Caldarale <n828cl@gmail.com <ma...@gmail.com>> wrote:
>
>>
>>> On 2025 Aug 16, at 12:44, Daniel Schwartz <da...@danielgschwartz.com>
>> wrote:
>>>
>>> From: Chuck Caldarale <n8...@gmail.com>
>>> Sent: Saturday, August 16, 2025 1:33 PM
>>> To: Tomcat Users List <us...@tomcat.apache.org>
>>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>>
>>>> Immediately after doing this, the message copied below started
>> appearing repeatedly in the server.log and my website stopped working---the
>> DB evidently became inaccessible. However, Glassfish was still running,
>> and as soon as I set the maximum pool size back to 1000, these messages
>> stopped coming and the website started working again.
>>>
>>> Indicative of an orphaned connection (resource leak).
>>>
>>> DGS: Why is this? What do those messages have to do with a resource
>> leak?
>>
>>
>> When the pool is at its maximum and all connections are in use, GlassFish
>> will hold requests for a configurable amount of time (max-wait, defaults to
>> 60 seconds), and only abort the request and log the situation after the
>> caller has been suspended for that amount of time. Since your web service’s
>> response time is very quick, this indicates the only allocated connection
>> has stayed in-use for over a minute - something leaked it.
>>
>> When the maximum pool size is set to your usual value, GlassFish
>> eventually cleans things up because it periodically discards all existing
>> connections and acquires new ones just in case they have become unusable
>> from the DB point of view.
>>
>
> Just to add that there is another situation, but is unlikely based on the
> default HTTP thread count maximums. It could be that you are getting a
> large amount of connections faster than they can be processed -- i.e. let's
> say 100 per 10 ms would overflow the connection pool if you had a limit of
> 50 and your average response time was 10 ms. This was why I asked about
> your settings for HTTP thread limits.
>
> I will check Glassfish 4.1 a bit later today, but with Glassfish 7.0.25
> ("out of the box") the limit on the HTTP processing threads was 5, and
> without increasing that, it's not possible to have more than 5 typical
> requests being processed at once. That means that if each request never
> acquires more than 1 connection (which is the case in all the examples you
> have provided), the connection pool usage should never grow beyond 5.
>
> So, unless you have increased the HTTP processing thread limits from
> defaults to a value larger than the default thread pool maximum size, or
> the deployment you are using does such, you shouldn't have seen an issue
> originally if all the connections are being released to the pool. The "peak
> value", as tracked in Glassfish, should never exceed this thread count
> unless a connection is not being returned to the pool.
>
> Thus, the conclusion that there is a leak somewhere, but where... I'm not
> sure at this point.
> This is where I think we need to focus on -- possibly by dialing back your
> settings, and also by looking at what's going on with the robot requests --
> are they causing faults that aren't visible"?
> (more on this at the end)
>
> @Dan: It would be a really good idea though (as it's been said, and been
> acknowledged) to wrap all the connection / statement / result-set
> acquisitions with try-with-resources. Not only will it rule out leaks from
> those going forward, it will also simplify your code and make it easier to
> read. I would do this sooner so we can try to rule out leaks from those
> activities.
>
>
>
>>
>>> So this is very interesting, and points to a possible line of
>> investigation. If the web crawlers are throwing garbage at your app, that
>> could possibly be resulting in losing track of connections, statements,
>> result sets, etc. You should carefully check your error paths and make sure
>> that all DB-related resources are being properly disposed of when invalid
>> input is received.
>>>
>>> DGS: I'm fairly sure that all connections and prepared statements are
>> being closed, but will look again. This would be happening in the code
>> fragment that tries to retrieve the list of holidays with calculated dates
>> (not the countries). This is somewhat complex and could have problems.
>>
>>
>> Your GetCountryList code from a previous message doesn’t dispose of the
>> ResultSet object; depending on the implementation details of the JDBC
>> driver and pool, closing the result set may not be required, but it’s
>> always good practice to do so. Since the ResultSet object contains a
>> reference to the Connection (and vice-versa), it may be interfering with
>> reuse of the connection until a garbage collection happens.
>>
>
>
> Okay, so while I was in between things this morning I did a whole bunch of
> testing.
>
> With Glassfish 7.0.25, with JDK 21, and the latest PostgreSQL JDBC driver,
> I was unable to reproduce the "leak" problem using code very similar to
> Dan's.
>
> I tried all of the following:
> - enabling and disabling the JDBC object wrapping in Glassfish
> - using the "singleton" data source or retrieving one each request
> - not closing the Statement or the ResultSet / or closing them
> - not closing the Connection or closing it
>
> The only situation where I could reproduce a leak (and very quickly) was to
> fail to close the connection. (remove it from the try-with-resources
> block). I could not get the lack of closing the ResultSet or the Statement
> to trigger a "leak" in the connection pool -- but that doesn't mean one can
> ignore that, only that it didn't definitely cause the issue in my test
> setup.
>
> I was not however running any "real queries". I was just running "SELECT 1"
> each time and returning the integer to the caller. So no data was coming
> from the client that could be triggering other potential failures.
>
> My next plan is to switch to MySQL JDBC (as I noted this is what Dan is
> using) and see if maybe there is something different with that JDBC driver
> and do the same tests.
>
> @Dan: Could you share the exact version of the JDBC driver you are using?
>
> And then, I'll try rolling back to Glassfish 4.1.x and see if that makes a
> difference.
>
> @Dan: Is there a minor version, or is it 4.1.latest ?
>
>
> Dan: it would also be a good idea to "verify" the parameters coming in for
> "valid values" without using a DB query (if that is possible) so as to
> avoid the robots triggering DB connections. Ultimately this is a risk of a
> DoS type of attack. You can also employ rate limiting as well to help avoid
> such problems.
>
> @Dan: I think we also need to change your "printing to Stdout" to print to
> the Glassfish logger. The problem with printing to Stdout is that only the
> HTTP client making the request that triggers these logs will see them. This
> could be "masking" some errors where you aren't doing the testing yourself.
> (I could be wrong about where Stdout output goes though -- so if you do see
> those in the logs, then ignore this item. I will validate that shortly
> myself in Glassfish 7.0.25).
>
> @Dan: Have you been able to get a rough count of the request rate you are
> seeing on your server, so we have some idea if it's even possible to be
> seeing an overload situation or if we can rule that out.
>
>
> Robert
> (who is clearly spending way too much time on Dan's issue, but is very
> puzzled and wants to get to the bottom of it, and as a result has now used
> Glassfish for the first time... :) )
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Dan,
You are doing well to keep up -- we keep throwing lots at you. I think we
all find this issue so bizarre we really want to figure it out. We are,
even if it doesn't look like it, slowly eliminating some potential causes.
I've put a few comments inline, and then a larger update on some testing I
was doing this morning to try to reproduce what you are observing in your
live system.
Questions / suggestions for Dan marked with @Dan
On Sat, Aug 16, 2025 at 2:31 PM Chuck Caldarale <n8...@gmail.com> wrote:
>
> > On 2025 Aug 16, at 12:44, Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
> >
> > From: Chuck Caldarale <n8...@gmail.com>
> > Sent: Saturday, August 16, 2025 1:33 PM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> >
> >> Immediately after doing this, the message copied below started
> appearing repeatedly in the server.log and my website stopped working---the
> DB evidently became inaccessible. However, Glassfish was still running,
> and as soon as I set the maximum pool size back to 1000, these messages
> stopped coming and the website started working again.
> >
> > Indicative of an orphaned connection (resource leak).
> >
> > DGS: Why is this? What do those messages have to do with a resource
> leak?
>
>
> When the pool is at its maximum and all connections are in use, GlassFish
> will hold requests for a configurable amount of time (max-wait, defaults to
> 60 seconds), and only abort the request and log the situation after the
> caller has been suspended for that amount of time. Since your web service’s
> response time is very quick, this indicates the only allocated connection
> has stayed in-use for over a minute - something leaked it.
>
> When the maximum pool size is set to your usual value, GlassFish
> eventually cleans things up because it periodically discards all existing
> connections and acquires new ones just in case they have become unusable
> from the DB point of view.
>
Just to add that there is another situation, but is unlikely based on the
default HTTP thread count maximums. It could be that you are getting a
large amount of connections faster than they can be processed -- i.e. let's
say 100 per 10 ms would overflow the connection pool if you had a limit of
50 and your average response time was 10 ms. This was why I asked about
your settings for HTTP thread limits.
I will check Glassfish 4.1 a bit later today, but with Glassfish 7.0.25
("out of the box") the limit on the HTTP processing threads was 5, and
without increasing that, it's not possible to have more than 5 typical
requests being processed at once. That means that if each request never
acquires more than 1 connection (which is the case in all the examples you
have provided), the connection pool usage should never grow beyond 5.
So, unless you have increased the HTTP processing thread limits from
defaults to a value larger than the default thread pool maximum size, or
the deployment you are using does such, you shouldn't have seen an issue
originally if all the connections are being released to the pool. The "peak
value", as tracked in Glassfish, should never exceed this thread count
unless a connection is not being returned to the pool.
Thus, the conclusion that there is a leak somewhere, but where... I'm not
sure at this point.
This is where I think we need to focus on -- possibly by dialing back your
settings, and also by looking at what's going on with the robot requests --
are they causing faults that aren't visible"?
(more on this at the end)
@Dan: It would be a really good idea though (as it's been said, and been
acknowledged) to wrap all the connection / statement / result-set
acquisitions with try-with-resources. Not only will it rule out leaks from
those going forward, it will also simplify your code and make it easier to
read. I would do this sooner so we can try to rule out leaks from those
activities.
>
> > So this is very interesting, and points to a possible line of
> investigation. If the web crawlers are throwing garbage at your app, that
> could possibly be resulting in losing track of connections, statements,
> result sets, etc. You should carefully check your error paths and make sure
> that all DB-related resources are being properly disposed of when invalid
> input is received.
> >
> > DGS: I'm fairly sure that all connections and prepared statements are
> being closed, but will look again. This would be happening in the code
> fragment that tries to retrieve the list of holidays with calculated dates
> (not the countries). This is somewhat complex and could have problems.
>
>
> Your GetCountryList code from a previous message doesn’t dispose of the
> ResultSet object; depending on the implementation details of the JDBC
> driver and pool, closing the result set may not be required, but it’s
> always good practice to do so. Since the ResultSet object contains a
> reference to the Connection (and vice-versa), it may be interfering with
> reuse of the connection until a garbage collection happens.
>
Okay, so while I was in between things this morning I did a whole bunch of
testing.
With Glassfish 7.0.25, with JDK 21, and the latest PostgreSQL JDBC driver,
I was unable to reproduce the "leak" problem using code very similar to
Dan's.
I tried all of the following:
- enabling and disabling the JDBC object wrapping in Glassfish
- using the "singleton" data source or retrieving one each request
- not closing the Statement or the ResultSet / or closing them
- not closing the Connection or closing it
The only situation where I could reproduce a leak (and very quickly) was to
fail to close the connection. (remove it from the try-with-resources
block). I could not get the lack of closing the ResultSet or the Statement
to trigger a "leak" in the connection pool -- but that doesn't mean one can
ignore that, only that it didn't definitely cause the issue in my test
setup.
I was not however running any "real queries". I was just running "SELECT 1"
each time and returning the integer to the caller. So no data was coming
from the client that could be triggering other potential failures.
My next plan is to switch to MySQL JDBC (as I noted this is what Dan is
using) and see if maybe there is something different with that JDBC driver
and do the same tests.
@Dan: Could you share the exact version of the JDBC driver you are using?
And then, I'll try rolling back to Glassfish 4.1.x and see if that makes a
difference.
@Dan: Is there a minor version, or is it 4.1.latest ?
Dan: it would also be a good idea to "verify" the parameters coming in for
"valid values" without using a DB query (if that is possible) so as to
avoid the robots triggering DB connections. Ultimately this is a risk of a
DoS type of attack. You can also employ rate limiting as well to help avoid
such problems.
@Dan: I think we also need to change your "printing to Stdout" to print to
the Glassfish logger. The problem with printing to Stdout is that only the
HTTP client making the request that triggers these logs will see them. This
could be "masking" some errors where you aren't doing the testing yourself.
(I could be wrong about where Stdout output goes though -- so if you do see
those in the logs, then ignore this item. I will validate that shortly
myself in Glassfish 7.0.25).
@Dan: Have you been able to get a rough count of the request rate you are
seeing on your server, so we have some idea if it's even possible to be
seeing an overload situation or if we can rule that out.
Robert
(who is clearly spending way too much time on Dan's issue, but is very
puzzled and wants to get to the bottom of it, and as a result has now used
Glassfish for the first time... :) )
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 16, at 12:44, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Saturday, August 16, 2025 1:33 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
>> Immediately after doing this, the message copied below started appearing repeatedly in the server.log and my website stopped working---the DB evidently became inaccessible. However, Glassfish was still running, and as soon as I set the maximum pool size back to 1000, these messages stopped coming and the website started working again.
>
> Indicative of an orphaned connection (resource leak).
>
> DGS: Why is this? What do those messages have to do with a resource leak?
When the pool is at its maximum and all connections are in use, GlassFish will hold requests for a configurable amount of time (max-wait, defaults to 60 seconds), and only abort the request and log the situation after the caller has been suspended for that amount of time. Since your web service’s response time is very quick, this indicates the only allocated connection has stayed in-use for over a minute - something leaked it.
When the maximum pool size is set to your usual value, GlassFish eventually cleans things up because it periodically discards all existing connections and acquires new ones just in case they have become unusable from the DB point of view.
> So this is very interesting, and points to a possible line of investigation. If the web crawlers are throwing garbage at your app, that could possibly be resulting in losing track of connections, statements, result sets, etc. You should carefully check your error paths and make sure that all DB-related resources are being properly disposed of when invalid input is received.
>
> DGS: I'm fairly sure that all connections and prepared statements are being closed, but will look again. This would be happening in the code fragment that tries to retrieve the list of holidays with calculated dates (not the countries). This is somewhat complex and could have problems.
Your GetCountryList code from a previous message doesn’t dispose of the ResultSet object; depending on the implementation details of the JDBC driver and pool, closing the result set may not be required, but it’s always good practice to do so. Since the ResultSet object contains a reference to the Connection (and vice-versa), it may be interfering with reuse of the connection until a garbage collection happens.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
From: Chuck Caldarale <n8...@gmail.com>
Sent: Saturday, August 16, 2025 1:33 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 16, at 12:21, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > I just sent a code fragment where I retrieve a list of countries from the DB, so won't repeat this here. However, I did find that I was mistaken
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5ffab89210efad9b957b503d2c7757e4c4dc7e5dc6cdf307022ef6ec039d2dab5436a20969caafccaef778a3287724416a8f17767fb01350cdf780beee54344117d85c6b54d82e9c0342155b579f291dd499772a2b1fb601f21864e80de3b03445150df3ed0ea3a7381e32e1d6f9bd241c20217f5446446f771d02e2405a1a58df7c3aef39d01e88fc9a051c9138bb3c12ad55ddb9302b25466ab3442b4b9ab3c5ffcf743c945135c12f5d0c957d5994d2f89a182ad9fac85bcd71c64bec17f5019edc5b4d21c43bf1f9bd487d6817712584f976c5b52d3dbedb83ab2d3f5169b17bea452febd1621a>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5ffab89210efad9b957b503d2c7757e4c4dc7e5dc6cdf307022ef6ec039d2dab5436a20969caafccaef778a3287724416a8f17767fb01350cdf780beee54344117d85c6b54d82e9c0342155b579f291dd499772a2b1fb601f21864e80de3b03445150df3ed0ea3a7381e32e1d6f9bd241c20217f5446446f771d02e2405a1a58df7c3aef39d01e88fc9a051c9138bb3c12ad55ddb9302b25466ab3442b4b9ab3c5ffcf743c945135c12f5d0c957d5994d2f89a182ad9fac85bcd71c64bec17f5019edc5b4d21c43bf1f9bd487d6817712584f976c5b52d3dbedb83ab2d3f5169b17bea452febd1621a>
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 16, at 12:21, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> I just sent a code fragment where I retrieve a list of countries from the DB, so won't repeat this here. However, I did find that I was mistaken in saying that Glassfish won't accept a minimum pool size less than 8. I don't know what happened before, but today I was able to set both the minimum and maximum to 1.
Good.
> Immediately after doing this, the message copied below started appearing repeatedly in the server.log and my website stopped working---the DB evidently became inaccessible. However, Glassfish was still running, and as soon as I set the maximum pool size back to 1000, these messages stopped coming and the website started working again.
Indicative of an orphaned connection (resource leak).
DGS: Why is this? What do those messages have to do with a resource leak?
> I have no idea what all this means, but I think that the message copied below was generated each time some web crawler was submitting a query. These come quite frequently.
>
> By the way, I don't know how they do this, but the web crawlers somehow figured out that I submit queries to the web service using Get requests, with parameters for "country", "state", "city", "year", and are creating bogus queries by randomly filling these in, usually with values that don't make any sense, like "country=England", "state=England", "city=Scotland", and "year=2087". These queries won't return any results, but they do initiate a DB connection. These are happening many times every day.
So this is very interesting, and points to a possible line of investigation. If the web crawlers are throwing garbage at your app, that could possibly be resulting in losing track of connections, statements, result sets, etc. You should carefully check your error paths and make sure that all DB-related resources are being properly disposed of when invalid input is received.
DGS: I'm fairly sure that all connections and prepared statements are being closed, but will look again. This would be happening in the code fragment that tries to retrieve the list of holidays with calculated dates (not the countries). This is somewhat complex and could have problems.
> -------------------------------------------------------------------------------
>
> [2025-08-16T16:54:23.735+0000] [glassfish 4.1] [WARNING] [poolmgr.get_connection_failure] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors] [tid: _ThreadID=30 _ThreadName=http-listener-1(4)] [timeMillis: 1755363263735] [levelValue: 900] [[
> RAR5117 : Failed to obtain/create connection from connection pool [ HolidaysConnectionPool ]. Reason : com.sun.appserv.connectors.internal.api.PoolingException: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.]]
>
> [2025-08-16T16:54:23.735+0000] [glassfish 4.1] [WARNING] [jdbc.exc_get_conn] [javax.enterprise.resource.resourceadapter.com.sun.gjc.spi] [tid: _ThreadID=30 _ThreadName=http-listener-1(4)] [timeMillis: 1755363263735] [levelValue: 900] [[
> RAR5114 : Error allocating connection : [Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.]]]
>
> [2025-08-16T16:54:23.735+0000] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=30 _ThreadName=Thread-8] [timeMillis: 1755363263735] [levelValue: 800] [[
> [Ljava.lang.StackTraceElement;@2545fa37]]
- Chuck
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 16, at 12:21, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> I just sent a code fragment where I retrieve a list of countries from the DB, so won't repeat this here. However, I did find that I was mistaken in saying that Glassfish won't accept a minimum pool size less than 8. I don't know what happened before, but today I was able to set both the minimum and maximum to 1.
Good.
> Immediately after doing this, the message copied below started appearing repeatedly in the server.log and my website stopped working---the DB evidently became inaccessible. However, Glassfish was still running, and as soon as I set the maximum pool size back to 1000, these messages stopped coming and the website started working again.
Indicative of an orphaned connection (resource leak).
> I have no idea what all this means, but I think that the message copied below was generated each time some web crawler was submitting a query. These come quite frequently.
>
> By the way, I don't know how they do this, but the web crawlers somehow figured out that I submit queries to the web service using Get requests, with parameters for "country", "state", "city", "year", and are creating bogus queries by randomly filling these in, usually with values that don't make any sense, like "country=England", "state=England", "city=Scotland", and "year=2087". These queries won't return any results, but they do initiate a DB connection. These are happening many times every day.
So this is very interesting, and points to a possible line of investigation. If the web crawlers are throwing garbage at your app, that could possibly be resulting in losing track of connections, statements, result sets, etc. You should carefully check your error paths and make sure that all DB-related resources are being properly disposed of when invalid input is received.
> -------------------------------------------------------------------------------
>
> [2025-08-16T16:54:23.735+0000] [glassfish 4.1] [WARNING] [poolmgr.get_connection_failure] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors] [tid: _ThreadID=30 _ThreadName=http-listener-1(4)] [timeMillis: 1755363263735] [levelValue: 900] [[
> RAR5117 : Failed to obtain/create connection from connection pool [ HolidaysConnectionPool ]. Reason : com.sun.appserv.connectors.internal.api.PoolingException: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.]]
>
> [2025-08-16T16:54:23.735+0000] [glassfish 4.1] [WARNING] [jdbc.exc_get_conn] [javax.enterprise.resource.resourceadapter.com.sun.gjc.spi] [tid: _ThreadID=30 _ThreadName=http-listener-1(4)] [timeMillis: 1755363263735] [levelValue: 900] [[
> RAR5114 : Error allocating connection : [Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.]]]
>
> [2025-08-16T16:54:23.735+0000] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=30 _ThreadName=Thread-8] [timeMillis: 1755363263735] [levelValue: 800] [[
> [Ljava.lang.StackTraceElement;@2545fa37]]
- Chuck
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Robert, Chuck, Rob,
I have received six emails from you today. Rather than replying to each one individually, I'll try to cover most of them here. However, several of you have asked questions that I don't know how to answer. You are all a level or two over my head. But I'm learning.
I just sent a code fragment where I retrieve a list of countries from the DB, so won't repeat this here. However, I did find that I was mistaken in saying that Glassfish won't accept a minimum pool size less than 8. I don't know what happened before, but today I was able to set both the minimum and maximum to 1. Immediately after doing this, the message copied below started appearing repeatedly in the server.log and my website stopped working---the DB evidently became inaccessible. However, Glassfish was still running, and as soon as I set the maximum pool size back to 1000, these messages stopped coming and the website started working again.
I have no idea what all this means, but I think that the message copied below was generated each time some web crawler was submitting a query. These come quite frequently.
By the way, I don't know how they do this, but the web crawlers somehow figured out that I submit queries to the web service using Get requests, with parameters for "country", "state", "city", "year", and are creating bogus queries by randomly filling these in, usually with values that don't make any sense, like "country=England", "state=England", "city=Scotland", and "year=2087". These queries won't return any results, but they do initiate a DB connection. These are happening many times every day.
Dan
-------------------------------------------------------------------------------
[2025-08-16T16:54:23.735+0000] [glassfish 4.1] [WARNING] [poolmgr.get_connection_failure] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors] [tid: _ThreadID=30 _ThreadName=http-listener-1(4)] [timeMillis: 1755363263735] [levelValue: 900] [[
RAR5117 : Failed to obtain/create connection from connection pool [ HolidaysConnectionPool ]. Reason : com.sun.appserv.connectors.internal.api.PoolingException: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.]]
[2025-08-16T16:54:23.735+0000] [glassfish 4.1] [WARNING] [jdbc.exc_get_conn] [javax.enterprise.resource.resourceadapter.com.sun.gjc.spi] [tid: _ThreadID=30 _ThreadName=http-listener-1(4)] [timeMillis: 1755363263735] [levelValue: 900] [[
RAR5114 : Error allocating connection : [Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections.]]]
[2025-08-16T16:54:23.735+0000] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=30 _ThreadName=Thread-8] [timeMillis: 1755363263735] [levelValue: 800] [[
[Ljava.lang.StackTraceElement;@2545fa37]]
----------------------------------------------------------------------------------
From: Chuck Caldarale <n8...@gmail.com>
Sent: Saturday, August 16, 2025 1:11 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 16, at 11:20, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > You might be using a different version of Glassfish. I have 4.1 (which I realize is old). It won't let you set the minimum pool size to less than
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fb68816cf49614cda4f16318311f3923530b283fd298b84fc1b98ffd5d5149175a07de6c4ae167e0908052df4454a6d44816c8ad875812516f324216fbba463bd871fa91f47849f28b81ae03e65c3472afe5c68ef717c37340d928a0302a57cf97746ddfa09d92e48cbdeac324ac458fd1ff6e370b30266a351c879bd633dc9fb5e34bcf576711fbe7d23ccee7dba4790e5713a1b088e971f402af170d22ece0573f0bb5becac2bc684e5f49b7ebb8e40a40a47cb159fcf1837845728f86d7802889b923c952434ac6b7205465dbf12e84413d1bb8dd40dc6d942611c97110071a2423164f3043223>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fb68816cf49614cda4f16318311f3923530b283fd298b84fc1b98ffd5d5149175a07de6c4ae167e0908052df4454a6d44816c8ad875812516f324216fbba463bd871fa91f47849f28b81ae03e65c3472afe5c68ef717c37340d928a0302a57cf97746ddfa09d92e48cbdeac324ac458fd1ff6e370b30266a351c879bd633dc9fb5e34bcf576711fbe7d23ccee7dba4790e5713a1b088e971f402af170d22ece0573f0bb5becac2bc684e5f49b7ebb8e40a40a47cb159fcf1837845728f86d7802889b923c952434ac6b7205465dbf12e84413d1bb8dd40dc6d942611c97110071a2423164f3043223>
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 16, at 11:20, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> You might be using a different version of Glassfish. I have 4.1 (which I realize is old). It won't let you set the minimum pool size to less than 8.
Did you actually set the minimum (steady-pool-size) or did you just try changing max-pool-size to 1? You cannot lower the maximum below the value of steady-pool-size.
> If you try to do this, it reports an error and won't let you proceed. The simple test I ran shows that it is creating 8 physical connections for each logical connection.
Again, your conclusion is incorrect. The pool is creating 8 connections because that’s what the minimum is set to. Testing with a delay in your web service code between the connection acquisition and close calls - as Robert T already did - will show the pool size not growing beyond 8 until there are more than 8 concurrent requests being processed.
> This is clearly stated by the monitoring report, and you can’t disagree with that.
The report only shows that 8 connections have been created; there is no indication in the report of anything else.
> I have considered upgrading to a newer version of Glassfish, but this would be another project that I'm not prepared to undertake right now.
But you apparently are prepared to handle all the security risks of running a 11-year old server exposed to the internet. Bad tradeoff.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 16, at 11:20, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> You might be using a different version of Glassfish. I have 4.1 (which I realize is old). It won't let you set the minimum pool size to less than 8.
Did you actually set the minimum (steady-pool-size) or did you just try changing max-pool-size to 1? You cannot lower the maximum below the value of steady-pool-size.
> If you try to do this, it reports an error and won't let you proceed. The simple test I ran shows that it is creating 8 physical connections for each logical connection.
Again, your conclusion is incorrect. The pool is creating 8 connections because that’s what the minimum is set to. Testing with a delay in your web service code between the connection acquisition and close calls - as Robert T already did - will show the pool size not growing beyond 8 until there are more than 8 concurrent requests being processed.
> This is clearly stated by the monitoring report, and you can’t disagree with that.
The report only shows that 8 connections have been created; there is no indication in the report of anything else.
> I have considered upgrading to a newer version of Glassfish, but this would be another project that I'm not prepared to undertake right now.
But you apparently are prepared to handle all the security risks of running a 11-year old server exposed to the internet. Bad tradeoff.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hi Robert,
You might be using a different version of Glassfish. I have 4.1 (which I realize is old). It won't let you set the minimum pool size to less than 8. If you try to do this, it reports an error and won't let you proceed. The simple test I ran shows that it is creating 8 physical connections for each logical connection. This is clearly stated by the monitoring report, and you can’t disagree with that.
I have considered upgrading to a newer version of Glassfish, but this would be another project that I'm not prepared to undertake right now. The simple fact is that what I have now seem to be working, so I don't see any point in making major changes.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Saturday, August 16, 2025 12:35 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Dan,
FWIW, I just set up test Glassfish server, and made a trivial app to acquire and release a connection from the pool.
I configured the connection with a minimum and starting size of 1.
I tested with 1 connection, and it did exactly what I expected. Acquired and released 1 connection. No more connections were allocated.
The setting for the minimum size is also the initial size (no surprise), and I could set that value to 1.
My code to acquire the connection was this trivial code:
final InitialContext ic = new InitialContext(); final DataSource ds = (DataSource) ic.lookup("test1"); try (Connection conn = ds.getConnection()) { } catch (SQLException e) {
throw new Runtime exception(e);
}
So, I don't agree with your "conclusion" about 8 connections per.
Robert
On Sat, Aug 16, 2025, 00:02 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Chuck,
>
> Okay, here is the text of the attachment.
>
> Instance Name:
> server
>
>
>
>
> Resource : HolidaysConnectionPool Application :
> HolidaysRESTJSON-1.0-SNAPSHOT
>
> Monitor (14 Statistics)
> JDBC Connection Pool Statistics : HolidaysConnectionPool Name Value
> Start Time Last Sample Time Details Description NumConnCreated
> 8 count
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> --
> The number of physical connections that were created since the last reset.
> NumConnFree
> 8count
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> High Water Mark: 8 count
> Low Water Mark: 0 count
> The total number of free connections in the pool as of the last sampling.
> NumConnReleased
> 1 count
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> --
> Number of logical connections released to the pool.
> NumPotentialConnLeak
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of potential connection leaks
> NumConnFailedValidation
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> The total number of connections in the connection pool that failed
> validation from the start time until the last sample time.
> ConnRequestWaitTime
> 485millisecond
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> High Water Mark: 485 millisecond
> Low Water Mark: 0 millisecond
> The longest and shortest wait times of connection requests. The
> current value indicates the wait time of the last request that was
> serviced by the pool.
> NumConnAcquired
> 1 count
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> --
> Number of logical connections acquired from the pool.
> AverageConnWaitTime
> 485 millisecond
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:33 AM
> --
> Average wait-time-duration per successful connection request
> NumConnDestroyed
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of physical connections that were destroyed since the last reset.
> NumConnSuccessfullyMatched
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of connections succesfully matched
> NumConnNotSuccessfullyMatched
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of connections rejected during matching NumConnUsed 0count Aug
> 15, 2025 1:26:20 AM Aug 15, 2025 1:26:21 AM High Water Mark: 1 count
> Low Water Mark: 0 count Provides connection usage statistics. The
> total number of connections that are currently being used, as well as
> information about the maximum number of connections that were used
> (the high water mark).
> WaitQueueLength
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of connection requests in the queue waiting to be serviced.
> NumConnTimedOut
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> The total number of connections in the pool that timed out between the
> start time and the last sample time.
>
> Regarding your statement "What is more likely is that the GlassFish
> connection pool simply initializes the configured minimum number of
> connections on the first attempt to acquire a connection.", I have no
> idea hat this means.
>
> Dan
>
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Friday, August 15, 2025 11:39 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> > On 2025 Aug 15, at 22:03, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote: > > I think I found the answer.
> > > A few days ago, someone suggested that I try setting the Glassfish
> maximum pool size to 1 and see what happens.
> NkdkJdXPPEBannerStart
> Be Careful With This Message
> From (Chuck Caldarale <n8...@gmail.com>)<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d
> 9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98b
> d9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce
> 43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156
> e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d
> 680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2c
> f6cf872584c675598f814ea3508244febcc34102818eff6415cdd
> >
> Learn More<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d
> 9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98b
> d9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce
> 43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156
> e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d
> 680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2c
> f6cf872584c675598f814ea3508244febcc34102818eff6415cdd
> >
> 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 15, at 22:03, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote:
>
> >
>
> > I think I found the answer.
>
> >
>
> > A few days ago, someone suggested that I try setting the Glassfish
> maximum pool size to 1 and see what happens. I reported back that in
> Glassfish the minimum pool size is 8, to which someone responded that
> this seems strange. I really didn't know. But now I do.
>
> >
>
> > Today I decided to run a test where I cleared out Glassfish so I
> > could
> start from scratch. I executed one REST request using the URL I
> posted recently, which returns a list of countries. Then I looked at
> the Glassfish JDBC pool monitor. A PDF of this is attached.
>
>
>
>
>
> The list strips nearly all attachments, for safely reasons. You need
> to post the text.
>
>
>
>
>
> > You will see that it says the following:
>
> >
>
> > 1. NumConnAcquired, 1 count, Number of logical connection
>
> >
>
> > 2. NumConnReleased, 1 count, Number of logical connections released
> > to
> the pool.
>
> >
>
> > 3. NumConnCreated, 8 count, The number of physical connections that
> > were
> created since the last reset.
>
> >
>
> > 4. NumConnFree, 8count, The total number of free connections in the
> > pool
> as of the last sampling.
>
> >
>
> > I believe that this is why the minimum pool size is 8; each logical
> connection requires 8 physical connections.
>
> >
>
> > This leads me to believe that this is why the number of connections
> > in
> my connection pool is much larger than what one would expect.
> Assuming that Tomcat only requires one connection object per query,
> this implies that Glassfish requires 8 times that amount.
>
>
>
>
>
> I think that is extremely unlikely. What is more likely is that the
> GlassFish connection pool simply initializes the configured minimum
> number of connections on the first attempt to acquire a connection.
>
>
>
> You can test this by making concurrent requests and seeing what
> happens to the pool counters. Try inserting a delay in your code
> between opening a connection and closing it; something like
> Thread.currentThread().sleep(10000) would likely suffice. Then
> initiate independent requests from several browser tabs in parallel;
> the 10-second delay should allow time for each request to grab its own
> connection from the pool while the other requests are still active.
>
>
>
>
>
> > So, while a normal pool size for Tomcat might be 20 connections, in
> Glassfish this same activity would require 160 connections.
>
> >
>
> > In any case, I'm now 100% sure that my program doesn't, and never
> > did,
> have a memory leak. I have modified my code according to Chris's
> recommendations, as this surely is good advice, but it hasn't changed
> the performance, since no exceptions were ever being thrown.
>
>
>
>
>
> Did you apply the try-catch-finally pattern to all DB-related objects,
> such as statements, prepared statements, and result sets?
>
>
>
> - Chuck
>
>
>
>
>
> > It appears to me that Glassfish is performing normally according to
> > its
> internal design, and there really is no problem as long as I keep the
> maximum pool size large enough.
>
> >
>
> > What do you think?
>
> >
>
> > Dan
>
> >
>
> > -----Original Message-----
>
> > From: Christopher Schultz <chris@christopherschultz.net<mailto:
> chris@christopherschultz.net>>
>
> > Sent: Friday, August 15, 2025 1:07 PM
>
> > To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>
> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> >
>
> > Dan,
>
> >
>
> > The only reason we are all looking for resource leaks (technically
> > not
> memory leaks, but leaks nonetheless) is because it's the best
> explanation for why your connection pool seems to be running dry.
>
> >
>
> > I don't think that switching to Tomcat (or TomEE) is going to make
> > any
> difference.
>
> >
>
> > -chris
>
> >
>
> > On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>
> >>
>
> >>
>
> >> -----Original Message-----
>
> >> From: Christopher Schultz <chris@christopherschultz.net<mailto:
> chris@christopherschultz.net>>
>
> >> Sent: Friday, August 15, 2025 12:18 PM
>
> >> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>
> >> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> >>
>
> >> Daniel,
>
> >>
>
> >> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>
> >>> Robert (and all),
>
> >>>
>
> >>> I will work on answers your various questions. However, I decided
> >>> to
> first explore the comment (by someone) that a servlet can "swallow" an
> exception, which I take to mean that it can throw an exception without
> reporting the exception or terminating the program.
>
> >>>
>
> >>> I have this system running on a PC identified as localhost. The
> >>> test
> URL is:
>
> >>>
>
> >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A80
> >>> 80_
>
> >>> H
>
> >>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_co
> >>> unt
>
> >>> r
>
> >>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCal
> >>> Lxz
>
> >>> o
>
> >>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1r
> >>> fTe
>
> >>> d
>
> >>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JS
> >>> Da9
>
> >>> P
>
> >>> xsSFgB4&e=
>
> >>>
>
> >>> I ran two tests. First, I wrote in code to throw an SQL
> >>> exception,
> which did get caught in my catch clause, which printed out some
> messages and a stack trace. The web browser showed the retrieved list
> of countries, but nothing else.
>
> >>>
>
> >>> Second, I replaced the line that throws the SQL exception by one
> >>> that
> tries to do a division by zero. This of course was not caught, but it
> did print out a stack trace and reported a 505 error in the browser,
> and the program did terminate.
>
> >>>
>
> >>> I take this to mean that exceptions are not being "swallowed" by
> >>> my
> program. When/if an exception occurs, there is definitely some
> indication of this, either in the server.log or the browser. Because
> I have never seen either of these actions, I'm fairly sure that my
> program is not throwing exceptions and all database connections are
> being closed immediately after they are used, i.e., no memory leaks in this respect.
>
> >>>
>
> >>> The actual code fragments and outputs are copied below.
>
> >>>
>
> >>> ----------------------------------------------------------------
>
> >>> The code that throws the SQL exception
>
> >>> ----------------------------------------------------------------
>
> >>> @GET
>
> >>> @Path("/countries")
>
> >>> @Produces(MediaType.APPLICATION_JSON)
>
> >>> public String getJsonCountries() {
>
> >>> if (TempDataStorage.countryList == null) {
>
> >>> Connection connection = null;
>
> >>> try {
>
> >>> connection = dataSource.getConnection();
>
> >>> System.out.println("countries connection has been
> opened");
>
> >>> TempDataStorage.countryList =
> GetCountryList.doIt(connection);
>
> >>> throw new SQLException("testing sql exception");
>
> >>> // connection.close();
>
> >>> // System.out.println("countries connection has been
> closed");
>
> >>> } catch (SQLException e) {
>
> >>> System.out.println(e);
>
> >>> System.out.println("catching sql exception");
>
> >>> if (connection != null) {
>
> >>> try {
>
> >>> connection.close();
>
> >>> } catch (SQLException ex) {
>
> >>> System.out.println(ex);
>
> >>> }
>
> >>> }
>
> >>> }
>
> >>> }
>
> >>
>
> >> 100% connection leak every time, guaranteed.
>
> >>
>
> >> You are never closing the connection, because it's been commented out.
>
> >> Perhaps this was just for testing, because I see you are throwing
> >> an
> exception.
>
> >>
>
> >> DGS: When I put in the throw statement, I had to comment out those
> >> two
> lines because the Java compiler complains that they are unreachable.
> This was just to test for what would happen if an SQL exception was
> thrown, in which case, yes, there will be a memory. The point is that
> my program never throws SQL exceptions, because if it did, I would know about it.
>
> >>
>
> >> The conn.close() *MUST* be in a finally {} block. Do not put it in
> >> the
> try block. Do not put it in the catch block. Always put it in the
> finally block.
>
> >>
>
> >> DGS: Sounds like good advice. I'll do this and see if it makes a
> difference.
>
> >>
>
> >>> ------------------------------------------------------------------
>
> >>> The output in the server.log file
>
> >>> ------------------------------------------------------------------
>
> >>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid:
> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue:
> 800] [[
>
> >>> countries connection has been opened]]
>
> >>>
>
> >>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid:
> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue:
> 800] [[
>
> >>> java.sql.SQLException: testing sql exception
>
> >>> at
>
> >>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONReso
> >>> urc
>
> >>> e
>
> >>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>
> >>>
>
> >>> ... stack trace ...
>
> >>>
>
> >>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid:
> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue:
> 800] [[
>
> >>> catching sql exception]]
>
> >>
>
> >> ... and the server does not crash. You can make any request without
> restarting Glassfish, right?
>
> >>
>
> >>> ----------------------------------------------------------------
>
> >>> The code that divides by zero
>
> >>> ----------------------------------------------------------------
>
> >>> @GET
>
> >>> @Path("/countries")
>
> >>> @Produces(MediaType.APPLICATION_JSON)
>
> >>> public String getJsonCountries() {
>
> >>> if (TempDataStorage.countryList == null) {
>
> >>> Connection connection = null;
>
> >>> try {
>
> >>> connection = dataSource.getConnection();
>
> >>> System.out.println("countries connection has been
> opened");
>
> >>> TempDataStorage.countryList =
> GetCountryList.doIt(connection);
>
> >>> float something = 1/0;
>
> >>> connection.close();
>
> >>> System.out.println("countries connection has been
> closed");
>
> >>> } catch (SQLException e) {
>
> >>> System.out.println(e);
>
> >>> System.out.println("catching sql exception");
>
> >>> if (connection != null) {
>
> >>> try {
>
> >>> connection.close();
>
> >>> } catch (SQLException ex) {
>
> >>> System.out.println(ex);
>
> >>> }
>
> >>> }
>
> >>> }
>
> >>> }
>
> >>
>
> >>
>
> >> 100% connection leak every time, guaranteed.
>
> >>
>
> >> You are never closing the connection, because your code is throwing
> >> an
> uncaught exception (divide by zero) Perhaps this was just for testing,
> because I see you are intentionally dividing by zero.
>
> >>
>
> >> DGS: Right. This was to test for what would happen if a non-SQL
> exception were thrown, i.e., one that is not caught in the catch clause.
> This created a 505 error and the program quit running. Here the
> point is that, if something like this were to happen, I would
> certainly know about it, and it has never happened, so no memory leak
> is being created in this way.
>
> >>
>
> >> The conn.close() *MUST* be in a finally {} block. Do not put it in
> >> the
> try block. Do not put it in the catch block. Always put it in the
> finally block.
>
> >>
>
> >> DGS: Thanks again. I'll do this and see if it makes any difference
> >> in
> the connection pooling.
>
> >>
>
> >> -chris
>
> >>
>
> >>
>
> >> -------------------------------------------------------------------
> >> --
>
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
> >>
>
> >>
>
> >> -------------------------------------------------------------------
> >> --
>
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
> >>
>
> >
>
> >
>
> > --------------------------------------------------------------------
> > -
>
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
> >
>
> >
>
> > --------------------------------------------------------------------
> > -
>
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Dan,
FWIW, I just set up test Glassfish server, and made a trivial app to
acquire and release a connection from the pool.
I configured the connection with a minimum and starting size of 1.
I tested with 1 connection, and it did exactly what I expected. Acquired
and released 1 connection. No more connections were allocated.
The setting for the minimum size is also the initial size (no surprise),
and I could set that value to 1.
My code to acquire the connection was this trivial code:
final InitialContext ic = new InitialContext();
final DataSource ds = (DataSource) ic.lookup("test1");
try (Connection conn = ds.getConnection()) {
} catch (SQLException e) {
throw new Runtime exception(e);
}
So, I don't agree with your "conclusion" about 8 connections per.
Robert
On Sat, Aug 16, 2025, 00:02 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Chuck,
>
> Okay, here is the text of the attachment.
>
> Instance Name:
> server
>
>
>
>
> Resource : HolidaysConnectionPool Application :
> HolidaysRESTJSON-1.0-SNAPSHOT
>
> Monitor (14 Statistics)
> JDBC Connection Pool Statistics : HolidaysConnectionPool
> Name
> Value
> Start Time
> Last Sample Time
> Details
> Description
> NumConnCreated
> 8 count
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> --
> The number of physical connections that were created since the last reset.
> NumConnFree
> 8count
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> High Water Mark: 8 count
> Low Water Mark: 0 count
> The total number of free connections in the pool as of the last sampling.
> NumConnReleased
> 1 count
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> --
> Number of logical connections released to the pool.
> NumPotentialConnLeak
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of potential connection leaks
> NumConnFailedValidation
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> The total number of connections in the connection pool that failed
> validation from the start time until the last sample time.
> ConnRequestWaitTime
> 485millisecond
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> High Water Mark: 485 millisecond
> Low Water Mark: 0 millisecond
> The longest and shortest wait times of connection requests. The current
> value indicates the wait time of the last request that was serviced by the
> pool.
> NumConnAcquired
> 1 count
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> --
> Number of logical connections acquired from the pool.
> AverageConnWaitTime
> 485 millisecond
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:33 AM
> --
> Average wait-time-duration per successful connection request
> NumConnDestroyed
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of physical connections that were destroyed since the last reset.
> NumConnSuccessfullyMatched
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of connections succesfully matched
> NumConnNotSuccessfullyMatched
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of connections rejected during matching
> NumConnUsed
> 0count
> Aug 15, 2025 1:26:20 AM
> Aug 15, 2025 1:26:21 AM
> High Water Mark: 1 count
> Low Water Mark: 0 count
> Provides connection usage statistics. The total number of connections that
> are currently being used, as well as information about the maximum number
> of connections that were used (the high water mark).
> WaitQueueLength
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> Number of connection requests in the queue waiting to be serviced.
> NumConnTimedOut
> 0 count
> Aug 15, 2025 1:26:20 AM
> --
> --
> The total number of connections in the pool that timed out between the
> start time and the last sample time.
>
> Regarding your statement "What is more likely is that the GlassFish
> connection pool simply initializes the configured minimum number of
> connections on the first attempt to acquire a connection.", I have no idea
> hat this means.
>
> Dan
>
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Friday, August 15, 2025 11:39 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> > On 2025 Aug 15, at 22:03, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote: > > I think I found the answer.
> > > A few days ago, someone suggested that I try setting the Glassfish
> maximum pool size to 1 and see what happens.
> NkdkJdXPPEBannerStart
> Be Careful With This Message
> From (Chuck Caldarale <n8...@gmail.com>)<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd
> >
> Learn More<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd
> >
> 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 15, at 22:03, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@danielgschwartz.com>> wrote:
>
> >
>
> > I think I found the answer.
>
> >
>
> > A few days ago, someone suggested that I try setting the Glassfish
> maximum pool size to 1 and see what happens. I reported back that in
> Glassfish the minimum pool size is 8, to which someone responded that this
> seems strange. I really didn't know. But now I do.
>
> >
>
> > Today I decided to run a test where I cleared out Glassfish so I could
> start from scratch. I executed one REST request using the URL I posted
> recently, which returns a list of countries. Then I looked at the
> Glassfish JDBC pool monitor. A PDF of this is attached.
>
>
>
>
>
> The list strips nearly all attachments, for safely reasons. You need to
> post the text.
>
>
>
>
>
> > You will see that it says the following:
>
> >
>
> > 1. NumConnAcquired, 1 count, Number of logical connection
>
> >
>
> > 2. NumConnReleased, 1 count, Number of logical connections released to
> the pool.
>
> >
>
> > 3. NumConnCreated, 8 count, The number of physical connections that were
> created since the last reset.
>
> >
>
> > 4. NumConnFree, 8count, The total number of free connections in the pool
> as of the last sampling.
>
> >
>
> > I believe that this is why the minimum pool size is 8; each logical
> connection requires 8 physical connections.
>
> >
>
> > This leads me to believe that this is why the number of connections in
> my connection pool is much larger than what one would expect. Assuming
> that Tomcat only requires one connection object per query, this implies
> that Glassfish requires 8 times that amount.
>
>
>
>
>
> I think that is extremely unlikely. What is more likely is that the
> GlassFish connection pool simply initializes the configured minimum number
> of connections on the first attempt to acquire a connection.
>
>
>
> You can test this by making concurrent requests and seeing what happens to
> the pool counters. Try inserting a delay in your code between opening a
> connection and closing it; something like
> Thread.currentThread().sleep(10000) would likely suffice. Then initiate
> independent requests from several browser tabs in parallel; the 10-second
> delay should allow time for each request to grab its own connection from
> the pool while the other requests are still active.
>
>
>
>
>
> > So, while a normal pool size for Tomcat might be 20 connections, in
> Glassfish this same activity would require 160 connections.
>
> >
>
> > In any case, I'm now 100% sure that my program doesn't, and never did,
> have a memory leak. I have modified my code according to Chris's
> recommendations, as this surely is good advice, but it hasn't changed the
> performance, since no exceptions were ever being thrown.
>
>
>
>
>
> Did you apply the try-catch-finally pattern to all DB-related objects,
> such as statements, prepared statements, and result sets?
>
>
>
> - Chuck
>
>
>
>
>
> > It appears to me that Glassfish is performing normally according to its
> internal design, and there really is no problem as long as I keep the
> maximum pool size large enough.
>
> >
>
> > What do you think?
>
> >
>
> > Dan
>
> >
>
> > -----Original Message-----
>
> > From: Christopher Schultz <chris@christopherschultz.net<mailto:
> chris@christopherschultz.net>>
>
> > Sent: Friday, August 15, 2025 1:07 PM
>
> > To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>
> > Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> >
>
> > Dan,
>
> >
>
> > The only reason we are all looking for resource leaks (technically not
> memory leaks, but leaks nonetheless) is because it's the best explanation
> for why your connection pool seems to be running dry.
>
> >
>
> > I don't think that switching to Tomcat (or TomEE) is going to make any
> difference.
>
> >
>
> > -chris
>
> >
>
> > On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>
> >>
>
> >>
>
> >> -----Original Message-----
>
> >> From: Christopher Schultz <chris@christopherschultz.net<mailto:
> chris@christopherschultz.net>>
>
> >> Sent: Friday, August 15, 2025 12:18 PM
>
> >> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>
> >> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> >>
>
> >> Daniel,
>
> >>
>
> >> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>
> >>> Robert (and all),
>
> >>>
>
> >>> I will work on answers your various questions. However, I decided to
> first explore the comment (by someone) that a servlet can "swallow" an
> exception, which I take to mean that it can throw an exception without
> reporting the exception or terminating the program.
>
> >>>
>
> >>> I have this system running on a PC identified as localhost. The test
> URL is:
>
> >>>
>
> >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_
>
> >>> H
>
> >>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_count
>
> >>> r
>
> >>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxz
>
> >>> o
>
> >>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1rfTe
>
> >>> d
>
> >>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JSDa9
>
> >>> P
>
> >>> xsSFgB4&e=
>
> >>>
>
> >>> I ran two tests. First, I wrote in code to throw an SQL exception,
> which did get caught in my catch clause, which printed out some messages
> and a stack trace. The web browser showed the retrieved list of countries,
> but nothing else.
>
> >>>
>
> >>> Second, I replaced the line that throws the SQL exception by one that
> tries to do a division by zero. This of course was not caught, but it did
> print out a stack trace and reported a 505 error in the browser, and the
> program did terminate.
>
> >>>
>
> >>> I take this to mean that exceptions are not being "swallowed" by my
> program. When/if an exception occurs, there is definitely some indication
> of this, either in the server.log or the browser. Because I have never
> seen either of these actions, I'm fairly sure that my program is not
> throwing exceptions and all database connections are being closed
> immediately after they are used, i.e., no memory leaks in this respect.
>
> >>>
>
> >>> The actual code fragments and outputs are copied below.
>
> >>>
>
> >>> ----------------------------------------------------------------
>
> >>> The code that throws the SQL exception
>
> >>> ----------------------------------------------------------------
>
> >>> @GET
>
> >>> @Path("/countries")
>
> >>> @Produces(MediaType.APPLICATION_JSON)
>
> >>> public String getJsonCountries() {
>
> >>> if (TempDataStorage.countryList == null) {
>
> >>> Connection connection = null;
>
> >>> try {
>
> >>> connection = dataSource.getConnection();
>
> >>> System.out.println("countries connection has been
> opened");
>
> >>> TempDataStorage.countryList =
> GetCountryList.doIt(connection);
>
> >>> throw new SQLException("testing sql exception");
>
> >>> // connection.close();
>
> >>> // System.out.println("countries connection has been
> closed");
>
> >>> } catch (SQLException e) {
>
> >>> System.out.println(e);
>
> >>> System.out.println("catching sql exception");
>
> >>> if (connection != null) {
>
> >>> try {
>
> >>> connection.close();
>
> >>> } catch (SQLException ex) {
>
> >>> System.out.println(ex);
>
> >>> }
>
> >>> }
>
> >>> }
>
> >>> }
>
> >>
>
> >> 100% connection leak every time, guaranteed.
>
> >>
>
> >> You are never closing the connection, because it's been commented out.
>
> >> Perhaps this was just for testing, because I see you are throwing an
> exception.
>
> >>
>
> >> DGS: When I put in the throw statement, I had to comment out those two
> lines because the Java compiler complains that they are unreachable. This
> was just to test for what would happen if an SQL exception was thrown, in
> which case, yes, there will be a memory. The point is that my program
> never throws SQL exceptions, because if it did, I would know about it.
>
> >>
>
> >> The conn.close() *MUST* be in a finally {} block. Do not put it in the
> try block. Do not put it in the catch block. Always put it in the finally
> block.
>
> >>
>
> >> DGS: Sounds like good advice. I'll do this and see if it makes a
> difference.
>
> >>
>
> >>> ------------------------------------------------------------------
>
> >>> The output in the server.log file
>
> >>> ------------------------------------------------------------------
>
> >>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid:
> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue:
> 800] [[
>
> >>> countries connection has been opened]]
>
> >>>
>
> >>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid:
> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue:
> 800] [[
>
> >>> java.sql.SQLException: testing sql exception
>
> >>> at
>
> >>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResourc
>
> >>> e
>
> >>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>
> >>>
>
> >>> ... stack trace ...
>
> >>>
>
> >>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid:
> _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue:
> 800] [[
>
> >>> catching sql exception]]
>
> >>
>
> >> ... and the server does not crash. You can make any request without
> restarting Glassfish, right?
>
> >>
>
> >>> ----------------------------------------------------------------
>
> >>> The code that divides by zero
>
> >>> ----------------------------------------------------------------
>
> >>> @GET
>
> >>> @Path("/countries")
>
> >>> @Produces(MediaType.APPLICATION_JSON)
>
> >>> public String getJsonCountries() {
>
> >>> if (TempDataStorage.countryList == null) {
>
> >>> Connection connection = null;
>
> >>> try {
>
> >>> connection = dataSource.getConnection();
>
> >>> System.out.println("countries connection has been
> opened");
>
> >>> TempDataStorage.countryList =
> GetCountryList.doIt(connection);
>
> >>> float something = 1/0;
>
> >>> connection.close();
>
> >>> System.out.println("countries connection has been
> closed");
>
> >>> } catch (SQLException e) {
>
> >>> System.out.println(e);
>
> >>> System.out.println("catching sql exception");
>
> >>> if (connection != null) {
>
> >>> try {
>
> >>> connection.close();
>
> >>> } catch (SQLException ex) {
>
> >>> System.out.println(ex);
>
> >>> }
>
> >>> }
>
> >>> }
>
> >>> }
>
> >>
>
> >>
>
> >> 100% connection leak every time, guaranteed.
>
> >>
>
> >> You are never closing the connection, because your code is throwing an
> uncaught exception (divide by zero) Perhaps this was just for testing,
> because I see you are intentionally dividing by zero.
>
> >>
>
> >> DGS: Right. This was to test for what would happen if a non-SQL
> exception were thrown, i.e., one that is not caught in the catch clause.
> This created a 505 error and the program quit running. Here the point is
> that, if something like this were to happen, I would certainly know about
> it, and it has never happened, so no memory leak is being created in this
> way.
>
> >>
>
> >> The conn.close() *MUST* be in a finally {} block. Do not put it in the
> try block. Do not put it in the catch block. Always put it in the finally
> block.
>
> >>
>
> >> DGS: Thanks again. I'll do this and see if it makes any difference in
> the connection pooling.
>
> >>
>
> >> -chris
>
> >>
>
> >>
>
> >> ---------------------------------------------------------------------
>
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
> >>
>
> >>
>
> >> ---------------------------------------------------------------------
>
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
> >>
>
> >
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
> >
>
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chuck,
Okay, here is the text of the attachment.
Instance Name:
server
Resource : HolidaysConnectionPool Application : HolidaysRESTJSON-1.0-SNAPSHOT
Monitor (14 Statistics)
JDBC Connection Pool Statistics : HolidaysConnectionPool
Name
Value
Start Time
Last Sample Time
Details
Description
NumConnCreated
8 count
Aug 15, 2025 1:26:20 AM
Aug 15, 2025 1:26:21 AM
--
The number of physical connections that were created since the last reset.
NumConnFree
8count
Aug 15, 2025 1:26:20 AM
Aug 15, 2025 1:26:21 AM
High Water Mark: 8 count
Low Water Mark: 0 count
The total number of free connections in the pool as of the last sampling.
NumConnReleased
1 count
Aug 15, 2025 1:26:20 AM
Aug 15, 2025 1:26:21 AM
--
Number of logical connections released to the pool.
NumPotentialConnLeak
0 count
Aug 15, 2025 1:26:20 AM
--
--
Number of potential connection leaks
NumConnFailedValidation
0 count
Aug 15, 2025 1:26:20 AM
--
--
The total number of connections in the connection pool that failed validation from the start time until the last sample time.
ConnRequestWaitTime
485millisecond
Aug 15, 2025 1:26:20 AM
Aug 15, 2025 1:26:21 AM
High Water Mark: 485 millisecond
Low Water Mark: 0 millisecond
The longest and shortest wait times of connection requests. The current value indicates the wait time of the last request that was serviced by the pool.
NumConnAcquired
1 count
Aug 15, 2025 1:26:20 AM
Aug 15, 2025 1:26:21 AM
--
Number of logical connections acquired from the pool.
AverageConnWaitTime
485 millisecond
Aug 15, 2025 1:26:20 AM
Aug 15, 2025 1:26:33 AM
--
Average wait-time-duration per successful connection request
NumConnDestroyed
0 count
Aug 15, 2025 1:26:20 AM
--
--
Number of physical connections that were destroyed since the last reset.
NumConnSuccessfullyMatched
0 count
Aug 15, 2025 1:26:20 AM
--
--
Number of connections succesfully matched
NumConnNotSuccessfullyMatched
0 count
Aug 15, 2025 1:26:20 AM
--
--
Number of connections rejected during matching
NumConnUsed
0count
Aug 15, 2025 1:26:20 AM
Aug 15, 2025 1:26:21 AM
High Water Mark: 1 count
Low Water Mark: 0 count
Provides connection usage statistics. The total number of connections that are currently being used, as well as information about the maximum number of connections that were used (the high water mark).
WaitQueueLength
0 count
Aug 15, 2025 1:26:20 AM
--
--
Number of connection requests in the queue waiting to be serviced.
NumConnTimedOut
0 count
Aug 15, 2025 1:26:20 AM
--
--
The total number of connections in the pool that timed out between the start time and the last sample time.
Regarding your statement "What is more likely is that the GlassFish connection pool simply initializes the configured minimum number of connections on the first attempt to acquire a connection.", I have no idea hat this means.
Dan
From: Chuck Caldarale <n8...@gmail.com>
Sent: Friday, August 15, 2025 11:39 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 15, at 22:03, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > I think I found the answer. > > A few days ago, someone suggested that I try setting the Glassfish maximum pool size to 1 and see what happens.
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f4a8adbed4b5cf7a587f5f4df537a8eaec1a2b42d4d58936018b1ed681a23d9919bf8332d2b6b61429feb03a72599510c1c3ab28d5aaddc506ec4d56aaa261fcb98bd9aad462cad1cc8e2c0a7c87426fd5ac7bd5b6e2701e483c6c0dabfa7863325d5e1cce43460a01fdb3123cef7a62998f33320b7ee6a504f58e005390e8ee17f0cc8754779156e61decfa830f679ecb7c1779d40b153b44dd3c8946f5c5040afad656b12d548292c93d680a4c9c588dd499f91f4d3fe02cd457cde8bab1d939f1dcbfe104966e4bccd617fa2cf6cf872584c675598f814ea3508244febcc34102818eff6415cdd>
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 15, at 22:03, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> I think I found the answer.
>
> A few days ago, someone suggested that I try setting the Glassfish maximum pool size to 1 and see what happens. I reported back that in Glassfish the minimum pool size is 8, to which someone responded that this seems strange. I really didn't know. But now I do.
>
> Today I decided to run a test where I cleared out Glassfish so I could start from scratch. I executed one REST request using the URL I posted recently, which returns a list of countries. Then I looked at the Glassfish JDBC pool monitor. A PDF of this is attached.
The list strips nearly all attachments, for safely reasons. You need to post the text.
> You will see that it says the following:
>
> 1. NumConnAcquired, 1 count, Number of logical connection
>
> 2. NumConnReleased, 1 count, Number of logical connections released to the pool.
>
> 3. NumConnCreated, 8 count, The number of physical connections that were created since the last reset.
>
> 4. NumConnFree, 8count, The total number of free connections in the pool as of the last sampling.
>
> I believe that this is why the minimum pool size is 8; each logical connection requires 8 physical connections.
>
> This leads me to believe that this is why the number of connections in my connection pool is much larger than what one would expect. Assuming that Tomcat only requires one connection object per query, this implies that Glassfish requires 8 times that amount.
I think that is extremely unlikely. What is more likely is that the GlassFish connection pool simply initializes the configured minimum number of connections on the first attempt to acquire a connection.
You can test this by making concurrent requests and seeing what happens to the pool counters. Try inserting a delay in your code between opening a connection and closing it; something like Thread.currentThread().sleep(10000) would likely suffice. Then initiate independent requests from several browser tabs in parallel; the 10-second delay should allow time for each request to grab its own connection from the pool while the other requests are still active.
> So, while a normal pool size for Tomcat might be 20 connections, in Glassfish this same activity would require 160 connections.
>
> In any case, I'm now 100% sure that my program doesn't, and never did, have a memory leak. I have modified my code according to Chris's recommendations, as this surely is good advice, but it hasn't changed the performance, since no exceptions were ever being thrown.
Did you apply the try-catch-finally pattern to all DB-related objects, such as statements, prepared statements, and result sets?
- Chuck
> It appears to me that Glassfish is performing normally according to its internal design, and there really is no problem as long as I keep the maximum pool size large enough.
>
> What do you think?
>
> Dan
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>>
> Sent: Friday, August 15, 2025 1:07 PM
> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Dan,
>
> The only reason we are all looking for resource leaks (technically not memory leaks, but leaks nonetheless) is because it's the best explanation for why your connection pool seems to be running dry.
>
> I don't think that switching to Tomcat (or TomEE) is going to make any difference.
>
> -chris
>
> On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>>
>>
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>>
>> Sent: Friday, August 15, 2025 12:18 PM
>> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> Daniel,
>>
>> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>>> Robert (and all),
>>>
>>> I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
>>>
>>> I have this system running on a PC identified as localhost. The test URL is:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_
>>> H
>>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_count
>>> r
>>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxz
>>> o
>>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1rfTe
>>> d
>>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JSDa9
>>> P
>>> xsSFgB4&e=
>>>
>>> I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
>>>
>>> Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
>>>
>>> I take this to mean that exceptions are not being "swallowed" by my program. When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
>>>
>>> The actual code fragments and outputs are copied below.
>>>
>>> ----------------------------------------------------------------
>>> The code that throws the SQL exception
>>> ----------------------------------------------------------------
>>> @GET
>>> @Path("/countries")
>>> @Produces(MediaType.APPLICATION_JSON)
>>> public String getJsonCountries() {
>>> if (TempDataStorage.countryList == null) {
>>> Connection connection = null;
>>> try {
>>> connection = dataSource.getConnection();
>>> System.out.println("countries connection has been opened");
>>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>>> throw new SQLException("testing sql exception");
>>> // connection.close();
>>> // System.out.println("countries connection has been closed");
>>> } catch (SQLException e) {
>>> System.out.println(e);
>>> System.out.println("catching sql exception");
>>> if (connection != null) {
>>> try {
>>> connection.close();
>>> } catch (SQLException ex) {
>>> System.out.println(ex);
>>> }
>>> }
>>> }
>>> }
>>
>> 100% connection leak every time, guaranteed.
>>
>> You are never closing the connection, because it's been commented out.
>> Perhaps this was just for testing, because I see you are throwing an exception.
>>
>> DGS: When I put in the throw statement, I had to comment out those two lines because the Java compiler complains that they are unreachable. This was just to test for what would happen if an SQL exception was thrown, in which case, yes, there will be a memory. The point is that my program never throws SQL exceptions, because if it did, I would know about it.
>>
>> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>>
>> DGS: Sounds like good advice. I'll do this and see if it makes a difference.
>>
>>> ------------------------------------------------------------------
>>> The output in the server.log file
>>> ------------------------------------------------------------------
>>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue: 800] [[
>>> countries connection has been opened]]
>>>
>>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>>> java.sql.SQLException: testing sql exception
>>> at
>>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResourc
>>> e
>>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>>>
>>> ... stack trace ...
>>>
>>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>>> catching sql exception]]
>>
>> ... and the server does not crash. You can make any request without restarting Glassfish, right?
>>
>>> ----------------------------------------------------------------
>>> The code that divides by zero
>>> ----------------------------------------------------------------
>>> @GET
>>> @Path("/countries")
>>> @Produces(MediaType.APPLICATION_JSON)
>>> public String getJsonCountries() {
>>> if (TempDataStorage.countryList == null) {
>>> Connection connection = null;
>>> try {
>>> connection = dataSource.getConnection();
>>> System.out.println("countries connection has been opened");
>>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>>> float something = 1/0;
>>> connection.close();
>>> System.out.println("countries connection has been closed");
>>> } catch (SQLException e) {
>>> System.out.println(e);
>>> System.out.println("catching sql exception");
>>> if (connection != null) {
>>> try {
>>> connection.close();
>>> } catch (SQLException ex) {
>>> System.out.println(ex);
>>> }
>>> }
>>> }
>>> }
>>
>>
>> 100% connection leak every time, guaranteed.
>>
>> You are never closing the connection, because your code is throwing an uncaught exception (divide by zero) Perhaps this was just for testing, because I see you are intentionally dividing by zero.
>>
>> DGS: Right. This was to test for what would happen if a non-SQL exception were thrown, i.e., one that is not caught in the catch clause. This created a 505 error and the program quit running. Here the point is that, if something like this were to happen, I would certainly know about it, and it has never happened, so no memory leak is being created in this way.
>>
>> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>>
>> DGS: Thanks again. I'll do this and see if it makes any difference in the connection pooling.
>>
>> -chris
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 15, at 22:03, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> I think I found the answer.
>
> A few days ago, someone suggested that I try setting the Glassfish maximum pool size to 1 and see what happens. I reported back that in Glassfish the minimum pool size is 8, to which someone responded that this seems strange. I really didn't know. But now I do.
>
> Today I decided to run a test where I cleared out Glassfish so I could start from scratch. I executed one REST request using the URL I posted recently, which returns a list of countries. Then I looked at the Glassfish JDBC pool monitor. A PDF of this is attached.
The list strips nearly all attachments, for safely reasons. You need to post the text.
> You will see that it says the following:
>
> 1. NumConnAcquired, 1 count, Number of logical connection
>
> 2. NumConnReleased, 1 count, Number of logical connections released to the pool.
>
> 3. NumConnCreated, 8 count, The number of physical connections that were created since the last reset.
>
> 4. NumConnFree, 8count, The total number of free connections in the pool as of the last sampling.
>
> I believe that this is why the minimum pool size is 8; each logical connection requires 8 physical connections.
>
> This leads me to believe that this is why the number of connections in my connection pool is much larger than what one would expect. Assuming that Tomcat only requires one connection object per query, this implies that Glassfish requires 8 times that amount.
I think that is extremely unlikely. What is more likely is that the GlassFish connection pool simply initializes the configured minimum number of connections on the first attempt to acquire a connection.
You can test this by making concurrent requests and seeing what happens to the pool counters. Try inserting a delay in your code between opening a connection and closing it; something like Thread.currentThread().sleep(10000) would likely suffice. Then initiate independent requests from several browser tabs in parallel; the 10-second delay should allow time for each request to grab its own connection from the pool while the other requests are still active.
> So, while a normal pool size for Tomcat might be 20 connections, in Glassfish this same activity would require 160 connections.
>
> In any case, I'm now 100% sure that my program doesn't, and never did, have a memory leak. I have modified my code according to Chris's recommendations, as this surely is good advice, but it hasn't changed the performance, since no exceptions were ever being thrown.
Did you apply the try-catch-finally pattern to all DB-related objects, such as statements, prepared statements, and result sets?
- Chuck
> It appears to me that Glassfish is performing normally according to its internal design, and there really is no problem as long as I keep the maximum pool size large enough.
>
> What do you think?
>
> Dan
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Friday, August 15, 2025 1:07 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Dan,
>
> The only reason we are all looking for resource leaks (technically not memory leaks, but leaks nonetheless) is because it's the best explanation for why your connection pool seems to be running dry.
>
> I don't think that switching to Tomcat (or TomEE) is going to make any difference.
>
> -chris
>
> On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>>
>>
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>
>> Sent: Friday, August 15, 2025 12:18 PM
>> To: users@tomcat.apache.org
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>>
>> Daniel,
>>
>> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>>> Robert (and all),
>>>
>>> I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
>>>
>>> I have this system running on a PC identified as localhost. The test URL is:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_
>>> H
>>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_count
>>> r
>>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxz
>>> o
>>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1rfTe
>>> d
>>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JSDa9
>>> P
>>> xsSFgB4&e=
>>>
>>> I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
>>>
>>> Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
>>>
>>> I take this to mean that exceptions are not being "swallowed" by my program. When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
>>>
>>> The actual code fragments and outputs are copied below.
>>>
>>> ----------------------------------------------------------------
>>> The code that throws the SQL exception
>>> ----------------------------------------------------------------
>>> @GET
>>> @Path("/countries")
>>> @Produces(MediaType.APPLICATION_JSON)
>>> public String getJsonCountries() {
>>> if (TempDataStorage.countryList == null) {
>>> Connection connection = null;
>>> try {
>>> connection = dataSource.getConnection();
>>> System.out.println("countries connection has been opened");
>>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>>> throw new SQLException("testing sql exception");
>>> // connection.close();
>>> // System.out.println("countries connection has been closed");
>>> } catch (SQLException e) {
>>> System.out.println(e);
>>> System.out.println("catching sql exception");
>>> if (connection != null) {
>>> try {
>>> connection.close();
>>> } catch (SQLException ex) {
>>> System.out.println(ex);
>>> }
>>> }
>>> }
>>> }
>>
>> 100% connection leak every time, guaranteed.
>>
>> You are never closing the connection, because it's been commented out.
>> Perhaps this was just for testing, because I see you are throwing an exception.
>>
>> DGS: When I put in the throw statement, I had to comment out those two lines because the Java compiler complains that they are unreachable. This was just to test for what would happen if an SQL exception was thrown, in which case, yes, there will be a memory. The point is that my program never throws SQL exceptions, because if it did, I would know about it.
>>
>> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>>
>> DGS: Sounds like good advice. I'll do this and see if it makes a difference.
>>
>>> ------------------------------------------------------------------
>>> The output in the server.log file
>>> ------------------------------------------------------------------
>>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue: 800] [[
>>> countries connection has been opened]]
>>>
>>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>>> java.sql.SQLException: testing sql exception
>>> at
>>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResourc
>>> e
>>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>>>
>>> ... stack trace ...
>>>
>>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>>> catching sql exception]]
>>
>> ... and the server does not crash. You can make any request without restarting Glassfish, right?
>>
>>> ----------------------------------------------------------------
>>> The code that divides by zero
>>> ----------------------------------------------------------------
>>> @GET
>>> @Path("/countries")
>>> @Produces(MediaType.APPLICATION_JSON)
>>> public String getJsonCountries() {
>>> if (TempDataStorage.countryList == null) {
>>> Connection connection = null;
>>> try {
>>> connection = dataSource.getConnection();
>>> System.out.println("countries connection has been opened");
>>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>>> float something = 1/0;
>>> connection.close();
>>> System.out.println("countries connection has been closed");
>>> } catch (SQLException e) {
>>> System.out.println(e);
>>> System.out.println("catching sql exception");
>>> if (connection != null) {
>>> try {
>>> connection.close();
>>> } catch (SQLException ex) {
>>> System.out.println(ex);
>>> }
>>> }
>>> }
>>> }
>>
>>
>> 100% connection leak every time, guaranteed.
>>
>> You are never closing the connection, because your code is throwing an uncaught exception (divide by zero) Perhaps this was just for testing, because I see you are intentionally dividing by zero.
>>
>> DGS: Right. This was to test for what would happen if a non-SQL exception were thrown, i.e., one that is not caught in the catch clause. This created a 505 error and the program quit running. Here the point is that, if something like this were to happen, I would certainly know about it, and it has never happened, so no memory leak is being created in this way.
>>
>> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>>
>> DGS: Thanks again. I'll do this and see if it makes any difference in the connection pooling.
>>
>> -chris
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris and all,
I think I found the answer.
A few days ago, someone suggested that I try setting the Glassfish maximum pool size to 1 and see what happens. I reported back that in Glassfish the minimum pool size is 8, to which someone responded that this seems strange. I really didn't know. But now I do.
Today I decided to run a test where I cleared out Glassfish so I could start from scratch. I executed one REST request using the URL I posted recently, which returns a list of countries. Then I looked at the Glassfish JDBC pool monitor. A PDF of this is attached. You will see that it says the following:
1. NumConnAcquired, 1 count, Number of logical connection
2. NumConnReleased, 1 count, Number of logical connections released to the pool.
3. NumConnCreated, 8 count, The number of physical connections that were created since the last reset.
4. NumConnFree, 8count, The total number of free connections in the pool as of the last sampling.
I believe that this is why the minimum pool size is 8; each logical connection requires 8 physical connections.
This leads me to believe that this is why the number of connections in my connection pool is much larger than what one would expect. Assuming that Tomcat only requires one connection object per query, this implies that Glassfish requires 8 times that amount. So, while a normal pool size for Tomcat might be 20 connections, in Glassfish this same activity would require 160 connections.
In any case, I'm now 100% sure that my program doesn't, and never did, have a memory leak. I have modified my code according to Chris's recommendations, as this surely is good advice, but it hasn't changed the performance, since no exceptions were ever being thrown.
It appears to me that Glassfish is performing normally according to its internal design, and there really is no problem as long as I keep the maximum pool size large enough.
What do you think?
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Friday, August 15, 2025 1:07 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Dan,
The only reason we are all looking for resource leaks (technically not memory leaks, but leaks nonetheless) is because it's the best explanation for why your connection pool seems to be running dry.
I don't think that switching to Tomcat (or TomEE) is going to make any difference.
-chris
On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Friday, August 15, 2025 12:18 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Daniel,
>
> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>> Robert (and all),
>>
>> I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
>>
>> I have this system running on a PC identified as localhost. The test URL is:
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_
>> H
>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_count
>> r
>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxz
>> o
>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1rfTe
>> d
>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JSDa9
>> P
>> xsSFgB4&e=
>>
>> I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
>>
>> Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
>>
>> I take this to mean that exceptions are not being "swallowed" by my program. When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
>>
>> The actual code fragments and outputs are copied below.
>>
>> ----------------------------------------------------------------
>> The code that throws the SQL exception
>> ----------------------------------------------------------------
>> @GET
>> @Path("/countries")
>> @Produces(MediaType.APPLICATION_JSON)
>> public String getJsonCountries() {
>> if (TempDataStorage.countryList == null) {
>> Connection connection = null;
>> try {
>> connection = dataSource.getConnection();
>> System.out.println("countries connection has been opened");
>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>> throw new SQLException("testing sql exception");
>> // connection.close();
>> // System.out.println("countries connection has been closed");
>> } catch (SQLException e) {
>> System.out.println(e);
>> System.out.println("catching sql exception");
>> if (connection != null) {
>> try {
>> connection.close();
>> } catch (SQLException ex) {
>> System.out.println(ex);
>> }
>> }
>> }
>> }
>
> 100% connection leak every time, guaranteed.
>
> You are never closing the connection, because it's been commented out.
> Perhaps this was just for testing, because I see you are throwing an exception.
>
> DGS: When I put in the throw statement, I had to comment out those two lines because the Java compiler complains that they are unreachable. This was just to test for what would happen if an SQL exception was thrown, in which case, yes, there will be a memory. The point is that my program never throws SQL exceptions, because if it did, I would know about it.
>
> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>
> DGS: Sounds like good advice. I'll do this and see if it makes a difference.
>
>> ------------------------------------------------------------------
>> The output in the server.log file
>> ------------------------------------------------------------------
>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue: 800] [[
>> countries connection has been opened]]
>>
>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>> java.sql.SQLException: testing sql exception
>> at
>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResourc
>> e
>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>>
>> ... stack trace ...
>>
>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>> catching sql exception]]
>
> ... and the server does not crash. You can make any request without restarting Glassfish, right?
>
>> ----------------------------------------------------------------
>> The code that divides by zero
>> ----------------------------------------------------------------
>> @GET
>> @Path("/countries")
>> @Produces(MediaType.APPLICATION_JSON)
>> public String getJsonCountries() {
>> if (TempDataStorage.countryList == null) {
>> Connection connection = null;
>> try {
>> connection = dataSource.getConnection();
>> System.out.println("countries connection has been opened");
>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>> float something = 1/0;
>> connection.close();
>> System.out.println("countries connection has been closed");
>> } catch (SQLException e) {
>> System.out.println(e);
>> System.out.println("catching sql exception");
>> if (connection != null) {
>> try {
>> connection.close();
>> } catch (SQLException ex) {
>> System.out.println(ex);
>> }
>> }
>> }
>> }
>
>
> 100% connection leak every time, guaranteed.
>
> You are never closing the connection, because your code is throwing an uncaught exception (divide by zero) Perhaps this was just for testing, because I see you are intentionally dividing by zero.
>
> DGS: Right. This was to test for what would happen if a non-SQL exception were thrown, i.e., one that is not caught in the catch clause. This created a 505 error and the program quit running. Here the point is that, if something like this were to happen, I would certainly know about it, and it has never happened, so no memory leak is being created in this way.
>
> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>
> DGS: Thanks again. I'll do this and see if it makes any difference in the connection pooling.
>
> -chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
Yes, this is where this conversation started. The pundits all think that I'm generating too many connections, and the suspicion is that this is being caused by a memory leak, i.e., some connections being created that are not being closed. This could be correct, but so far, I have been unable to find any such leak. Still looking.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Friday, August 15, 2025 1:07 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Dan,
The only reason we are all looking for resource leaks (technically not memory leaks, but leaks nonetheless) is because it's the best explanation for why your connection pool seems to be running dry.
I don't think that switching to Tomcat (or TomEE) is going to make any difference.
-chris
On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Friday, August 15, 2025 12:18 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Daniel,
>
> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>> Robert (and all),
>>
>> I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
>>
>> I have this system running on a PC identified as localhost. The test URL is:
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_
>> H
>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_count
>> r
>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxz
>> o
>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1rfTe
>> d
>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JSDa9
>> P
>> xsSFgB4&e=
>>
>> I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
>>
>> Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
>>
>> I take this to mean that exceptions are not being "swallowed" by my program. When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
>>
>> The actual code fragments and outputs are copied below.
>>
>> ----------------------------------------------------------------
>> The code that throws the SQL exception
>> ----------------------------------------------------------------
>> @GET
>> @Path("/countries")
>> @Produces(MediaType.APPLICATION_JSON)
>> public String getJsonCountries() {
>> if (TempDataStorage.countryList == null) {
>> Connection connection = null;
>> try {
>> connection = dataSource.getConnection();
>> System.out.println("countries connection has been opened");
>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>> throw new SQLException("testing sql exception");
>> // connection.close();
>> // System.out.println("countries connection has been closed");
>> } catch (SQLException e) {
>> System.out.println(e);
>> System.out.println("catching sql exception");
>> if (connection != null) {
>> try {
>> connection.close();
>> } catch (SQLException ex) {
>> System.out.println(ex);
>> }
>> }
>> }
>> }
>
> 100% connection leak every time, guaranteed.
>
> You are never closing the connection, because it's been commented out.
> Perhaps this was just for testing, because I see you are throwing an exception.
>
> DGS: When I put in the throw statement, I had to comment out those two lines because the Java compiler complains that they are unreachable. This was just to test for what would happen if an SQL exception was thrown, in which case, yes, there will be a memory. The point is that my program never throws SQL exceptions, because if it did, I would know about it.
>
> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>
> DGS: Sounds like good advice. I'll do this and see if it makes a difference.
>
>> ------------------------------------------------------------------
>> The output in the server.log file
>> ------------------------------------------------------------------
>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue: 800] [[
>> countries connection has been opened]]
>>
>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>> java.sql.SQLException: testing sql exception
>> at
>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResourc
>> e
>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>>
>> ... stack trace ...
>>
>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>> catching sql exception]]
>
> ... and the server does not crash. You can make any request without restarting Glassfish, right?
>
>> ----------------------------------------------------------------
>> The code that divides by zero
>> ----------------------------------------------------------------
>> @GET
>> @Path("/countries")
>> @Produces(MediaType.APPLICATION_JSON)
>> public String getJsonCountries() {
>> if (TempDataStorage.countryList == null) {
>> Connection connection = null;
>> try {
>> connection = dataSource.getConnection();
>> System.out.println("countries connection has been opened");
>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>> float something = 1/0;
>> connection.close();
>> System.out.println("countries connection has been closed");
>> } catch (SQLException e) {
>> System.out.println(e);
>> System.out.println("catching sql exception");
>> if (connection != null) {
>> try {
>> connection.close();
>> } catch (SQLException ex) {
>> System.out.println(ex);
>> }
>> }
>> }
>> }
>
>
> 100% connection leak every time, guaranteed.
>
> You are never closing the connection, because your code is throwing an uncaught exception (divide by zero) Perhaps this was just for testing, because I see you are intentionally dividing by zero.
>
> DGS: Right. This was to test for what would happen if a non-SQL exception were thrown, i.e., one that is not caught in the catch clause. This created a 505 error and the program quit running. Here the point is that, if something like this were to happen, I would certainly know about it, and it has never happened, so no memory leak is being created in this way.
>
> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>
> DGS: Thanks again. I'll do this and see if it makes any difference in the connection pooling.
>
> -chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
The only reason we are all looking for resource leaks (technically not
memory leaks, but leaks nonetheless) is because it's the best
explanation for why your connection pool seems to be running dry.
I don't think that switching to Tomcat (or TomEE) is going to make any
difference.
-chris
On 8/15/25 12:33 PM, Daniel Schwartz wrote:
>
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Friday, August 15, 2025 12:18 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Daniel,
>
> On 8/15/25 12:49 AM, Daniel Schwartz wrote:
>> Robert (and all),
>>
>> I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
>>
>> I have this system running on a PC identified as localhost. The test URL is:
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_H
>> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_countr
>> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzo
>> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1rfTed
>> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JSDa9P
>> xsSFgB4&e=
>>
>> I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
>>
>> Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
>>
>> I take this to mean that exceptions are not being "swallowed" by my program. When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
>>
>> The actual code fragments and outputs are copied below.
>>
>> ----------------------------------------------------------------
>> The code that throws the SQL exception
>> ----------------------------------------------------------------
>> @GET
>> @Path("/countries")
>> @Produces(MediaType.APPLICATION_JSON)
>> public String getJsonCountries() {
>> if (TempDataStorage.countryList == null) {
>> Connection connection = null;
>> try {
>> connection = dataSource.getConnection();
>> System.out.println("countries connection has been opened");
>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>> throw new SQLException("testing sql exception");
>> // connection.close();
>> // System.out.println("countries connection has been closed");
>> } catch (SQLException e) {
>> System.out.println(e);
>> System.out.println("catching sql exception");
>> if (connection != null) {
>> try {
>> connection.close();
>> } catch (SQLException ex) {
>> System.out.println(ex);
>> }
>> }
>> }
>> }
>
> 100% connection leak every time, guaranteed.
>
> You are never closing the connection, because it's been commented out.
> Perhaps this was just for testing, because I see you are throwing an exception.
>
> DGS: When I put in the throw statement, I had to comment out those two lines because the Java compiler complains that they are unreachable. This was just to test for what would happen if an SQL exception was thrown, in which case, yes, there will be a memory. The point is that my program never throws SQL exceptions, because if it did, I would know about it.
>
> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>
> DGS: Sounds like good advice. I'll do this and see if it makes a difference.
>
>> ------------------------------------------------------------------
>> The output in the server.log file
>> ------------------------------------------------------------------
>> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue: 800] [[
>> countries connection has been opened]]
>>
>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>> java.sql.SQLException: testing sql exception
>> at
>> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResource
>> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>>
>> ... stack trace ...
>>
>> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
>> catching sql exception]]
>
> ... and the server does not crash. You can make any request without restarting Glassfish, right?
>
>> ----------------------------------------------------------------
>> The code that divides by zero
>> ----------------------------------------------------------------
>> @GET
>> @Path("/countries")
>> @Produces(MediaType.APPLICATION_JSON)
>> public String getJsonCountries() {
>> if (TempDataStorage.countryList == null) {
>> Connection connection = null;
>> try {
>> connection = dataSource.getConnection();
>> System.out.println("countries connection has been opened");
>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>> float something = 1/0;
>> connection.close();
>> System.out.println("countries connection has been closed");
>> } catch (SQLException e) {
>> System.out.println(e);
>> System.out.println("catching sql exception");
>> if (connection != null) {
>> try {
>> connection.close();
>> } catch (SQLException ex) {
>> System.out.println(ex);
>> }
>> }
>> }
>> }
>
>
> 100% connection leak every time, guaranteed.
>
> You are never closing the connection, because your code is throwing an uncaught exception (divide by zero) Perhaps this was just for testing, because I see you are intentionally dividing by zero.
>
> DGS: Right. This was to test for what would happen if a non-SQL exception were thrown, i.e., one that is not caught in the catch clause. This created a 505 error and the program quit running. Here the point is that, if something like this were to happen, I would certainly know about it, and it has never happened, so no memory leak is being created in this way.
>
> The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
>
> DGS: Thanks again. I'll do this and see if it makes any difference in the connection pooling.
>
> -chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Friday, August 15, 2025 12:18 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Daniel,
On 8/15/25 12:49 AM, Daniel Schwartz wrote:
> Robert (and all),
>
> I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
>
> I have this system running on a PC identified as localhost. The test URL is:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_H
> olidaysRESTJSON-2D1.0-2DSNAPSHOT_webresources_holidaysandevents_countr
> ies&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzo
> pgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=NKm1FUayvDzFHyhbqCI0JR32OpW1rfTed
> HFkAoC_xT6Cjqt4-wsVFtYKPtR38vFY&s=4BYNb88ZN6WvyMyyZcR1FyT6Jg-qa4JSDa9P
> xsSFgB4&e=
>
> I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
>
> Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
>
> I take this to mean that exceptions are not being "swallowed" by my program. When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
>
> The actual code fragments and outputs are copied below.
>
> ----------------------------------------------------------------
> The code that throws the SQL exception
> ----------------------------------------------------------------
> @GET
> @Path("/countries")
> @Produces(MediaType.APPLICATION_JSON)
> public String getJsonCountries() {
> if (TempDataStorage.countryList == null) {
> Connection connection = null;
> try {
> connection = dataSource.getConnection();
> System.out.println("countries connection has been opened");
> TempDataStorage.countryList = GetCountryList.doIt(connection);
> throw new SQLException("testing sql exception");
> // connection.close();
> // System.out.println("countries connection has been closed");
> } catch (SQLException e) {
> System.out.println(e);
> System.out.println("catching sql exception");
> if (connection != null) {
> try {
> connection.close();
> } catch (SQLException ex) {
> System.out.println(ex);
> }
> }
> }
> }
100% connection leak every time, guaranteed.
You are never closing the connection, because it's been commented out.
Perhaps this was just for testing, because I see you are throwing an exception.
DGS: When I put in the throw statement, I had to comment out those two lines because the Java compiler complains that they are unreachable. This was just to test for what would happen if an SQL exception was thrown, in which case, yes, there will be a memory. The point is that my program never throws SQL exceptions, because if it did, I would know about it.
The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
DGS: Sounds like good advice. I'll do this and see if it makes a difference.
> ------------------------------------------------------------------
> The output in the server.log file
> ------------------------------------------------------------------
> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue: 800] [[
> countries connection has been opened]]
>
> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
> java.sql.SQLException: testing sql exception
> at
> com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResource
> .getJsonCountries(HolidaysRESTJSONResource.java:54)
>
> ... stack trace ...
>
> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
> catching sql exception]]
... and the server does not crash. You can make any request without restarting Glassfish, right?
> ----------------------------------------------------------------
> The code that divides by zero
> ----------------------------------------------------------------
> @GET
> @Path("/countries")
> @Produces(MediaType.APPLICATION_JSON)
> public String getJsonCountries() {
> if (TempDataStorage.countryList == null) {
> Connection connection = null;
> try {
> connection = dataSource.getConnection();
> System.out.println("countries connection has been opened");
> TempDataStorage.countryList = GetCountryList.doIt(connection);
> float something = 1/0;
> connection.close();
> System.out.println("countries connection has been closed");
> } catch (SQLException e) {
> System.out.println(e);
> System.out.println("catching sql exception");
> if (connection != null) {
> try {
> connection.close();
> } catch (SQLException ex) {
> System.out.println(ex);
> }
> }
> }
> }
100% connection leak every time, guaranteed.
You are never closing the connection, because your code is throwing an uncaught exception (divide by zero) Perhaps this was just for testing, because I see you are intentionally dividing by zero.
DGS: Right. This was to test for what would happen if a non-SQL exception were thrown, i.e., one that is not caught in the catch clause. This created a 505 error and the program quit running. Here the point is that, if something like this were to happen, I would certainly know about it, and it has never happened, so no memory leak is being created in this way.
The conn.close() *MUST* be in a finally {} block. Do not put it in the try block. Do not put it in the catch block. Always put it in the finally block.
DGS: Thanks again. I'll do this and see if it makes any difference in the connection pooling.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Daniel,
On 8/15/25 12:49 AM, Daniel Schwartz wrote:
> Robert (and all),
>
> I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
>
> I have this system running on a PC identified as localhost. The test URL is:
>
> http://localhost:8080/HolidaysRESTJSON-1.0-SNAPSHOT/webresources/holidaysandevents/countries
>
> I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
>
> Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
>
> I take this to mean that exceptions are not being "swallowed" by my program. When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
>
> The actual code fragments and outputs are copied below.
>
> ----------------------------------------------------------------
> The code that throws the SQL exception
> ----------------------------------------------------------------
> @GET
> @Path("/countries")
> @Produces(MediaType.APPLICATION_JSON)
> public String getJsonCountries() {
> if (TempDataStorage.countryList == null) {
> Connection connection = null;
> try {
> connection = dataSource.getConnection();
> System.out.println("countries connection has been opened");
> TempDataStorage.countryList = GetCountryList.doIt(connection);
> throw new SQLException("testing sql exception");
> // connection.close();
> // System.out.println("countries connection has been closed");
> } catch (SQLException e) {
> System.out.println(e);
> System.out.println("catching sql exception");
> if (connection != null) {
> try {
> connection.close();
> } catch (SQLException ex) {
> System.out.println(ex);
> }
> }
> }
> }
100% connection leak every time, guaranteed.
You are never closing the connection, because it's been commented out.
Perhaps this was just for testing, because I see you are throwing an
exception.
The conn.close() *MUST* be in a finally {} block. Do not put it in the
try block. Do not put it in the catch block. Always put it in the
finally block.
> ------------------------------------------------------------------
> The output in the server.log file
> ------------------------------------------------------------------
> [2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue: 800] [[
> countries connection has been opened]]
>
> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
> java.sql.SQLException: testing sql exception
> at com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResource.getJsonCountries(HolidaysRESTJSONResource.java:54)
>
> ... stack trace ...
>
> [2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
> catching sql exception]]
... and the server does not crash. You can make any request without
restarting Glassfish, right?
> ----------------------------------------------------------------
> The code that divides by zero
> ----------------------------------------------------------------
> @GET
> @Path("/countries")
> @Produces(MediaType.APPLICATION_JSON)
> public String getJsonCountries() {
> if (TempDataStorage.countryList == null) {
> Connection connection = null;
> try {
> connection = dataSource.getConnection();
> System.out.println("countries connection has been opened");
> TempDataStorage.countryList = GetCountryList.doIt(connection);
> float something = 1/0;
> connection.close();
> System.out.println("countries connection has been closed");
> } catch (SQLException e) {
> System.out.println(e);
> System.out.println("catching sql exception");
> if (connection != null) {
> try {
> connection.close();
> } catch (SQLException ex) {
> System.out.println(ex);
> }
> }
> }
> }
100% connection leak every time, guaranteed.
You are never closing the connection, because your code is throwing an
uncaught exception (divide by zero) Perhaps this was just for testing,
because I see you are intentionally dividing by zero.
The conn.close() *MUST* be in a finally {} block. Do not put it in the
try block. Do not put it in the catch block. Always put it in the
finally block.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 14, at 23:49, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
>
> I have this system running on a PC identified as localhost. The test URL is:
>
> http://localhost:8080/HolidaysRESTJSON-1.0-SNAPSHOT/webresources/holidaysandevents/countries
>
> I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
>
> Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
What do you mean by “the program did terminate”? Did GlassFish actually exit? GlassFish is the actual “program" here - your application is simply a web service running inside the GlassFish container. Perhaps you meant that a response was returned to the client.
> I take this to mean that exceptions are not being "swallowed" by my program.
Correct, but the exception actually is being swallowed by GlassFish, after logging its occurrence and returning a 500 (not 505) response to the client. The thread that encountered the exception returns to the GlassFish thread pool and does not exit.
> When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
Resource leaks can also occur by not always closing Statement, PreparedStatement, or ResultSet objects (as mentioned way back in this thread), at least some of which your application must be using. Each such resource is associated with a DB connection, but whether or not failing to explicitly close them can cause an active connection to be unavailable for reuse depends on the implementation details of the JDBC driver and the connection pool. At least in the past, sometimes a garbage collection was required to reset connections to the point they could be recycled.
Another thing to check for is retaining references to the connection or subsidiary resources in class or instance variables in your code. This seems unlikely in a web service, but should be looked at just in case.
> [2025-08-14T23:45:29.328-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=36 _ThreadName=http-listener-1(1)] [timeMillis: 1755229529328] [levelValue: 900] [[
> StandardWrapperValve[com.worldholidaysandevents.restjsonwebservice.ApplicationConfig]: Servlet.service() for servlet com.worldholidaysandevents.restjsonwebservice.ApplicationConfig threw exception
> java.lang.ArithmeticException: / by zero
> at com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResource.getJsonCountries(HolidaysRESTJSONResource.java:53)
Note the use of “servlet" in the above exception message, demonstrating that GlassFish does indeed encapsulate web services inside servlets.
Also, the exception is only logged at the warning, not error, level. If only error logging is enabled, you would never see such a message in the logs.
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Robert (and all),
I will work on answers your various questions. However, I decided to first explore the comment (by someone) that a servlet can "swallow" an exception, which I take to mean that it can throw an exception without reporting the exception or terminating the program.
I have this system running on a PC identified as localhost. The test URL is:
http://localhost:8080/HolidaysRESTJSON-1.0-SNAPSHOT/webresources/holidaysandevents/countries
I ran two tests. First, I wrote in code to throw an SQL exception, which did get caught in my catch clause, which printed out some messages and a stack trace. The web browser showed the retrieved list of countries, but nothing else.
Second, I replaced the line that throws the SQL exception by one that tries to do a division by zero. This of course was not caught, but it did print out a stack trace and reported a 505 error in the browser, and the program did terminate.
I take this to mean that exceptions are not being "swallowed" by my program. When/if an exception occurs, there is definitely some indication of this, either in the server.log or the browser. Because I have never seen either of these actions, I'm fairly sure that my program is not throwing exceptions and all database connections are being closed immediately after they are used, i.e., no memory leaks in this respect.
The actual code fragments and outputs are copied below.
----------------------------------------------------------------
The code that throws the SQL exception
----------------------------------------------------------------
@GET
@Path("/countries")
@Produces(MediaType.APPLICATION_JSON)
public String getJsonCountries() {
if (TempDataStorage.countryList == null) {
Connection connection = null;
try {
connection = dataSource.getConnection();
System.out.println("countries connection has been opened");
TempDataStorage.countryList = GetCountryList.doIt(connection);
throw new SQLException("testing sql exception");
// connection.close();
// System.out.println("countries connection has been closed");
} catch (SQLException e) {
System.out.println(e);
System.out.println("catching sql exception");
if (connection != null) {
try {
connection.close();
} catch (SQLException ex) {
System.out.println(ex);
}
}
}
}
------------------------------------------------------------------
The output in the server.log file
------------------------------------------------------------------
[2025-08-14T23:34:42.019-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882019] [levelValue: 800] [[
countries connection has been opened]]
[2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
java.sql.SQLException: testing sql exception
at com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResource.getJsonCountries(HolidaysRESTJSONResource.java:54)
... stack trace ...
[2025-08-14T23:34:42.022-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=40 _ThreadName=Thread-8] [timeMillis: 1755228882022] [levelValue: 800] [[
catching sql exception]]
----------------------------------------------------------------
The code that divides by zero
----------------------------------------------------------------
@GET
@Path("/countries")
@Produces(MediaType.APPLICATION_JSON)
public String getJsonCountries() {
if (TempDataStorage.countryList == null) {
Connection connection = null;
try {
connection = dataSource.getConnection();
System.out.println("countries connection has been opened");
TempDataStorage.countryList = GetCountryList.doIt(connection);
float something = 1/0;
connection.close();
System.out.println("countries connection has been closed");
} catch (SQLException e) {
System.out.println(e);
System.out.println("catching sql exception");
if (connection != null) {
try {
connection.close();
} catch (SQLException ex) {
System.out.println(ex);
}
}
}
}
-----------------------------------------------------------------------
The output in the server.log file
-----------------------------------------------------------------------
[2025-08-14T23:45:29.324-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1755229529324] [levelValue: 800] [[
countries connection has been opened]]
[2025-08-14T23:45:29.328-0400] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=36 _ThreadName=http-listener-1(1)] [timeMillis: 1755229529328] [levelValue: 900] [[
StandardWrapperValve[com.worldholidaysandevents.restjsonwebservice.ApplicationConfig]: Servlet.service() for servlet com.worldholidaysandevents.restjsonwebservice.ApplicationConfig threw exception
java.lang.ArithmeticException: / by zero
at com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResource.getJsonCountries(HolidaysRESTJSONResource.java:53)
... stack trace ...
------------------------------------------------------------------------
The browser showed the page:
------------------------------------------------------------------------
HTTP Status 500 - Internal Server Error
type Exception report
messageInternal Server Error
descriptionThe server encountered an internal error that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: java.lang.ArithmeticException: / by zero
root cause
java.lang.ArithmeticException: / by zero
note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 4.1 logs.
GlassFish Server Open Source Edition 4.1
-----------------------------------------------------------------------
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Thursday, August 14, 2025 6:15 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
(apologies for the top post -- this thread is getting messy)
I assume you mean JAX-RS (or similar).
As a few poeple have already pointed out, these are Servlets under the covers -- regardless, what you have described still has conflicting
statements:
- you state it's regular Java program (implies it has a main function)
- you state it's a WAR file created in IntelliJ (implies it is a Servlet-based application -- whether you are using REST, JSP or others) Those are conflicting statements and why we have been getting very confused.
Based on some of your most recent comments, I believe you are using standard Servlet packaging (WAR file), and you are definitely using Servlets under the covers, whether you wrote the Servlet class or not.
So, as you said in the email to Chris, you still have this bizarre DB connection issue. Let's see if we can get to the bottom of that...no need to discuss the "client-portion" of the program -- let's focus on just the operations (HTTP operations) that go to your server.
As I've said before, I do not expect this is an issue with Glassfish ("select isn't broken"), and that something you have done in setting up either the pool, or the rest endpoints is causing the problem. Here's a list of specific questions that would be helpful to have answers to (actual answers with data from logs, or code samples, etc.)
Q1: Are you able to post the code for a single "REST endpoint" (without the business logic), and any classes it uses? This would be much more precise and less prone to communication issues.
Q2: It's also not clear what analysis has been done on SQL connection usage?
Q3: Do you have logs from your program showing SQL connections acquisition in relation to client requests?
Q4: Have you done any analysis by reducing the pool size to the minimum and invoking single REST requests (without the client code .. it's not important to this problem)?
Q5: What do you see in terms of connection usage? If you "graphed the count", do you get something like this (fixed width font needed):
___
DB connection count over time: __/ \__
REST request: +-----+
If not, then you want to look at when the connection is released back to the pool.
You also haven't provided any information about how the requests you see coming into your server relate to the SQL connections. It would be helpful to have some correlation of these so as to provide suggestions.
Q6: Can you provide some data around the number of REST requests your server is receiving per minute (or some period) that correlates to how quickly your session pool was overflowing before you increased the size to 1000?
Q7: Could you share your pool connection configuration details? It would be helpful to know if there are "idle periods" (like after release) or "connection test" operations that might be causing some of your issues.
Q8: Can you reproduce your pool overflow condition on your development computer with a low pool count and share the Glassfish logs leading up to and including the exception?
Q9: Can you share your WEB.INF file that's packaged in your WAR file?
Robert
On Thu, Aug 14, 2025 at 5:42 PM Daniel Schwartz <da...@danielgschwartz.com>
wrote:
> Robert,
>
> Please see the reply is just sent to Chris. I think that this answers
> your questions.
>
> I don't know why people thought I was using servlets. It's a REST web
> service. I thought that this was clear.
>
> Dan
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Thursday, August 14, 2025 1:27 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Oh....
>
>
> On Thu, Aug 14, 2025, 00:57 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
> >
> >
> >
> > DGS: You are talking above my head on this, but I’m not using any
> > servlets, and the entire JVM process is the main thread.
> >
> >
> >
> > DGS: Let me put this in context. My system has two components, (1)
> > a backend REST webservice written in Java and running in Glassfish,
> > (2) a website written in Next.js that consumes the webservice. The
> > Java program access a MySql database through the Glassfish pooling system.
> > But this is just an ordinary Java program running in a single thread.
> > If this throws an exception that is caught, then the code for the
> > catch clause will output an error message, and if it throws an
> > exception that is not caught, the JRE will output a stack trace and
> > terminate. You say that Glassfish will somehow “swallow” the
> > exception and keep running. I really don’t think so. Maybe
> > something like this will happen with servlets, but this is just an
> > ordinary Java program, and this is how Java behaves. It has nothing
> > to do with
> Glassfish.
> >
>
> Now I know why are all so confused ..
>
> FWIW, this made me laugh for 3 minutes...
>
> Either you've made things much harder for yourself, or you have some
> good reason for this approach...
>
> Typically one would use a server based application with a servlet
> container (Glassfish or Tomcat).
>
> What is acting as your web server/TCP server! Performing your listen /
> accept / etc on the sockets?
>
> Are you using bits of Glassfish as a library?
>
> Is there a reference example of what you've built somewhere?
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Robert (Turner), Rob (Sargent), Chuck (Caldarale),
I think our emails are crossing. You are here replying to some earlier replies from me. I just sent another one today with more details.
In any case, I was not aware that a REST webservice had anything to do with servlets, so probably I'm the one that's confused. I guess that I misspoke when I said that it was a "regular Java program", since it doesn't have a main method. It simply sits in the Glassfish domain and responds to REST requests. Does this make it a servlet? I have written servlets before, but this is not how I did it.
Robert has asked a lot of questions. I will respond to these as best I can in a future reply.
Thanks to everyone for your attention to this. I too would like to get to the bottom of this.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Thursday, August 14, 2025 6:15 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
(apologies for the top post -- this thread is getting messy)
I assume you mean JAX-RS (or similar).
As a few poeple have already pointed out, these are Servlets under the covers -- regardless, what you have described still has conflicting
statements:
- you state it's regular Java program (implies it has a main function)
- you state it's a WAR file created in IntelliJ (implies it is a Servlet-based application -- whether you are using REST, JSP or others) Those are conflicting statements and why we have been getting very confused.
Based on some of your most recent comments, I believe you are using standard Servlet packaging (WAR file), and you are definitely using Servlets under the covers, whether you wrote the Servlet class or not.
So, as you said in the email to Chris, you still have this bizarre DB connection issue. Let's see if we can get to the bottom of that...no need to discuss the "client-portion" of the program -- let's focus on just the operations (HTTP operations) that go to your server.
As I've said before, I do not expect this is an issue with Glassfish ("select isn't broken"), and that something you have done in setting up either the pool, or the rest endpoints is causing the problem. Here's a list of specific questions that would be helpful to have answers to (actual answers with data from logs, or code samples, etc.)
Q1: Are you able to post the code for a single "REST endpoint" (without the business logic), and any classes it uses? This would be much more precise and less prone to communication issues.
Q2: It's also not clear what analysis has been done on SQL connection usage?
Q3: Do you have logs from your program showing SQL connections acquisition in relation to client requests?
Q4: Have you done any analysis by reducing the pool size to the minimum and invoking single REST requests (without the client code .. it's not important to this problem)?
Q5: What do you see in terms of connection usage? If you "graphed the count", do you get something like this (fixed width font needed):
___
DB connection count over time: __/ \__
REST request: +-----+
If not, then you want to look at when the connection is released back to the pool.
You also haven't provided any information about how the requests you see coming into your server relate to the SQL connections. It would be helpful to have some correlation of these so as to provide suggestions.
Q6: Can you provide some data around the number of REST requests your server is receiving per minute (or some period) that correlates to how quickly your session pool was overflowing before you increased the size to 1000?
Q7: Could you share your pool connection configuration details? It would be helpful to know if there are "idle periods" (like after release) or "connection test" operations that might be causing some of your issues.
Q8: Can you reproduce your pool overflow condition on your development computer with a low pool count and share the Glassfish logs leading up to and including the exception?
Q9: Can you share your WEB.INF file that's packaged in your WAR file?
Robert
On Thu, Aug 14, 2025 at 5:42 PM Daniel Schwartz <da...@danielgschwartz.com>
wrote:
> Robert,
>
> Please see the reply is just sent to Chris. I think that this answers
> your questions.
>
> I don't know why people thought I was using servlets. It's a REST web
> service. I thought that this was clear.
>
> Dan
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Thursday, August 14, 2025 1:27 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Oh....
>
>
> On Thu, Aug 14, 2025, 00:57 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
> >
> >
> >
> > DGS: You are talking above my head on this, but I’m not using any
> > servlets, and the entire JVM process is the main thread.
> >
> >
> >
> > DGS: Let me put this in context. My system has two components, (1)
> > a backend REST webservice written in Java and running in Glassfish,
> > (2) a website written in Next.js that consumes the webservice. The
> > Java program access a MySql database through the Glassfish pooling system.
> > But this is just an ordinary Java program running in a single thread.
> > If this throws an exception that is caught, then the code for the
> > catch clause will output an error message, and if it throws an
> > exception that is not caught, the JRE will output a stack trace and
> > terminate. You say that Glassfish will somehow “swallow” the
> > exception and keep running. I really don’t think so. Maybe
> > something like this will happen with servlets, but this is just an
> > ordinary Java program, and this is how Java behaves. It has nothing
> > to do with
> Glassfish.
> >
>
> Now I know why are all so confused ..
>
> FWIW, this made me laugh for 3 minutes...
>
> Either you've made things much harder for yourself, or you have some
> good reason for this approach...
>
> Typically one would use a server based application with a servlet
> container (Glassfish or Tomcat).
>
> What is acting as your web server/TCP server! Performing your listen /
> accept / etc on the sockets?
>
> Are you using bits of Glassfish as a library?
>
> Is there a reference example of what you've built somewhere?
>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
(apologies for the top post -- this thread is getting messy)
I assume you mean JAX-RS (or similar).
As a few poeple have already pointed out, these are Servlets under the
covers -- regardless, what you have described still has conflicting
statements:
- you state it's regular Java program (implies it has a main function)
- you state it's a WAR file created in IntelliJ (implies it is a
Servlet-based application -- whether you are using REST, JSP or others)
Those are conflicting statements and why we have been getting very confused.
Based on some of your most recent comments, I believe you are using
standard Servlet packaging (WAR file), and you are definitely using
Servlets under the covers, whether you wrote the Servlet class or not.
So, as you said in the email to Chris, you still have this bizarre DB
connection issue. Let's see if we can get to the bottom of that...no need
to discuss the "client-portion" of the program -- let's focus on just the
operations (HTTP operations) that go to your server.
As I've said before, I do not expect this is an issue with Glassfish
("select isn't broken"), and that something you have done in setting up
either the pool, or the rest endpoints is causing the problem. Here's a
list of specific questions that would be helpful to have answers to (actual
answers with data from logs, or code samples, etc.)
Q1: Are you able to post the code for a single "REST endpoint" (without the
business logic), and any classes it uses? This would be much more precise
and less prone to communication issues.
Q2: It's also not clear what analysis has been done on SQL connection
usage?
Q3: Do you have logs from your program showing SQL connections acquisition
in relation to client requests?
Q4: Have you done any analysis by reducing the pool size to the minimum and
invoking single REST requests (without the client code .. it's not
important to this problem)?
Q5: What do you see in terms of connection usage? If you "graphed the
count", do you get something like this (fixed width font needed):
___
DB connection count over time: __/ \__
REST request: +-----+
If not, then you want to look at when the connection is released back to
the pool.
You also haven't provided any information about how the requests you see
coming into your server relate to the SQL connections. It would be helpful
to have some correlation of these so as to provide suggestions.
Q6: Can you provide some data around the number of REST requests your
server is receiving per minute (or some period) that correlates to how
quickly your session pool was overflowing before you increased the size to
1000?
Q7: Could you share your pool connection configuration details? It would be
helpful to know if there are "idle periods" (like after release) or
"connection test" operations that might be causing some of your issues.
Q8: Can you reproduce your pool overflow condition on your development
computer with a low pool count and share the Glassfish logs leading up to
and including the exception?
Q9: Can you share your WEB.INF file that's packaged in your WAR file?
Robert
On Thu, Aug 14, 2025 at 5:42 PM Daniel Schwartz <da...@danielgschwartz.com>
wrote:
> Robert,
>
> Please see the reply is just sent to Chris. I think that this answers
> your questions.
>
> I don't know why people thought I was using servlets. It's a REST web
> service. I thought that this was clear.
>
> Dan
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Thursday, August 14, 2025 1:27 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Oh....
>
>
> On Thu, Aug 14, 2025, 00:57 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
>
> >
> >
> >
> > DGS: You are talking above my head on this, but I’m not using any
> > servlets, and the entire JVM process is the main thread.
> >
> >
> >
> > DGS: Let me put this in context. My system has two components, (1) a
> > backend REST webservice written in Java and running in Glassfish, (2)
> > a website written in Next.js that consumes the webservice. The Java
> > program access a MySql database through the Glassfish pooling system.
> > But this is just an ordinary Java program running in a single thread.
> > If this throws an exception that is caught, then the code for the
> > catch clause will output an error message, and if it throws an
> > exception that is not caught, the JRE will output a stack trace and
> > terminate. You say that Glassfish will somehow “swallow” the
> > exception and keep running. I really don’t think so. Maybe something
> > like this will happen with servlets, but this is just an ordinary Java
> > program, and this is how Java behaves. It has nothing to do with
> Glassfish.
> >
>
> Now I know why are all so confused ..
>
> FWIW, this made me laugh for 3 minutes...
>
> Either you've made things much harder for yourself, or you have some good
> reason for this approach...
>
> Typically one would use a server based application with a servlet
> container (Glassfish or Tomcat).
>
> What is acting as your web server/TCP server! Performing your listen /
> accept / etc on the sockets?
>
> Are you using bits of Glassfish as a library?
>
> Is there a reference example of what you've built somewhere?
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Robert,
Please see the reply is just sent to Chris. I think that this answers your questions.
I don't know why people thought I was using servlets. It's a REST web service. I thought that this was clear.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Thursday, August 14, 2025 1:27 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Oh....
On Thu, Aug 14, 2025, 00:57 Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
>
>
> DGS: You are talking above my head on this, but I’m not using any
> servlets, and the entire JVM process is the main thread.
>
>
>
> DGS: Let me put this in context. My system has two components, (1) a
> backend REST webservice written in Java and running in Glassfish, (2)
> a website written in Next.js that consumes the webservice. The Java
> program access a MySql database through the Glassfish pooling system.
> But this is just an ordinary Java program running in a single thread.
> If this throws an exception that is caught, then the code for the
> catch clause will output an error message, and if it throws an
> exception that is not caught, the JRE will output a stack trace and
> terminate. You say that Glassfish will somehow “swallow” the
> exception and keep running. I really don’t think so. Maybe something
> like this will happen with servlets, but this is just an ordinary Java
> program, and this is how Java behaves. It has nothing to do with Glassfish.
>
Now I know why are all so confused ..
FWIW, this made me laugh for 3 minutes...
Either you've made things much harder for yourself, or you have some good reason for this approach...
Typically one would use a server based application with a servlet container (Glassfish or Tomcat).
What is acting as your web server/TCP server! Performing your listen / accept / etc on the sockets?
Are you using bits of Glassfish as a library?
Is there a reference example of what you've built somewhere?
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Oh....
On Thu, Aug 14, 2025, 00:57 Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
>
>
> DGS: You are talking above my head on this, but I’m not using any
> servlets, and the entire JVM process is the main thread.
>
>
>
> DGS: Let me put this in context. My system has two components, (1) a
> backend REST webservice written in Java and running in Glassfish, (2) a
> website written in Next.js that consumes the webservice. The Java program
> access a MySql database through the Glassfish pooling system. But this is
> just an ordinary Java program running in a single thread. If this throws
> an exception that is caught, then the code for the catch clause will output
> an error message, and if it throws an exception that is not caught, the JRE
> will output a stack trace and terminate. You say that Glassfish will
> somehow “swallow” the exception and keep running. I really don’t think
> so. Maybe something like this will happen with servlets, but this is just
> an ordinary Java program, and this is how Java behaves. It has nothing to
> do with Glassfish.
>
Now I know why are all so confused ..
FWIW, this made me laugh for 3 minutes...
Either you've made things much harder for yourself, or you have some good
reason for this approach...
Typically one would use a server based application with a servlet container
(Glassfish or Tomcat).
What is acting as your web server/TCP server! Performing your listen /
accept / etc on the sockets?
Are you using bits of Glassfish as a library?
Is there a reference example of what you've built somewhere?
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
Accessing your website doesn’t tell us anything definitive about your implementation.
The page which makes the request is waiting for the answer. No user session is required.
Oh. At least thats the case in the servlet world. But in your java Main world we are left at a loss as to how you are handling multiple http requests concurrently. Perhaps an Executor managing a bunch of Threads?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chuck,
To avoid repeating myself, please see my reply to Chris, mailed just moments ago.
Yes, I’m considering TomEE as a future option.
Dan
From: Chuck Caldarale <n8...@gmail.com>
Sent: Thursday, August 14, 2025 2:15 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 13, at 23:55, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > See my reply below. > > Dan > > From: Chuck Caldarale <n828cl@gmail.com <ma...@gmail.com>>> > Sent: Wednesday,
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f604cc39d9bc49bad3f39f6e83e0d9c92c6831319cffe7a8792de1a755759095599f5bf3a6ece3ea0c47a725e80d6f76748181a8c97238dcc42ef76617d9d8c4ef0277948a18fb52f1359b5d3bbdd1d211722bc6197ab41b92485852f77367d1850959bf2506289beaffe2f98b23350e418648499af632bfd89702d4d17e8b4a16211313c511379a59ec7681cbd2cf171807fcee1e2341278ce8d122e34fd9568a969ce1d9e2ff291689a407f404303a2dfc03ee30ed17c13ff78a57a10351dc870757c5341424446a9ec721ed583cb9cec9671d59de4358647226ccee0f9c791779d5aaa9e5ce19f>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f604cc39d9bc49bad3f39f6e83e0d9c92c6831319cffe7a8792de1a755759095599f5bf3a6ece3ea0c47a725e80d6f76748181a8c97238dcc42ef76617d9d8c4ef0277948a18fb52f1359b5d3bbdd1d211722bc6197ab41b92485852f77367d1850959bf2506289beaffe2f98b23350e418648499af632bfd89702d4d17e8b4a16211313c511379a59ec7681cbd2cf171807fcee1e2341278ce8d122e34fd9568a969ce1d9e2ff291689a407f404303a2dfc03ee30ed17c13ff78a57a10351dc870757c5341424446a9ec721ed583cb9cec9671d59de4358647226ccee0f9c791779d5aaa9e5ce19f>
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 13, at 23:55, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> See my reply below.
>
> Dan
>
> From: Chuck Caldarale <n828cl@gmail.com <ma...@gmail.com>>>
> Sent: Wednesday, August 13, 2025 10:29 PM
> To: Tomcat Users List <users@tomcat.apache.org <ma...@tomcat.apache.org>>>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
>
> Uhhh - no. (BTW, the term “program” is rather ambiguous and really has little meaning in a servlet container environment,)
>
> Exceptions can also be caught and swallowed, with or without logging them first. An uncaught exception results in termination of a single thread, not the entire JVM process (unless it’s the main thread). Tomcat goes to great lengths to catch any exception that servlet code doesn’t, and returns an appropriate status to the client that initiated the request that encountered the exception. Tomcat normally logs exceptions it catches to the webapp’s log file, not the console (or catalina.out). There has been the rare Tomcat bug where logging was inadvertently skipped.
>
> I have no idea what Glassfish does with exceptions, but I would hope that a simple exception in a servlet running under Glassfish would not result in JVM termination - that would be really, really stupid and a violation of the servlet spec.
>
> Not sure what you mean by “Glassfish quits, not the JVM” - if Glassfish exits, the JVM process terminates (unless Glassfish is being used in embedded mode). Do you mean that it’s Glassfish that detects the error and exits rather than the JVM aborting with, for example, a segfault ("access violation" in Windows)?
>
> - Chuck
>
>
> DGS: You are talking above my head on this, but I’m not using any servlets, and the entire JVM process is the main thread.
That’s not possible. Just a “Hello World” program will spawn at least half-a-dozen threads in the JVM.
> DGS: Let me put this in context. My system has two components, (1) a backend REST webservice written in Java and running in Glassfish, (2) a website written in Next.js that consumes the webservice. The Java program access a MySql database through the Glassfish pooling system. But this is just an ordinary Java program running in a single thread. If this throws an exception that is caught, then the code for the catch clause will output an error message, and if it throws an exception that is not caught, the JRE will output a stack trace and terminate. You say that Glassfish will somehow “swallow” the exception and keep running. I really don’t think so. Maybe something like this will happen with servlets, but this is just an ordinary Java program, and this is how Java behaves. It has nothing to do with Glassfish.
Your not using servlets directly is news, and should have been made clear at the beginning of this exceptionally long thread.
Is your application really “an ordinary Java program”, or is it dependent on the JAX-RS implementation provided by GlassFish? I strongly suspect the latter, since otherwise there’s no reason for you to use a container like GlassFish.
AFAICT, GlassFish uses Jersey to implement JAX-RS (RESTful web services), which generates servlets under the hood. It almost certainly will be using more than one thread, likely creating an instance of your application’s classes for each active client request. If you have any class-level fields you will need synchronization around updates to those. (I believe that was pointed out earlier in this thread.) If you really were able to restrict GlassFish to a single thread, you wouldn’t need DB connection pooling, since a single thread wouldn’t ever need more than connection.
GlassFish likely also implements separate logging for each application - even if there’s only one, but I have no idea where those logs would be located.
Note that Tomcat does not include support for JAX-RS, so you do need something that implements more of the Jakarta-EE spec, such as TomEE (or GlassFish).
- Chuck
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 13, at 23:55, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> See my reply below.
>
> Dan
>
> From: Chuck Caldarale <n828cl@gmail.com <ma...@gmail.com>>
> Sent: Wednesday, August 13, 2025 10:29 PM
> To: Tomcat Users List <users@tomcat.apache.org <ma...@tomcat.apache.org>>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
>
> Uhhh - no. (BTW, the term “program” is rather ambiguous and really has little meaning in a servlet container environment,)
>
> Exceptions can also be caught and swallowed, with or without logging them first. An uncaught exception results in termination of a single thread, not the entire JVM process (unless it’s the main thread). Tomcat goes to great lengths to catch any exception that servlet code doesn’t, and returns an appropriate status to the client that initiated the request that encountered the exception. Tomcat normally logs exceptions it catches to the webapp’s log file, not the console (or catalina.out). There has been the rare Tomcat bug where logging was inadvertently skipped.
>
> I have no idea what Glassfish does with exceptions, but I would hope that a simple exception in a servlet running under Glassfish would not result in JVM termination - that would be really, really stupid and a violation of the servlet spec.
>
> Not sure what you mean by “Glassfish quits, not the JVM” - if Glassfish exits, the JVM process terminates (unless Glassfish is being used in embedded mode). Do you mean that it’s Glassfish that detects the error and exits rather than the JVM aborting with, for example, a segfault ("access violation" in Windows)?
>
> - Chuck
>
>
> DGS: You are talking above my head on this, but I’m not using any servlets, and the entire JVM process is the main thread.
That’s not possible. Just a “Hello World” program will spawn at least half-a-dozen threads in the JVM.
> DGS: Let me put this in context. My system has two components, (1) a backend REST webservice written in Java and running in Glassfish, (2) a website written in Next.js that consumes the webservice. The Java program access a MySql database through the Glassfish pooling system. But this is just an ordinary Java program running in a single thread. If this throws an exception that is caught, then the code for the catch clause will output an error message, and if it throws an exception that is not caught, the JRE will output a stack trace and terminate. You say that Glassfish will somehow “swallow” the exception and keep running. I really don’t think so. Maybe something like this will happen with servlets, but this is just an ordinary Java program, and this is how Java behaves. It has nothing to do with Glassfish.
Your not using servlets directly is news, and should have been made clear at the beginning of this exceptionally long thread.
Is your application really “an ordinary Java program”, or is it dependent on the JAX-RS implementation provided by GlassFish? I strongly suspect the latter, since otherwise there’s no reason for you to use a container like GlassFish.
AFAICT, GlassFish uses Jersey to implement JAX-RS (RESTful web services), which generates servlets under the hood. It almost certainly will be using more than one thread, likely creating an instance of your application’s classes for each active client request. If you have any class-level fields you will need synchronization around updates to those. (I believe that was pointed out earlier in this thread.) If you really were able to restrict GlassFish to a single thread, you wouldn’t need DB connection pooling, since a single thread wouldn’t ever need more than connection.
GlassFish likely also implements separate logging for each application - even if there’s only one, but I have no idea where those logs would be located.
Note that Tomcat does not include support for JAX-RS, so you do need something that implements more of the Jakarta-EE spec, such as TomEE (or GlassFish).
- Chuck
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Felix,
See my reply below marked DGS.
Dan
From: Felix Schumacher <fe...@internetallee.de>
Sent: Friday, August 15, 2025 1:09 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Am 14.08.25 um 23:26 schrieb Daniel Schwartz:
Chris,
See below.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Thursday, August 14, 2025 2:47 PM
To: users@tomcat.apache.org<ma...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Dan,
Like Robert, I am confused.
Read on for more replies...
On 8/14/25 12:55 AM, Daniel Schwartz wrote:
From: Chuck Caldarale <n8...@gmail.com>
Sent: Wednesday, August 13, 2025 10:29 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
...
Are you using the Glassfish application server, or only the Glassfish connection pool? Or something else?
If you are not using Glassfish server, what code is binding to the socket, listening on a port, and accepting connections? That's usually Glassfish or whatever other application server you are using.
It would be very unusual to build a REST service with your own code handling the HTTP stuff. Instead, you use the application server to handle all the HTTP noise, as well as configuring your data source and handing to you through JNDI (which we *know* you are using to get the DataSource). Then your code is written to the servlet specification and all is well. You may be using a servlet even if you don't know it e.g.
if you are using JSP.
If you are only using the Glassfish connection pool, then this conversation just got a whole lot more interesting.
DGS:
Let me put this in context. I have created a REST webservice using IntelliJ IDEA, which produces a .war file that I drop into Glassfish domain1. This deploys, and can receive REST requests on port 3000 (I think). The webservice has code that accesses MySQL through the Glassfish JDBC connection pool. The REST requests come from the website, written using Next.js, which serves as the user interface. Repeating my previous example, suppose you want to see the holidays and events for Tallahassee, Florida, USA, for the year 2025. When you enter the website, the "Countries" drop down is filled automatically by a request to the webservice to retrieve the current contents of a MySQL "Countries" table, which contains the current list of available countries. This requires one DB connection. Then, in the "Countries" drop down, select "United States of America". This initiates another REST request which amounts to executing two DB queries, getting the list of states and the list of countries associated with United States of America. These fill the "States" and "Cities" drop downs. This is a second DB connection. Then, in the "States" drop down list, select Florida. This initiates one further REST request to get the cities associated only with Florida, and refills the "Cities" drop down with just these. This is a third DB connection. Then, select Tallahassee from the "Cities" drop down, and select 2025, from the "Year" date picker, and click the "Explore" button. This initiates a fourth REST request which requires one last DB connection to retrieve all the data required to calculate the dates for requested holidays and events, with these calculated data being displayed to the user in the website.
I looked at your website at https://www.worldholidaysandevents.com/
It seems to work in a way, that the landing page includes all countries. That is probably your first connection to the db to get the country list.
On that page, when I select a country a http request is send to your server to retrieve the states of that country, which is your second connection to the db.
Now, when I select a state, another http request is send and a select box with cities is filled, which will correspond to another connection to your db.
After I selected the city, I can "explore" by pressing the button with the same label and fourth request is send and probably your fourth db connection is used.
Given that picture is right, I would expect only a single connection ever used for a complete walk through, as a user can only take the next step (and the next connection), when the data has been delivered and thus the connection should have been returned to the pool.
Therefore you either have more load on your service than we think, or there is something fishy with your handling of the pool/connection.
To get you even more sidetracked, the used HTTP method for the steps to fetch the states and cities should use a GET method and not a POST method, as surely nothing should be changed on the server. And to get caching work, it would probably be better to put the name of the country/state together with the wanted resource into the URL instead of the request body.
So, there is a series of four independent DB connections, executed in a series, and there is no way to combine these without somehow associating them with a single user "session", which you have said is a bad idea. So there really is not good alternative to what I am currently doing, as far as I know.
Right, seems so, but you could cache those pages on the client and on the edge (your webserver in front of glassfish), if you would use a nicer naming scheme for the URLs and GET instead of POST.
DSG: The only way I know of to combine those four connections into one is to identify a client session on the client side and then assign one database connection to each session. However, I’m advised by others on this list that this is a bad idea because a user could neglect to terminate a session, thereby leaving the database connection open for an indefinite amount of time.
Felix
...
The fact that no memory leaks are occurring is also supported by the Glassfish connection pool monitoring system, which says that there are 0 (zero) potential leaks. How it knows this, I have no idea. But this is what it says.
This still leaves open the question regarding why my system seems to use an unusually large number of DB connections. After all that has been said in these discussions, I still have no answer for this. It might have something to do with how Glassfish is configured, but the person I talked with at Omnifish seemed think that this behavior is normal. I really don't know.
However, since the system seems to be running fine simply by setting the maximum pool size to be 1000, I've decided to not worry about it for the time being. But I'm still keeping in mind the possibility of switching to Tomcat, if further problems arise.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 14.08.25 um 23:26 schrieb Daniel Schwartz:
> Chris,
>
> See below.
>
> Dan
>
> -----Original Message-----
> From: Christopher Schultz<ch...@christopherschultz.net>
> Sent: Thursday, August 14, 2025 2:47 PM
> To:users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
> Dan,
>
> Like Robert, I am confused.
>
> Read on for more replies...
>
> On 8/14/25 12:55 AM, Daniel Schwartz wrote:
>> From: Chuck Caldarale<n8...@gmail.com>
>> Sent: Wednesday, August 13, 2025 10:29 PM
>> To: Tomcat Users List<us...@tomcat.apache.org>
>> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> ...
> Are you using the Glassfish application server, or only the Glassfish connection pool? Or something else?
>
> If you are not using Glassfish server, what code is binding to the socket, listening on a port, and accepting connections? That's usually Glassfish or whatever other application server you are using.
>
> It would be very unusual to build a REST service with your own code handling the HTTP stuff. Instead, you use the application server to handle all the HTTP noise, as well as configuring your data source and handing to you through JNDI (which we *know* you are using to get the DataSource). Then your code is written to the servlet specification and all is well. You may be using a servlet even if you don't know it e.g.
> if you are using JSP.
>
> If you are only using the Glassfish connection pool, then this conversation just got a whole lot more interesting.
>
> DGS:
>
> Let me put this in context. I have created a REST webservice using IntelliJ IDEA, which produces a .war file that I drop into Glassfish domain1. This deploys, and can receive REST requests on port 3000 (I think). The webservice has code that accesses MySQL through the Glassfish JDBC connection pool. The REST requests come from the website, written using Next.js, which serves as the user interface. Repeating my previous example, suppose you want to see the holidays and events for Tallahassee, Florida, USA, for the year 2025. When you enter the website, the "Countries" drop down is filled automatically by a request to the webservice to retrieve the current contents of a MySQL "Countries" table, which contains the current list of available countries. This requires one DB connection. Then, in the "Countries" drop down, select "United States of America". This initiates another REST request which amounts to executing two DB queries, getting the list of states and the list of countries associated with United States of America. These fill the "States" and "Cities" drop downs. This is a second DB connection. Then, in the "States" drop down list, select Florida. This initiates one further REST request to get the cities associated only with Florida, and refills the "Cities" drop down with just these. This is a third DB connection. Then, select Tallahassee from the "Cities" drop down, and select 2025, from the "Year" date picker, and click the "Explore" button. This initiates a fourth REST request which requires one last DB connection to retrieve all the data required to calculate the dates for requested holidays and events, with these calculated data being displayed to the user in the website.
I looked at your website at https://www.worldholidaysandevents.com/
It seems to work in a way, that the landing page includes all countries.
That is probably your first connection to the db to get the country list.
On that page, when I select a country a http request is send to your
server to retrieve the states of that country, which is your second
connection to the db.
Now, when I select a state, another http request is send and a select
box with cities is filled, which will correspond to another connection
to your db.
After I selected the city, I can "explore" by pressing the button with
the same label and fourth request is send and probably your fourth db
connection is used.
Given that picture is right, I would expect only a single connection
ever used for a complete walk through, as a user can only take the next
step (and the next connection), when the data has been delivered and
thus the connection should have been returned to the pool.
Therefore you either have more load on your service than we think, or
there is something fishy with your handling of the pool/connection.
To get you even more sidetracked, the used HTTP method for the steps to
fetch the states and cities should use a GET method and not a POST
method, as surely nothing should be changed on the server. And to get
caching work, it would probably be better to put the name of the
country/state together with the wanted resource into the URL instead of
the request body.
>
> So, there is a series of four independent DB connections, executed in a series, and there is no way to combine these without somehow associating them with a single user "session", which you have said is a bad idea. So there really is not good alternative to what I am currently doing, as far as I know.
Right, seems so, but you could cache those pages on the client and on
the edge (your webserver in front of glassfish), if you would use a
nicer naming scheme for the URLs and GET instead of POST.
Felix
> ...
> The fact that no memory leaks are occurring is also supported by the Glassfish connection pool monitoring system, which says that there are 0 (zero) potential leaks. How it knows this, I have no idea. But this is what it says.
>
> This still leaves open the question regarding why my system seems to use an unusually large number of DB connections. After all that has been said in these discussions, I still have no answer for this. It might have something to do with how Glassfish is configured, but the person I talked with at Omnifish seemed think that this behavior is normal. I really don't know.
>
> However, since the system seems to be running fine simply by setting the maximum pool size to be 1000, I've decided to not worry about it for the time being. But I'm still keeping in mind the possibility of switching to Tomcat, if further problems arise.
>
> -chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:users-help@tomcat.apache.org
>
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
See below.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Thursday, August 14, 2025 2:47 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
Dan,
Like Robert, I am confused.
Read on for more replies...
On 8/14/25 12:55 AM, Daniel Schwartz wrote:
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Wednesday, August 13, 2025 10:29 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
>> -----Original Message-----
>
>> From: Christopher Schultz
>> <ch...@christopherschultz.net>>
>
>> Sent: Wednesday, August 13, 2025 2:21 PM
>
>> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>
>> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
>>
>
>> Application servers don't work that way. A failed request stops the request, not the application. If the JVM quits when you run out of connections, this is a very unusual configuration you are running under.
>
>>
>
>> DGS: I think we miscommunicated. Someone was suggesting that my problem was that my Java program was throwing exceptions before it released the database connections, but this can't be possible, because if an exception was being thrown then either (1) the exception is caught and an error message is printed out, and the program keeps running, or (2) the error is not caught and the JVM outputs a stack trace and terminates. Neither of these ever happened, indicating that no exceptions are being thrown. The only time the program quits is when Glassfish can't make any further connections. In this case it is Glassfish that quits, not the JVM.
>
> Uhhh - no. (BTW, the term “program” is rather ambiguous and really has
> little meaning in a servlet container environment,)
>
>
>
> Exceptions can also be caught and swallowed, with or without logging them first. An uncaught exception results in termination of a single thread, not the entire JVM process (unless it’s the main thread). Tomcat goes to great lengths to catch any exception that servlet code doesn’t, and returns an appropriate status to the client that initiated the request that encountered the exception. Tomcat normally logs exceptions it catches to the webapp’s log file, not the console (or catalina.out). There has been the rare Tomcat bug where logging was inadvertently skipped.
>
>
>
> I have no idea what Glassfish does with exceptions, but I would hope that a simple exception in a servlet running under Glassfish would not result in JVM termination - that would be really, really stupid and a violation of the servlet spec.
>
>
>
> Not sure what you mean by “Glassfish quits, not the JVM” - if Glassfish exits, the JVM process terminates (unless Glassfish is being used in embedded mode). Do you mean that it’s Glassfish that detects the error and exits rather than the JVM aborting with, for example, a segfault ("access violation" in Windows)?
>
>
>
> - Chuck
>
>
>
> DGS: You are talking above my head on this, but I’m not using any servlets, and the entire JVM process is the main thread.
>
>
>
> DGS: Let me put this in context. My system has two components, (1) a backend REST webservice written in Java and running in Glassfish, (2) a website written in Next.js that consumes the webservice. The Java program access a MySql database through the Glassfish pooling system. But this is just an ordinary Java program running in a single thread. If this throws an exception that is caught, then the code for the catch clause will output an error message, and if it throws an exception that is not caught, the JRE will output a stack trace and terminate. You say that Glassfish will somehow “swallow” the exception and keep running. I really don’t think so. Maybe something like this will happen with servlets, but this is just an ordinary Java program, and this is how Java behaves. It has nothing to do with Glassfish.
Are you using the Glassfish application server, or only the Glassfish connection pool? Or something else?
If you are not using Glassfish server, what code is binding to the socket, listening on a port, and accepting connections? That's usually Glassfish or whatever other application server you are using.
It would be very unusual to build a REST service with your own code handling the HTTP stuff. Instead, you use the application server to handle all the HTTP noise, as well as configuring your data source and handing to you through JNDI (which we *know* you are using to get the DataSource). Then your code is written to the servlet specification and all is well. You may be using a servlet even if you don't know it e.g.
if you are using JSP.
If you are only using the Glassfish connection pool, then this conversation just got a whole lot more interesting.
DGS:
Let me put this in context. I have created a REST webservice using IntelliJ IDEA, which produces a .war file that I drop into Glassfish domain1. This deploys, and can receive REST requests on port 3000 (I think). The webservice has code that accesses MySQL through the Glassfish JDBC connection pool. The REST requests come from the website, written using Next.js, which serves as the user interface. Repeating my previous example, suppose you want to see the holidays and events for Tallahassee, Florida, USA, for the year 2025. When you enter the website, the "Countries" drop down is filled automatically by a request to the webservice to retrieve the current contents of a MySQL "Countries" table, which contains the current list of available countries. This requires one DB connection. Then, in the "Countries" drop down, select "United States of America". This initiates another REST request which amounts to executing two DB queries, getting the list of states and the list of countries associated with United States of America. These fill the "States" and "Cities" drop downs. This is a second DB connection. Then, in the "States" drop down list, select Florida. This initiates one further REST request to get the cities associated only with Florida, and refills the "Cities" drop down with just these. This is a third DB connection. Then, select Tallahassee from the "Cities" drop down, and select 2025, from the "Year" date picker, and click the "Explore" button. This initiates a fourth REST request which requires one last DB connection to retrieve all the data required to calculate the dates for requested holidays and events, with these calculated data being displayed to the user in the website.
So, there is a series of four independent DB connections, executed in a series, and there is no way to combine these without somehow associating them with a single user "session", which you have said is a bad idea. So there really is not good alternative to what I am currently doing, as far as I know.
I have written servlets, in fact previously taught a course on Servlets and JSP. I know what these are. My system doesn't use servlets. The REST webservice is an ordinary Java program running on a single thread.
There was at some point speculation that a memory leak was occurring by my program first creating a connection and then throwing an exception before the connection was being closed. However, I have determined that this is not happening, because, if an exception were being thrown, I would know about it. My code currently catches SQL exceptions, and prints out an error message when/if it gets one; and if some other type of exception is thrown, the JVM will output a stack trace and terminate. Neither of these events have ever occurred. So, no exceptions are being thrown, in which case no memory leaks are occurring (at least not this way).
The fact that no memory leaks are occurring is also supported by the Glassfish connection pool monitoring system, which says that there are 0 (zero) potential leaks. How it knows this, I have no idea. But this is what it says.
This still leaves open the question regarding why my system seems to use an unusually large number of DB connections. After all that has been said in these discussions, I still have no answer for this. It might have something to do with how Glassfish is configured, but the person I talked with at Omnifish seemed think that this behavior is normal. I really don't know.
However, since the system seems to be running fine simply by setting the maximum pool size to be 1000, I've decided to not worry about it for the time being. But I'm still keeping in mind the possibility of switching to Tomcat, if further problems arise.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
Like Robert, I am confused.
Read on for more replies...
On 8/14/25 12:55 AM, Daniel Schwartz wrote:
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Wednesday, August 13, 2025 10:29 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] How to access a REST service
>
>> -----Original Message-----
>
>> From: Christopher Schultz <ch...@christopherschultz.net>>
>
>> Sent: Wednesday, August 13, 2025 2:21 PM
>
>> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>
>> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
>>
>
>> Application servers don't work that way. A failed request stops the request, not the application. If the JVM quits when you run out of connections, this is a very unusual configuration you are running under.
>
>>
>
>> DGS: I think we miscommunicated. Someone was suggesting that my problem was that my Java program was throwing exceptions before it released the database connections, but this can't be possible, because if an exception was being thrown then either (1) the exception is caught and an error message is printed out, and the program keeps running, or (2) the error is not caught and the JVM outputs a stack trace and terminates. Neither of these ever happened, indicating that no exceptions are being thrown. The only time the program quits is when Glassfish can't make any further connections. In this case it is Glassfish that quits, not the JVM.
>
> Uhhh - no. (BTW, the term “program” is rather ambiguous and really has little meaning in a servlet container environment,)
>
>
>
> Exceptions can also be caught and swallowed, with or without logging them first. An uncaught exception results in termination of a single thread, not the entire JVM process (unless it’s the main thread). Tomcat goes to great lengths to catch any exception that servlet code doesn’t, and returns an appropriate status to the client that initiated the request that encountered the exception. Tomcat normally logs exceptions it catches to the webapp’s log file, not the console (or catalina.out). There has been the rare Tomcat bug where logging was inadvertently skipped.
>
>
>
> I have no idea what Glassfish does with exceptions, but I would hope that a simple exception in a servlet running under Glassfish would not result in JVM termination - that would be really, really stupid and a violation of the servlet spec.
>
>
>
> Not sure what you mean by “Glassfish quits, not the JVM” - if Glassfish exits, the JVM process terminates (unless Glassfish is being used in embedded mode). Do you mean that it’s Glassfish that detects the error and exits rather than the JVM aborting with, for example, a segfault ("access violation" in Windows)?
>
>
>
> - Chuck
>
>
>
> DGS: You are talking above my head on this, but I’m not using any servlets, and the entire JVM process is the main thread.
>
>
>
> DGS: Let me put this in context. My system has two components, (1) a backend REST webservice written in Java and running in Glassfish, (2) a website written in Next.js that consumes the webservice. The Java program access a MySql database through the Glassfish pooling system. But this is just an ordinary Java program running in a single thread. If this throws an exception that is caught, then the code for the catch clause will output an error message, and if it throws an exception that is not caught, the JRE will output a stack trace and terminate. You say that Glassfish will somehow “swallow” the exception and keep running. I really don’t think so. Maybe something like this will happen with servlets, but this is just an ordinary Java program, and this is how Java behaves. It has nothing to do with Glassfish.
Are you using the Glassfish application server, or only the Glassfish
connection pool? Or something else?
If you are not using Glassfish server, what code is binding to the
socket, listening on a port, and accepting connections? That's usually
Glassfish or whatever other application server you are using.
It would be very unusual to build a REST service with your own code
handling the HTTP stuff. Instead, you use the application server to
handle all the HTTP noise, as well as configuring your data source and
handing to you through JNDI (which we *know* you are using to get the
DataSource). Then your code is written to the servlet specification and
all is well. You may be using a servlet even if you don't know it e.g.
if you are using JSP.
If you are only using the Glassfish connection pool, then this
conversation just got a whole lot more interesting.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hi Chuck,
See my reply below.
Dan
From: Chuck Caldarale <n8...@gmail.com>
Sent: Wednesday, August 13, 2025 10:29 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
> On 2025 Aug 13, at 20:27, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > Chris, > > See my reply to your comment. > > Dan > -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net>>
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Chuck Caldarale <n8...@gmail.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fa98110f9f78623bc8099677906920df3d9bf0bc7620a029c68032ad953b6e292b42666fe10c749ab1316b2c67ff5f28b0acac4a4de02e79510f3cba6e49354f48b85ec42a339e28ec01e514e3c1a92c032a26bf4e674bcab96e2179aa20c69ea082d01ecc06485f35f7fb8e66270993d2062fdea52bfff06c26f17a34947d0887c654327ae6693d916a0fa58f477dac80cc32ddba49f588b23abbb7a5dda0378a2ede9514879e08c923706275c36485ba5a85bcc50f76f3a271e0ab40ac64b36bf6e374e709ade5b26f78e00213d91e80ab10aa32982a61289f9a0422e73a7e7298f94f1836de921>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5fa98110f9f78623bc8099677906920df3d9bf0bc7620a029c68032ad953b6e292b42666fe10c749ab1316b2c67ff5f28b0acac4a4de02e79510f3cba6e49354f48b85ec42a339e28ec01e514e3c1a92c032a26bf4e674bcab96e2179aa20c69ea082d01ecc06485f35f7fb8e66270993d2062fdea52bfff06c26f17a34947d0887c654327ae6693d916a0fa58f477dac80cc32ddba49f588b23abbb7a5dda0378a2ede9514879e08c923706275c36485ba5a85bcc50f76f3a271e0ab40ac64b36bf6e374e709ade5b26f78e00213d91e80ab10aa32982a61289f9a0422e73a7e7298f94f1836de921>
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 13, at 20:27, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Chris,
>
> See my reply to your comment.
>
> Dan
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>>
> Sent: Wednesday, August 13, 2025 2:21 PM
> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> Application servers don't work that way. A failed request stops the request, not the application. If the JVM quits when you run out of connections, this is a very unusual configuration you are running under.
>
> DGS: I think we miscommunicated. Someone was suggesting that my problem was that my Java program was throwing exceptions before it released the database connections, but this can't be possible, because if an exception was being thrown then either (1) the exception is caught and an error message is printed out, and the program keeps running, or (2) the error is not caught and the JVM outputs a stack trace and terminates. Neither of these ever happened, indicating that no exceptions are being thrown. The only time the program quits is when Glassfish can't make any further connections. In this case it is Glassfish that quits, not the JVM.
Uhhh - no. (BTW, the term “program” is rather ambiguous and really has little meaning in a servlet container environment,)
Exceptions can also be caught and swallowed, with or without logging them first. An uncaught exception results in termination of a single thread, not the entire JVM process (unless it’s the main thread). Tomcat goes to great lengths to catch any exception that servlet code doesn’t, and returns an appropriate status to the client that initiated the request that encountered the exception. Tomcat normally logs exceptions it catches to the webapp’s log file, not the console (or catalina.out). There has been the rare Tomcat bug where logging was inadvertently skipped.
I have no idea what Glassfish does with exceptions, but I would hope that a simple exception in a servlet running under Glassfish would not result in JVM termination - that would be really, really stupid and a violation of the servlet spec.
Not sure what you mean by “Glassfish quits, not the JVM” - if Glassfish exits, the JVM process terminates (unless Glassfish is being used in embedded mode). Do you mean that it’s Glassfish that detects the error and exits rather than the JVM aborting with, for example, a segfault ("access violation" in Windows)?
- Chuck
DGS: You are talking above my head on this, but I’m not using any servlets, and the entire JVM process is the main thread.
DGS: Let me put this in context. My system has two components, (1) a backend REST webservice written in Java and running in Glassfish, (2) a website written in Next.js that consumes the webservice. The Java program access a MySql database through the Glassfish pooling system. But this is just an ordinary Java program running in a single thread. If this throws an exception that is caught, then the code for the catch clause will output an error message, and if it throws an exception that is not caught, the JRE will output a stack trace and terminate. You say that Glassfish will somehow “swallow” the exception and keep running. I really don’t think so. Maybe something like this will happen with servlets, but this is just an ordinary Java program, and this is how Java behaves. It has nothing to do with Glassfish.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: [EXTERNAL EMAIL] How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 13, at 20:27, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Chris,
>
> See my reply to your comment.
>
> Dan
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Wednesday, August 13, 2025 2:21 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> Application servers don't work that way. A failed request stops the request, not the application. If the JVM quits when you run out of connections, this is a very unusual configuration you are running under.
>
> DGS: I think we miscommunicated. Someone was suggesting that my problem was that my Java program was throwing exceptions before it released the database connections, but this can't be possible, because if an exception was being thrown then either (1) the exception is caught and an error message is printed out, and the program keeps running, or (2) the error is not caught and the JVM outputs a stack trace and terminates. Neither of these ever happened, indicating that no exceptions are being thrown. The only time the program quits is when Glassfish can't make any further connections. In this case it is Glassfish that quits, not the JVM.
Uhhh - no. (BTW, the term “program” is rather ambiguous and really has little meaning in a servlet container environment,)
Exceptions can also be caught and swallowed, with or without logging them first. An uncaught exception results in termination of a single thread, not the entire JVM process (unless it’s the main thread). Tomcat goes to great lengths to catch any exception that servlet code doesn’t, and returns an appropriate status to the client that initiated the request that encountered the exception. Tomcat normally logs exceptions it catches to the webapp’s log file, not the console (or catalina.out). There has been the rare Tomcat bug where logging was inadvertently skipped.
I have no idea what Glassfish does with exceptions, but I would hope that a simple exception in a servlet running under Glassfish would not result in JVM termination - that would be really, really stupid and a violation of the servlet spec.
Not sure what you mean by “Glassfish quits, not the JVM” - if Glassfish exits, the JVM process terminates (unless Glassfish is being used in embedded mode). Do you mean that it’s Glassfish that detects the error and exits rather than the JVM aborting with, for example, a segfault ("access violation" in Windows)?
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
See my reply to your comment.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Wednesday, August 13, 2025 2:21 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
Dan,
At the risk of extending an already-lengthy conversation...
On 8/12/25 1:31 PM, Daniel Schwartz wrote:
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Tuesday, August 12, 2025 11:19 AM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> Daniel,
>
> On 8/11/25 9:38 PM, Daniel Schwartz wrote:
>> Chris,
>>
>> Again, see my replies marked DSG.
>>
>> Dan
>>
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>
>> Sent: Monday, August 11, 2025 3:21 PM
>> To: users@tomcat.apache.org
>> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>>
>> Daniel,
>>
>> On 8/5/25 3:05 PM, Daniel Schwartz wrote:
>>> I just replied to Rob Sargent regarding this. Did you see that reply?
>>>
>> > Maybe I’m not using Glassfish correctly, but if I set the
>> maximum> pool size to 1, the system almost immediately outputs an
>> error
>>> message saying that it is unable to allocate any more connections
>>> and crashes.
>> I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse?
>>
>> DGS: By "crashes" I mean that the program terminates, usually just after printing out a stack trace.
>
> O_O
>
> Like... the JVM completely exits and you have to re-start Tomcat? That
> sounds ... suspicious. I don't think I've ever taken down Tomcat in
> the
> 20+ years I've been using it. Application in an unusable state? Sure.
> But exiting the JVM usually requires a JVM bug or tcnative crash.
>
> DGS: I'm a Java programmer. This is normal behavior. If an exception is thrown and there is no provision for catching it, the JRE outputs a stack trace and terminates the program. However, this has never happened in my program. The program itself doesn't crash, only Glassfish does when it can't create any more connections.
Application servers don't work that way. A failed request stops the request, not the application. If the JVM quits when you run out of connections, this is a very unusual configuration you are running under.
DGS: I think we miscommunicated. Someone was suggesting that my problem was that my Java program was throwing exceptions before it released the database connections, but this can't be possible, because if an exception was being thrown then either (1) the exception is caught and an error message is printed out, and the program keeps running, or (2) the error is not caught and the JVM outputs a stack trace and terminates. Neither of these ever happened, indicating that no exceptions are being thrown. The only time the program quits is when Glassfish can't make any further connections. In this case it is Glassfish that quits, not the JVM.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
At the risk of extending an already-lengthy conversation...
On 8/12/25 1:31 PM, Daniel Schwartz wrote:
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Tuesday, August 12, 2025 11:19 AM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> Daniel,
>
> On 8/11/25 9:38 PM, Daniel Schwartz wrote:
>> Chris,
>>
>> Again, see my replies marked DSG.
>>
>> Dan
>>
>> -----Original Message-----
>> From: Christopher Schultz <ch...@christopherschultz.net>
>> Sent: Monday, August 11, 2025 3:21 PM
>> To: users@tomcat.apache.org
>> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>>
>> Daniel,
>>
>> On 8/5/25 3:05 PM, Daniel Schwartz wrote:
>>> I just replied to Rob Sargent regarding this. Did you see that reply?
>>>
>> > Maybe I’m not using Glassfish correctly, but if I set the maximum>
>> pool size to 1, the system almost immediately outputs an error
>>> message saying that it is unable to allocate any more connections and
>>> crashes.
>> I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse?
>>
>> DGS: By "crashes" I mean that the program terminates, usually just after printing out a stack trace.
>
> O_O
>
> Like... the JVM completely exits and you have to re-start Tomcat? That sounds ... suspicious. I don't think I've ever taken down Tomcat in the
> 20+ years I've been using it. Application in an unusable state? Sure.
> But exiting the JVM usually requires a JVM bug or tcnative crash.
>
> DGS: I'm a Java programmer. This is normal behavior. If an exception is thrown and there is no provision for catching it, the JRE outputs a stack trace and terminates the program. However, this has never happened in my program. The program itself doesn't crash, only Glassfish does when it can't create any more connections.
Application servers don't work that way. A failed request stops the
request, not the application. If the JVM quits when you run out of
connections, this is a very unusual configuration you are running under.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
Thanks for the detailed response. I'll keep this on file for future reference, but it's a bigger project than what I am prepared to undertake at this time.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Thursday, August 14, 2025 2:39 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
Daniel,
On 8/13/25 8:59 PM, Daniel Schwartz wrote:
> Chris,
>
> You have given me a lot to think about.
>
> Re your comment: "Getting ApacheBench is different depending upon your development environment. If you let me know your OS, etc. I can point you in the right direction."
>
> I found the following via Google:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__httpd.apache.org_
> docs_2.4_programs_ab.html&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_C
> dpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=FYTiEEGpxyI
> 35g9WJ8y3fZ5Je8vX4M0GpF72IoEhQPue-CY-PAjC4EZQkilLkh6l&s=RB3ipIsWbOeYvC
> xSoWA_XG74cg6FprWIk4WS3qqZheI&e= This indicates that it comes as a
> part of the Apache HTTP server and is useful only for this. Is there a version that works with Glassfish? Is there any documentation?
ab is a utility that you can run against any web server, including both Glassfish and Tomcat. It *does* come with Apache httpd, but you can get it separately and don't have to install the web server to use it.
> I'm running on Windows on AWS.
Apache Lounge [1] has binary versions of Apache httpd which include the utility. I didn't see any option to just get ab.exe from there, but you can download the ZIP package for Apache httpd and just take what you need.
ChatGPT tells me that you will need these files from the ZIP archive:
ab.exe
Required DLLs (usually):
libhttpd.dll
libapr-1.dll
libaprutil-1.dll
pcre.dll or pcre2-*.dll (depending on version) ssleay32.dll, libeay32.dll, or OpenSSL DLLs (if SSL support is needed)
Just extract all those files into the same directory and run "ab" from the command line.
It's a CLI tool, so you'll do a lot of typing. I would refer to the documentation[2] to see what all the options are and what they mean.
I would start with something simple like this:
C:> ab -n 10 https://urldefense.proofpoint.com/v2/url?u=https-3A__example.com_yourapp_page&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=FYTiEEGpxyI35g9WJ8y3fZ5Je8vX4M0GpF72IoEhQPue-CY-PAjC4EZQkilLkh6l&s=g3Ca5FqEeCz6u0NYTSKj2F5wNT_ELJ4A7Ndjx6Mu1Lw&e=
This will make 10 requests and give you some statistics. Then check your Glassfish pool counters.
If you get a weird error like "apr_socket_connect(): Invalid argument (22)" or something, try using "127.0.0.1" instead of "localhost".
-chris
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__apachelounge.com_downloads&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=FYTiEEGpxyI35g9WJ8y3fZ5Je8vX4M0GpF72IoEhQPue-CY-PAjC4EZQkilLkh6l&s=NOeF_ACBzetTE-QvTk1zfjY5rdjlIEjHcTq3IG4MzSQ&e=
[2] (https://urldefense.proofpoint.com/v2/url?u=https-3A__apachelounge.com_downloads&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=FYTiEEGpxyI35g9WJ8y3fZ5Je8vX4M0GpF72IoEhQPue-CY-PAjC4EZQkilLkh6l&s=NOeF_ACBzetTE-QvTk1zfjY5rdjlIEjHcTq3IG4MzSQ&e=)
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Wednesday, August 13, 2025 2:49 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> Dan,
>
> On 8/12/25 11:33 PM, Daniel Schwartz wrote:
>> -----Original Message-----
>> From: Robert Turner <rt...@e-djuster.ca.INVALID>
>> Sent: Tuesday, August 12, 2025 11:09 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>>
> > [snip]>
>> 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?
>
> I suspect what Robert means by "annotate your code with diagnostics as needed" just means "put something in your code to record additional information. For example, logging the request URI, number of db connections obtained, the amount of time each connection took to obtain (~13ms ain't bad, but it's not exactly lightning-fast, either), and *the amount of time you spend doing your queries before the connections are returned to the pool* which seems to be something worth knowing.
>
> As for "what sort of test", I would recommend setting up a load-test in a development environment like your own workstation. Get your application running locally with the smallest pool you can muster (8 connections? Weird that there is a minimum number of connections in this pool... I'm not impressed). Make a few requests manually to ensure that the application is working "normally". Then, unleash a load test on the application.
>
> There are a number of ways to do this.
>
> First, you can mash RELOAD in your web browser and see what happens.
> That's usually not very helpful and doesn't give you much useful data.
>
> Another simple load-test is to use curl from the command line like this:
>
> $ while true ; do curl
> https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_y
> our_application_page&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnV
> fiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4
> jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=di3ilaaf964xSIwNBTX
> tkVqVtJr5iPLPVNWhYYVb9Xw&e= > /dev/null; done
>
> That will pound your application harder than you probably can through your web browser. Pretty CTRL-C to stop the madness.
>
> When you are ready for proper load-testing, consider a simple tool like ab [1]. Getting ApacheBench is different depending upon your development environment. If you let me know your OS, etc. I can point you in the right direction.
>
> When you are ready to go down a very deep rabbit hole, you can use JMeter[2] but I suspect you will be able to learn a lot using both curl and ab, with ab being the much better choice.
>
> I'm hoping you are able to get some questions answered about your application like:
>
> 1. If I configure the pool with 8 connections, how many requests (in
> series) are required to get the pool to break?
>
> 2. If I configure the pool with 8 connections, how many requests (in
> parallel) are required to get the pool to break?
>
> 3. If I configure the pool with 100 connections, how many requests (in
> series) are required to get the pool to break?
>
> 4. If I configure the pool with 100 connections, how many requests (in parallel are required to get the pool to break?
>
> 5. What's the average response-time for a large number of serial requests? Hopefully, it's "fast". For most users, a second of latency is about when people start getting bored waiting for your site and consider switching to a competitor. Most users are also willing to wait a lot longer for some specific things. But loading your home page isn't one of them. "Generate a complex report for me?" Sure, they'll wait. But "click on the item to get details" is not something you want to make people wait for.
>
> 6. What's the average response-time for a large number of parallel
> requests, mixed-in with serial requests at the same time. This
> simulates *real world traffic*. And your application needs to be able
> to meet
> *peak-load* at any given time. So if you expect 100 simultaneous requests, your application must be able to handle those requests without falling over. I can tell you that if you have a fairly well-written application, running on Tomcat, with a single connection in the database connection pool, and if your application can respond to requests in 1 second, and you have a 60 second wait-for-connection configuration on that pool, then your application can handle a burst of traffic up to 60 simultaneous requests without rejecting a single one. Once the 61st request is made (on top of the other 60 simultaneous requests), one of them is going to throw an error. But the application will not crash.
> Tomcat will not crash. The JVM will not crash. A single error for a
> single request will be returned to a single client. All 60 others will
> get the expected response. If you crank that up to 100 simultaneous
> requests, over and over again, 60% of them will return successfully
> and the other 40% will get errors. Which is exactly what you want. If
> your database (which is the real bottleneck, here) can really only
> take
> (e.g.) 60 simultaneous requests, then don't configure your application to give it 100 or 1000. It's better to return errors to some clients than to slowly grind everything to a halt. If your database starts thrashing, then you have nothing.
>
> The "in series" questions are easy to answer with curl, and hopefully the answers are "I can make a large number of requests in series and never break the pool" regardless of the configuration.
>
> The "in parallel" questions will get down to what happens when the pool is empty, how long are your db connections being used (i.e. duration between pool-check-out and pool-return), etc., and will require that you use a tool like ab or JMeter. ab is was easier, so, again, I'd recommend it for your uses.
>
> ab gives you great tabular data when it terminates, and will answer basically all the questions above if you run it with various options.
>
> Make sure to keep an eye on the application server's log files. For Tomcat, that means catalina.out plus any application-log file you may have configured in your application. You are looking for any errors and especially stack-traces. For the "simple tests" (like you at the browser or trying 100 requests back-to-back) you should see no errors.
>
> But you should start seeing errors at some point. And the server
> (Glassfish, or Tomcat) should *not* crash. Both the JVM and the server
> should stay running, and so should your application. Your application
> and configuration *do* have a breaking point: that's the point of a
> load-test: to understand what that breaking point actually is. But you shouldn't be able to take-down the application server or the JVM.
>
> Hope that helps,
> -chris
>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__httpd.apache.org_
> docs_2.4_programs_ab.html&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_C
> dpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHsc
> rNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=JCzN9UqN9UNmQk
> eTGL_eK59RndvTL3wnS3hkMKeqR8s&e= [2]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__jmeter.apache.org
> _&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopg
> QUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5
> _E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=AzXpplYNVaVb3NtWqdjjZqsfT36_PTaOGOe6-C
> pbpBo&e=
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Daniel,
On 8/13/25 8:59 PM, Daniel Schwartz wrote:
> Chris,
>
> You have given me a lot to think about.
>
> Re your comment: "Getting ApacheBench is different depending upon your development environment. If you let me know your OS, etc. I can point you in the right direction."
>
> I found the following via Google: https://httpd.apache.org/docs/2.4/programs/ab.html
> This indicates that it comes as a part of the Apache HTTP server and is useful only for this. Is there a version that works with Glassfish? Is there any documentation?
ab is a utility that you can run against any web server, including both
Glassfish and Tomcat. It *does* come with Apache httpd, but you can get
it separately and don't have to install the web server to use it.
> I'm running on Windows on AWS.
Apache Lounge [1] has binary versions of Apache httpd which include the
utility. I didn't see any option to just get ab.exe from there, but you
can download the ZIP package for Apache httpd and just take what you need.
ChatGPT tells me that you will need these files from the ZIP archive:
ab.exe
Required DLLs (usually):
libhttpd.dll
libapr-1.dll
libaprutil-1.dll
pcre.dll or pcre2-*.dll (depending on version)
ssleay32.dll, libeay32.dll, or OpenSSL DLLs (if SSL support is needed)
Just extract all those files into the same directory and run "ab" from
the command line.
It's a CLI tool, so you'll do a lot of typing. I would refer to the
documentation[2] to see what all the options are and what they mean.
I would start with something simple like this:
C:> ab -n 10 https://example.com/yourapp/page
This will make 10 requests and give you some statistics. Then check your
Glassfish pool counters.
If you get a weird error like "apr_socket_connect(): Invalid argument
(22)" or something, try using "127.0.0.1" instead of "localhost".
-chris
[1] https://apachelounge.com/downloads
[2] (https://apachelounge.com/downloads)
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Wednesday, August 13, 2025 2:49 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> Dan,
>
> On 8/12/25 11:33 PM, Daniel Schwartz wrote:
>> -----Original Message-----
>> From: Robert Turner <rt...@e-djuster.ca.INVALID>
>> Sent: Tuesday, August 12, 2025 11:09 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>>
> > [snip]>
>> 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?
>
> I suspect what Robert means by "annotate your code with diagnostics as needed" just means "put something in your code to record additional information. For example, logging the request URI, number of db connections obtained, the amount of time each connection took to obtain (~13ms ain't bad, but it's not exactly lightning-fast, either), and *the amount of time you spend doing your queries before the connections are returned to the pool* which seems to be something worth knowing.
>
> As for "what sort of test", I would recommend setting up a load-test in a development environment like your own workstation. Get your application running locally with the smallest pool you can muster (8 connections? Weird that there is a minimum number of connections in this pool... I'm not impressed). Make a few requests manually to ensure that the application is working "normally". Then, unleash a load test on the application.
>
> There are a number of ways to do this.
>
> First, you can mash RELOAD in your web browser and see what happens.
> That's usually not very helpful and doesn't give you much useful data.
>
> Another simple load-test is to use curl from the command line like this:
>
> $ while true ; do curl https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_your_application_page&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=di3ilaaf964xSIwNBTXtkVqVtJr5iPLPVNWhYYVb9Xw&e= > /dev/null; done
>
> That will pound your application harder than you probably can through your web browser. Pretty CTRL-C to stop the madness.
>
> When you are ready for proper load-testing, consider a simple tool like ab [1]. Getting ApacheBench is different depending upon your development environment. If you let me know your OS, etc. I can point you in the right direction.
>
> When you are ready to go down a very deep rabbit hole, you can use JMeter[2] but I suspect you will be able to learn a lot using both curl and ab, with ab being the much better choice.
>
> I'm hoping you are able to get some questions answered about your application like:
>
> 1. If I configure the pool with 8 connections, how many requests (in
> series) are required to get the pool to break?
>
> 2. If I configure the pool with 8 connections, how many requests (in
> parallel) are required to get the pool to break?
>
> 3. If I configure the pool with 100 connections, how many requests (in
> series) are required to get the pool to break?
>
> 4. If I configure the pool with 100 connections, how many requests (in parallel are required to get the pool to break?
>
> 5. What's the average response-time for a large number of serial requests? Hopefully, it's "fast". For most users, a second of latency is about when people start getting bored waiting for your site and consider switching to a competitor. Most users are also willing to wait a lot longer for some specific things. But loading your home page isn't one of them. "Generate a complex report for me?" Sure, they'll wait. But "click on the item to get details" is not something you want to make people wait for.
>
> 6. What's the average response-time for a large number of parallel requests, mixed-in with serial requests at the same time. This simulates *real world traffic*. And your application needs to be able to meet
> *peak-load* at any given time. So if you expect 100 simultaneous requests, your application must be able to handle those requests without falling over. I can tell you that if you have a fairly well-written application, running on Tomcat, with a single connection in the database connection pool, and if your application can respond to requests in 1 second, and you have a 60 second wait-for-connection configuration on that pool, then your application can handle a burst of traffic up to 60 simultaneous requests without rejecting a single one. Once the 61st request is made (on top of the other 60 simultaneous requests), one of them is going to throw an error. But the application will not crash.
> Tomcat will not crash. The JVM will not crash. A single error for a single request will be returned to a single client. All 60 others will get the expected response. If you crank that up to 100 simultaneous requests, over and over again, 60% of them will return successfully and the other 40% will get errors. Which is exactly what you want. If your database (which is the real bottleneck, here) can really only take
> (e.g.) 60 simultaneous requests, then don't configure your application to give it 100 or 1000. It's better to return errors to some clients than to slowly grind everything to a halt. If your database starts thrashing, then you have nothing.
>
> The "in series" questions are easy to answer with curl, and hopefully the answers are "I can make a large number of requests in series and never break the pool" regardless of the configuration.
>
> The "in parallel" questions will get down to what happens when the pool is empty, how long are your db connections being used (i.e. duration between pool-check-out and pool-return), etc., and will require that you use a tool like ab or JMeter. ab is was easier, so, again, I'd recommend it for your uses.
>
> ab gives you great tabular data when it terminates, and will answer basically all the questions above if you run it with various options.
>
> Make sure to keep an eye on the application server's log files. For Tomcat, that means catalina.out plus any application-log file you may have configured in your application. You are looking for any errors and especially stack-traces. For the "simple tests" (like you at the browser or trying 100 requests back-to-back) you should see no errors.
>
> But you should start seeing errors at some point. And the server (Glassfish, or Tomcat) should *not* crash. Both the JVM and the server should stay running, and so should your application. Your application and configuration *do* have a breaking point: that's the point of a
> load-test: to understand what that breaking point actually is. But you shouldn't be able to take-down the application server or the JVM.
>
> Hope that helps,
> -chris
>
> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__httpd.apache.org_docs_2.4_programs_ab.html&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=JCzN9UqN9UNmQkeTGL_eK59RndvTL3wnS3hkMKeqR8s&e=
> [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__jmeter.apache.org_&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=AzXpplYNVaVb3NtWqdjjZqsfT36_PTaOGOe6-CpbpBo&e=
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
Thanks for the detailed reply. You give numerous things to consider. I'll look into them as my time permits.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Wednesday, August 13, 2025 2:49 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
Dan,
On 8/12/25 11:33 PM, Daniel Schwartz wrote:
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Tuesday, August 12, 2025 11:09 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> [snip]>
> 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?
I suspect what Robert means by "annotate your code with diagnostics as needed" just means "put something in your code to record additional information. For example, logging the request URI, number of db connections obtained, the amount of time each connection took to obtain (~13ms ain't bad, but it's not exactly lightning-fast, either), and *the amount of time you spend doing your queries before the connections are returned to the pool* which seems to be something worth knowing.
As for "what sort of test", I would recommend setting up a load-test in a development environment like your own workstation. Get your application running locally with the smallest pool you can muster (8 connections? Weird that there is a minimum number of connections in this pool... I'm not impressed). Make a few requests manually to ensure that the application is working "normally". Then, unleash a load test on the application.
There are a number of ways to do this.
First, you can mash RELOAD in your web browser and see what happens.
That's usually not very helpful and doesn't give you much useful data.
Another simple load-test is to use curl from the command line like this:
$ while true ; do curl https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_your_application_page&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=di3ilaaf964xSIwNBTXtkVqVtJr5iPLPVNWhYYVb9Xw&e= > /dev/null; done
That will pound your application harder than you probably can through your web browser. Pretty CTRL-C to stop the madness.
When you are ready for proper load-testing, consider a simple tool like ab [1]. Getting ApacheBench is different depending upon your development environment. If you let me know your OS, etc. I can point you in the right direction.
When you are ready to go down a very deep rabbit hole, you can use JMeter[2] but I suspect you will be able to learn a lot using both curl and ab, with ab being the much better choice.
I'm hoping you are able to get some questions answered about your application like:
1. If I configure the pool with 8 connections, how many requests (in
series) are required to get the pool to break?
2. If I configure the pool with 8 connections, how many requests (in
parallel) are required to get the pool to break?
3. If I configure the pool with 100 connections, how many requests (in
series) are required to get the pool to break?
4. If I configure the pool with 100 connections, how many requests (in parallel are required to get the pool to break?
5. What's the average response-time for a large number of serial requests? Hopefully, it's "fast". For most users, a second of latency is about when people start getting bored waiting for your site and consider switching to a competitor. Most users are also willing to wait a lot longer for some specific things. But loading your home page isn't one of them. "Generate a complex report for me?" Sure, they'll wait. But "click on the item to get details" is not something you want to make people wait for.
6. What's the average response-time for a large number of parallel requests, mixed-in with serial requests at the same time. This simulates *real world traffic*. And your application needs to be able to meet
*peak-load* at any given time. So if you expect 100 simultaneous requests, your application must be able to handle those requests without falling over. I can tell you that if you have a fairly well-written application, running on Tomcat, with a single connection in the database connection pool, and if your application can respond to requests in 1 second, and you have a 60 second wait-for-connection configuration on that pool, then your application can handle a burst of traffic up to 60 simultaneous requests without rejecting a single one. Once the 61st request is made (on top of the other 60 simultaneous requests), one of them is going to throw an error. But the application will not crash.
Tomcat will not crash. The JVM will not crash. A single error for a single request will be returned to a single client. All 60 others will get the expected response. If you crank that up to 100 simultaneous requests, over and over again, 60% of them will return successfully and the other 40% will get errors. Which is exactly what you want. If your database (which is the real bottleneck, here) can really only take
(e.g.) 60 simultaneous requests, then don't configure your application to give it 100 or 1000. It's better to return errors to some clients than to slowly grind everything to a halt. If your database starts thrashing, then you have nothing.
The "in series" questions are easy to answer with curl, and hopefully the answers are "I can make a large number of requests in series and never break the pool" regardless of the configuration.
The "in parallel" questions will get down to what happens when the pool is empty, how long are your db connections being used (i.e. duration between pool-check-out and pool-return), etc., and will require that you use a tool like ab or JMeter. ab is was easier, so, again, I'd recommend it for your uses.
ab gives you great tabular data when it terminates, and will answer basically all the questions above if you run it with various options.
Make sure to keep an eye on the application server's log files. For Tomcat, that means catalina.out plus any application-log file you may have configured in your application. You are looking for any errors and especially stack-traces. For the "simple tests" (like you at the browser or trying 100 requests back-to-back) you should see no errors.
But you should start seeing errors at some point. And the server (Glassfish, or Tomcat) should *not* crash. Both the JVM and the server should stay running, and so should your application. Your application and configuration *do* have a breaking point: that's the point of a
load-test: to understand what that breaking point actually is. But you shouldn't be able to take-down the application server or the JVM.
Hope that helps,
-chris
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__httpd.apache.org_docs_2.4_programs_ab.html&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=JCzN9UqN9UNmQkeTGL_eK59RndvTL3wnS3hkMKeqR8s&e=
[2] https://urldefense.proofpoint.com/v2/url?u=https-3A__jmeter.apache.org_&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=AzXpplYNVaVb3NtWqdjjZqsfT36_PTaOGOe6-CpbpBo&e=
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
You have given me a lot to think about.
Re your comment: "Getting ApacheBench is different depending upon your development environment. If you let me know your OS, etc. I can point you in the right direction."
I found the following via Google: https://httpd.apache.org/docs/2.4/programs/ab.html
This indicates that it comes as a part of the Apache HTTP server and is useful only for this. Is there a version that works with Glassfish? Is there any documentation?
I'm running on Windows on AWS.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Wednesday, August 13, 2025 2:49 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
Dan,
On 8/12/25 11:33 PM, Daniel Schwartz wrote:
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Tuesday, August 12, 2025 11:09 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> [snip]>
> 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?
I suspect what Robert means by "annotate your code with diagnostics as needed" just means "put something in your code to record additional information. For example, logging the request URI, number of db connections obtained, the amount of time each connection took to obtain (~13ms ain't bad, but it's not exactly lightning-fast, either), and *the amount of time you spend doing your queries before the connections are returned to the pool* which seems to be something worth knowing.
As for "what sort of test", I would recommend setting up a load-test in a development environment like your own workstation. Get your application running locally with the smallest pool you can muster (8 connections? Weird that there is a minimum number of connections in this pool... I'm not impressed). Make a few requests manually to ensure that the application is working "normally". Then, unleash a load test on the application.
There are a number of ways to do this.
First, you can mash RELOAD in your web browser and see what happens.
That's usually not very helpful and doesn't give you much useful data.
Another simple load-test is to use curl from the command line like this:
$ while true ; do curl https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_your_application_page&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=di3ilaaf964xSIwNBTXtkVqVtJr5iPLPVNWhYYVb9Xw&e= > /dev/null; done
That will pound your application harder than you probably can through your web browser. Pretty CTRL-C to stop the madness.
When you are ready for proper load-testing, consider a simple tool like ab [1]. Getting ApacheBench is different depending upon your development environment. If you let me know your OS, etc. I can point you in the right direction.
When you are ready to go down a very deep rabbit hole, you can use JMeter[2] but I suspect you will be able to learn a lot using both curl and ab, with ab being the much better choice.
I'm hoping you are able to get some questions answered about your application like:
1. If I configure the pool with 8 connections, how many requests (in
series) are required to get the pool to break?
2. If I configure the pool with 8 connections, how many requests (in
parallel) are required to get the pool to break?
3. If I configure the pool with 100 connections, how many requests (in
series) are required to get the pool to break?
4. If I configure the pool with 100 connections, how many requests (in parallel are required to get the pool to break?
5. What's the average response-time for a large number of serial requests? Hopefully, it's "fast". For most users, a second of latency is about when people start getting bored waiting for your site and consider switching to a competitor. Most users are also willing to wait a lot longer for some specific things. But loading your home page isn't one of them. "Generate a complex report for me?" Sure, they'll wait. But "click on the item to get details" is not something you want to make people wait for.
6. What's the average response-time for a large number of parallel requests, mixed-in with serial requests at the same time. This simulates *real world traffic*. And your application needs to be able to meet
*peak-load* at any given time. So if you expect 100 simultaneous requests, your application must be able to handle those requests without falling over. I can tell you that if you have a fairly well-written application, running on Tomcat, with a single connection in the database connection pool, and if your application can respond to requests in 1 second, and you have a 60 second wait-for-connection configuration on that pool, then your application can handle a burst of traffic up to 60 simultaneous requests without rejecting a single one. Once the 61st request is made (on top of the other 60 simultaneous requests), one of them is going to throw an error. But the application will not crash.
Tomcat will not crash. The JVM will not crash. A single error for a single request will be returned to a single client. All 60 others will get the expected response. If you crank that up to 100 simultaneous requests, over and over again, 60% of them will return successfully and the other 40% will get errors. Which is exactly what you want. If your database (which is the real bottleneck, here) can really only take
(e.g.) 60 simultaneous requests, then don't configure your application to give it 100 or 1000. It's better to return errors to some clients than to slowly grind everything to a halt. If your database starts thrashing, then you have nothing.
The "in series" questions are easy to answer with curl, and hopefully the answers are "I can make a large number of requests in series and never break the pool" regardless of the configuration.
The "in parallel" questions will get down to what happens when the pool is empty, how long are your db connections being used (i.e. duration between pool-check-out and pool-return), etc., and will require that you use a tool like ab or JMeter. ab is was easier, so, again, I'd recommend it for your uses.
ab gives you great tabular data when it terminates, and will answer basically all the questions above if you run it with various options.
Make sure to keep an eye on the application server's log files. For Tomcat, that means catalina.out plus any application-log file you may have configured in your application. You are looking for any errors and especially stack-traces. For the "simple tests" (like you at the browser or trying 100 requests back-to-back) you should see no errors.
But you should start seeing errors at some point. And the server (Glassfish, or Tomcat) should *not* crash. Both the JVM and the server should stay running, and so should your application. Your application and configuration *do* have a breaking point: that's the point of a
load-test: to understand what that breaking point actually is. But you shouldn't be able to take-down the application server or the JVM.
Hope that helps,
-chris
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__httpd.apache.org_docs_2.4_programs_ab.html&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=JCzN9UqN9UNmQkeTGL_eK59RndvTL3wnS3hkMKeqR8s&e=
[2] https://urldefense.proofpoint.com/v2/url?u=https-3A__jmeter.apache.org_&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=CTy2h5PJHscrNmr4jn0Y-7PvWGT5hMBTsJ5_E5Vs4YvyNG7N7W-VPGs88HyDGBUV&s=AzXpplYNVaVb3NtWqdjjZqsfT36_PTaOGOe6-CpbpBo&e=
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
On 8/12/25 11:33 PM, Daniel Schwartz wrote:
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Tuesday, August 12, 2025 11:09 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> [snip]>
> 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?
I suspect what Robert means by "annotate your code with diagnostics as
needed" just means "put something in your code to record additional
information. For example, logging the request URI, number of db
connections obtained, the amount of time each connection took to obtain
(~13ms ain't bad, but it's not exactly lightning-fast, either), and *the
amount of time you spend doing your queries before the connections are
returned to the pool* which seems to be something worth knowing.
As for "what sort of test", I would recommend setting up a load-test in
a development environment like your own workstation. Get your
application running locally with the smallest pool you can muster (8
connections? Weird that there is a minimum number of connections in this
pool... I'm not impressed). Make a few requests manually to ensure that
the application is working "normally". Then, unleash a load test on the
application.
There are a number of ways to do this.
First, you can mash RELOAD in your web browser and see what happens.
That's usually not very helpful and doesn't give you much useful data.
Another simple load-test is to use curl from the command line like this:
$ while true ; do curl http://localhost:8080/your/application/page >
/dev/null; done
That will pound your application harder than you probably can through
your web browser. Pretty CTRL-C to stop the madness.
When you are ready for proper load-testing, consider a simple tool like
ab [1]. Getting ApacheBench is different depending upon your development
environment. If you let me know your OS, etc. I can point you in the
right direction.
When you are ready to go down a very deep rabbit hole, you can use
JMeter[2] but I suspect you will be able to learn a lot using both curl
and ab, with ab being the much better choice.
I'm hoping you are able to get some questions answered about your
application like:
1. If I configure the pool with 8 connections, how many requests (in
series) are required to get the pool to break?
2. If I configure the pool with 8 connections, how many requests (in
parallel) are required to get the pool to break?
3. If I configure the pool with 100 connections, how many requests (in
series) are required to get the pool to break?
4. If I configure the pool with 100 connections, how many requests (in
parallel are required to get the pool to break?
5. What's the average response-time for a large number of serial
requests? Hopefully, it's "fast". For most users, a second of latency is
about when people start getting bored waiting for your site and consider
switching to a competitor. Most users are also willing to wait a lot
longer for some specific things. But loading your home page isn't one of
them. "Generate a complex report for me?" Sure, they'll wait. But "click
on the item to get details" is not something you want to make people
wait for.
6. What's the average response-time for a large number of parallel
requests, mixed-in with serial requests at the same time. This simulates
*real world traffic*. And your application needs to be able to meet
*peak-load* at any given time. So if you expect 100 simultaneous
requests, your application must be able to handle those requests without
falling over. I can tell you that if you have a fairly well-written
application, running on Tomcat, with a single connection in the database
connection pool, and if your application can respond to requests in 1
second, and you have a 60 second wait-for-connection configuration on
that pool, then your application can handle a burst of traffic up to 60
simultaneous requests without rejecting a single one. Once the 61st
request is made (on top of the other 60 simultaneous requests), one of
them is going to throw an error. But the application will not crash.
Tomcat will not crash. The JVM will not crash. A single error for a
single request will be returned to a single client. All 60 others will
get the expected response. If you crank that up to 100 simultaneous
requests, over and over again, 60% of them will return successfully and
the other 40% will get errors. Which is exactly what you want. If your
database (which is the real bottleneck, here) can really only take
(e.g.) 60 simultaneous requests, then don't configure your application
to give it 100 or 1000. It's better to return errors to some clients
than to slowly grind everything to a halt. If your database starts
thrashing, then you have nothing.
The "in series" questions are easy to answer with curl, and hopefully
the answers are "I can make a large number of requests in series and
never break the pool" regardless of the configuration.
The "in parallel" questions will get down to what happens when the pool
is empty, how long are your db connections being used (i.e. duration
between pool-check-out and pool-return), etc., and will require that you
use a tool like ab or JMeter. ab is was easier, so, again, I'd recommend
it for your uses.
ab gives you great tabular data when it terminates, and will answer
basically all the questions above if you run it with various options.
Make sure to keep an eye on the application server's log files. For
Tomcat, that means catalina.out plus any application-log file you may
have configured in your application. You are looking for any errors and
especially stack-traces. For the "simple tests" (like you at the browser
or trying 100 requests back-to-back) you should see no errors.
But you should start seeing errors at some point. And the server
(Glassfish, or Tomcat) should *not* crash. Both the JVM and the server
should stay running, and so should your application. Your application
and configuration *do* have a breaking point: that's the point of a
load-test: to understand what that breaking point actually is. But you
shouldn't be able to take-down the application server or the JVM.
Hope that helps,
-chris
[1] https://httpd.apache.org/docs/2.4/programs/ab.html
[2] https://jmeter.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Robert,
See my replies.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Tuesday, August 12, 2025 11:09 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
Dan,
On Tue, Aug 12, 2025 at 10:38 PM Daniel Schwartz <da...@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: 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 <rt...@e-djuster.ca.INVALID>
> > Sent: Tuesday, August 12, 2025 1:57 PM
> > To: Tomcat Users List <us...@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
> > <da...@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Dan,
On Tue, Aug 12, 2025 at 10:38 PM Daniel Schwartz <da...@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 <rt...@e-djuster.ca.INVALID>
> > Sent: Tuesday, August 12, 2025 1:57 PM
> > To: Tomcat Users List <us...@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
> > <da...@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Robert,
See my replies.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Tuesday, August 12, 2025 5:06 PM
To: Tomcat Users List <us...@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 <da...@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 <rt...@e-djuster.ca.INVALID>
> Sent: Tuesday, August 12, 2025 1:57 PM
> To: Tomcat Users List <us...@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
> <da...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Dan,
On Tue, Aug 12, 2025 at 4:43 PM Daniel Schwartz <da...@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.
>
> 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.
>
>
> Dan
>
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Tuesday, August 12, 2025 1:57 PM
> To: Tomcat Users List <us...@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 <da...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
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?
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.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Tuesday, August 12, 2025 1:57 PM
To: Tomcat Users List <us...@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 <da...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
inline...
On Tue, Aug 12, 2025 at 1:46 PM Daniel Schwartz <da...@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.
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
More replied labeled DGS below.
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Tuesday, August 12, 2025 11:19 AM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
Daniel,
On 8/11/25 9:38 PM, Daniel Schwartz wrote:
> Chris,
>
> Again, see my replies marked DSG.
>
> Dan
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Monday, August 11, 2025 3:21 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> Daniel,
>
> On 8/5/25 3:05 PM, Daniel Schwartz wrote:
>> I just replied to Rob Sargent regarding this. Did you see that reply?
>>
> > Maybe I’m not using Glassfish correctly, but if I set the maximum>
> pool size to 1, the system almost immediately outputs an error
>> message saying that it is unable to allocate any more connections and
>> crashes.
> I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse?
>
> DGS: By "crashes" I mean that the program terminates, usually just after printing out a stack trace.
O_O
Like... the JVM completely exits and you have to re-start Tomcat? That sounds ... suspicious. I don't think I've ever taken down Tomcat in the
20+ years I've been using it. Application in an unusable state? Sure.
But exiting the JVM usually requires a JVM bug or tcnative crash.
DGS: I'm a Java programmer. This is normal behavior. If an exception is thrown and there is no provision for catching it, the JRE outputs a stack trace and terminates the program. However, this has never happened in my program. The program itself doesn't crash, only Glassfish does when it can't create any more connections.
>> That’s why I have set a large maximum pool size.
>
> I think you are fixing the symptom and not the problem. Even with a pool size of 1, your server should not crash. The worst thing that should happen is a request fails because a connection could not be immediately obtained from the pool.
>
> Most pools will wait some amount of time for a connection, and then time-out and the request fails. I suppose it's possible to configure a pool to require a connection to be immediately available, but that would be an unusual configuration to use IMHO.
>
> DGS: According to the people at Onmifish, if you set the maximum pool size to 1, you can have only one connection at a time.
This is exactly the intent of my recommendation.
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.
> So, if there is a request for a second connection, you get that message saying that no more connections can be created, and the system crashes (stops running). The behavior that you describe makes sense (sounds like how things should work), but that evidently isn't true about Glassfish.
Maybe Glassfish's default configuration is to crap itself if you run out of connections (which is *insane* IMHO). There must be a way to configure that connection pool to "wait up to 5 seconds for a connection, then throw an exception".
DGS: I agree with "insane". I would never design a pooling system to work like this, but it evidently is what Glassfish does.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Daniel,
On 8/11/25 9:38 PM, Daniel Schwartz wrote:
> Chris,
>
> Again, see my replies marked DSG.
>
> Dan
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Monday, August 11, 2025 3:21 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> Daniel,
>
> On 8/5/25 3:05 PM, Daniel Schwartz wrote:
>> I just replied to Rob Sargent regarding this. Did you see that reply?
>>
> > Maybe I’m not using Glassfish correctly, but if I set the maximum> pool size to 1, the system almost immediately outputs an error
>> message saying that it is unable to allocate any more connections and
>> crashes.
> I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse?
>
> DGS: By "crashes" I mean that the program terminates, usually just after printing out a stack trace.
O_O
Like... the JVM completely exits and you have to re-start Tomcat? That
sounds ... suspicious. I don't think I've ever taken down Tomcat in the
20+ years I've been using it. Application in an unusable state? Sure.
But exiting the JVM usually requires a JVM bug or tcnative crash.
>> That’s why I have set a large maximum pool size.
>
> I think you are fixing the symptom and not the problem. Even with a pool size of 1, your server should not crash. The worst thing that should happen is a request fails because a connection could not be immediately obtained from the pool.
>
> Most pools will wait some amount of time for a connection, and then time-out and the request fails. I suppose it's possible to configure a pool to require a connection to be immediately available, but that would be an unusual configuration to use IMHO.
>
> DGS: According to the people at Onmifish, if you set the maximum pool size to 1, you can have only one connection at a time.
This is exactly the intent of my recommendation.
> So, if there is a request for a second connection, you get that message saying that no more connections can be created, and the system crashes (stops running). The behavior that you describe makes sense (sounds like how things should work), but that evidently isn't true about Glassfish.
Maybe Glassfish's default configuration is to crap itself if you run out
of connections (which is *insane* IMHO). There must be a way to
configure that connection pool to "wait up to 5 seconds for a
connection, then throw an exception".
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
Again, see my replies marked DSG.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, August 11, 2025 3:21 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
Daniel,
On 8/5/25 3:05 PM, Daniel Schwartz wrote:
> I just replied to Rob Sargent regarding this. Did you see that reply?
>
> Maybe I’m not using Glassfish correctly, but if I set the maximum> pool size to 1, the system almost immediately outputs an error
> message saying that it is unable to allocate any more connections and
> crashes.
I'm interested in what you mean by "crashes". To me, that usually means that the process stops at the very least. Do you mean that the request fails, or something much worse?
DGS: By "crashes" I mean that the program terminates, usually just after printing out a stack trace.
> That’s why I have set a large maximum pool size.
I think you are fixing the symptom and not the problem. Even with a pool size of 1, your server should not crash. The worst thing that should happen is a request fails because a connection could not be immediately obtained from the pool.
Most pools will wait some amount of time for a connection, and then time-out and the request fails. I suppose it's possible to configure a pool to require a connection to be immediately available, but that would be an unusual configuration to use IMHO.
DGS: According to the people at Onmifish, if you set the maximum pool size to 1, you can have only one connection at a time. So, if there is a request for a second connection, you get that message saying that no more connections can be created, and the system crashes (stops running). The behavior that you describe makes sense (sounds like how things should work), but that evidently isn't true about Glassfish.
-chris
> From: Niranjan Rao <nr...@paymentus.com>
> Sent: Tuesday, August 5, 2025 12:54 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> On 8/5/25 09:43, Daniel Schwartz wrote: > Well, I guess that this is a
> top post. But this message is getting > longer with all the replies. I
> don’t think it is a memory leak. I’m > fairly sure that I’m closing
> every connection immediately NkdkJdXPPEBannerStart Be Careful With
> This Message From (Niranjan Rao
> <nr...@paymentus.com>)<https://godaddy1.cloud-protect.net/email-details
> /?k=k1&payload=53616c7465645f5f01479cd1d42494181d4c16588b94df4c820e427
> 2265487dd9f78a6c5058acdafc93d62897abd159718ec313c22d09277dbf2fbb536c02
> 6e3f6aee770447b1d4f78dfc54afce74a56553ab348aa1f4cf565bf83964f1f0912334
> 8c4e595d8d9df00b653e7157eedbd6450c9ea7be6c8687659e563a0caaeb8ee75dff4f
> a7e4a88d05034bb22037dd4bbe58bf99e736fbdae6b66c1d082b0b30de80c55b5719ab
> c475fbe778560908e4d4a57fae4f1567f335f620ae681895613f5e4f54efacefe16c1e
> cf319bdaec9f510253a8e47129cd215e8d8cd3c3bf89c2456aab6324c75736d9af5f15
> 50a42> Learn
> More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53
> 616c7465645f5f01479cd1d42494181d4c16588b94df4c820e4272265487dd9f78a6c5
> 058acdafc93d62897abd159718ec313c22d09277dbf2fbb536c026e3f6aee770447b1d
> 4f78dfc54afce74a56553ab348aa1f4cf565bf83964f1f09123348c4e595d8d9df00b6
> 53e7157eedbd6450c9ea7be6c8687659e563a0caaeb8ee75dff4fa7e4a88d05034bb22
> 037dd4bbe58bf99e736fbdae6b66c1d082b0b30de80c55b5719abc475fbe778560908e
> 4d4a57fae4f1567f335f620ae681895613f5e4f54efacefe16c1ecf319bdaec9f51025
> 3a8e47129cd215e8d8cd3c3bf89c2456aab6324c75736d9af5f1550a42>
> 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 8/5/25 09:43, Daniel Schwartz wrote:
>
>> Well, I guess that this is a top post. But this message is getting
>
>> longer with all the replies. I don’t think it is a memory leak. I’m
>
>> fairly sure that I’m closing every connection immediately after using
>
>> it. It seems that most of my database
>
>> ZjQcmQRYFpfptBannerStart
>
>> This Message Is From an Untrusted Sender
>
>> You have not previously corresponded with this sender.
>
>> ZjQcmQRYFpfptBannerEnd
>
>> Well, I guess that this is a top post. But this message is getting longer with all the replies.
>
>>
>
>> I don’t think it is a memory leak. I’m fairly sure that I’m closing every connection immediately after using it. It seems that most of my database queries are coming from web crawlers, and there are a few hundred accesses every day. I was getting error messages from Glassfish saying that it couldn’t allocate any more connection objects and then crashing. At that time the maximum pool size was the default, which is 32. So I believe it was just being overloaded by the web crawlers. Now that I have increased to 1000, the system has stopped crashing.
>
>>
>
>> But I have to admit that I really don’t understand how these connection pooling systems work. 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. Once a database session terminates, then that connection object becomes available for future use. 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?
>
>>
>
>> Dan Schwartz
>
>>
>
>
>
> The default is a reasonable number depending upon traffic. Is your
> site
>
> fairly busy? We manage a fairly busy site with lot database activity
> and
>
> even then we don't have to go 1000 connections which essentially might
>
> boil down to 1000 concurrent requests. Are you really getting that
> many
>
> requests simultaneously? As others have indicated there is a good
> chance
>
> you have connection and/or other resource leaks in your code. There
> are
>
> some debugging hints posted like setting max connections to 1 in your
>
> dev environment and see if it works cleanly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Daniel,
On 8/5/25 3:05 PM, Daniel Schwartz wrote:
> I just replied to Rob Sargent regarding this. Did you see that reply?
>
> Maybe I’m not using Glassfish correctly, but if I set the maximum>
pool size to 1, the system almost immediately outputs an error
> message saying that it is unable to allocate any more connections
> and crashes.
I'm interested in what you mean by "crashes". To me, that usually means
that the process stops at the very least. Do you mean that the request
fails, or something much worse?
> That’s why I have set a large maximum pool size.
I think you are fixing the symptom and not the problem. Even with a pool
size of 1, your server should not crash. The worst thing that should
happen is a request fails because a connection could not be immediately
obtained from the pool.
Most pools will wait some amount of time for a connection, and then
time-out and the request fails. I suppose it's possible to configure a
pool to require a connection to be immediately available, but that would
be an unusual configuration to use IMHO.
-chris
> From: Niranjan Rao <nr...@paymentus.com>
> Sent: Tuesday, August 5, 2025 12:54 PM
> To: users@tomcat.apache.org
> Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
>
> On 8/5/25 09:43, Daniel Schwartz wrote: > Well, I guess that this is a top post. But this message is getting > longer with all the replies. I don’t think it is a memory leak. I’m > fairly sure that I’m closing every connection immediately
> NkdkJdXPPEBannerStart
> Be Careful With This Message
> From (Niranjan Rao <nr...@paymentus.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f01479cd1d42494181d4c16588b94df4c820e4272265487dd9f78a6c5058acdafc93d62897abd159718ec313c22d09277dbf2fbb536c026e3f6aee770447b1d4f78dfc54afce74a56553ab348aa1f4cf565bf83964f1f09123348c4e595d8d9df00b653e7157eedbd6450c9ea7be6c8687659e563a0caaeb8ee75dff4fa7e4a88d05034bb22037dd4bbe58bf99e736fbdae6b66c1d082b0b30de80c55b5719abc475fbe778560908e4d4a57fae4f1567f335f620ae681895613f5e4f54efacefe16c1ecf319bdaec9f510253a8e47129cd215e8d8cd3c3bf89c2456aab6324c75736d9af5f1550a42>
> Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f01479cd1d42494181d4c16588b94df4c820e4272265487dd9f78a6c5058acdafc93d62897abd159718ec313c22d09277dbf2fbb536c026e3f6aee770447b1d4f78dfc54afce74a56553ab348aa1f4cf565bf83964f1f09123348c4e595d8d9df00b653e7157eedbd6450c9ea7be6c8687659e563a0caaeb8ee75dff4fa7e4a88d05034bb22037dd4bbe58bf99e736fbdae6b66c1d082b0b30de80c55b5719abc475fbe778560908e4d4a57fae4f1567f335f620ae681895613f5e4f54efacefe16c1ecf319bdaec9f510253a8e47129cd215e8d8cd3c3bf89c2456aab6324c75736d9af5f1550a42>
> 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 8/5/25 09:43, Daniel Schwartz wrote:
>
>> Well, I guess that this is a top post. But this message is getting
>
>> longer with all the replies. I don’t think it is a memory leak. I’m
>
>> fairly sure that I’m closing every connection immediately after using
>
>> it. It seems that most of my database
>
>> ZjQcmQRYFpfptBannerStart
>
>> This Message Is From an Untrusted Sender
>
>> You have not previously corresponded with this sender.
>
>> ZjQcmQRYFpfptBannerEnd
>
>> Well, I guess that this is a top post. But this message is getting longer with all the replies.
>
>>
>
>> I don’t think it is a memory leak. I’m fairly sure that I’m closing every connection immediately after using it. It seems that most of my database queries are coming from web crawlers, and there are a few hundred accesses every day. I was getting error messages from Glassfish saying that it couldn’t allocate any more connection objects and then crashing. At that time the maximum pool size was the default, which is 32. So I believe it was just being overloaded by the web crawlers. Now that I have increased to 1000, the system has stopped crashing.
>
>>
>
>> But I have to admit that I really don’t understand how these connection pooling systems work. 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. Once a database session terminates, then that connection object becomes available for future use. 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?
>
>>
>
>> Dan Schwartz
>
>>
>
>
>
> The default is a reasonable number depending upon traffic. Is your site
>
> fairly busy? We manage a fairly busy site with lot database activity and
>
> even then we don't have to go 1000 connections which essentially might
>
> boil down to 1000 concurrent requests. Are you really getting that many
>
> requests simultaneously? As others have indicated there is a good chance
>
> you have connection and/or other resource leaks in your code. There are
>
> some debugging hints posted like setting max connections to 1 in your
>
> dev environment and see if it works cleanly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Niranjan,
I just replied to Rob Sargent regarding this. Did you see that reply?
Maybe I’m not using Glassfish correctly, but if I set the maximum pool size to 1, the system almost immediately outputs an error message saying that it is unable to allocate any more connections and crashes. That’s why I have set a large maximum pool size.
Dan Schwartz
From: Niranjan Rao <nr...@paymentus.com>
Sent: Tuesday, August 5, 2025 12:54 PM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL EMAIL] RE: How to access a REST service
On 8/5/25 09:43, Daniel Schwartz wrote: > Well, I guess that this is a top post. But this message is getting > longer with all the replies. I don’t think it is a memory leak. I’m > fairly sure that I’m closing every connection immediately
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Niranjan Rao <nr...@paymentus.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f01479cd1d42494181d4c16588b94df4c820e4272265487dd9f78a6c5058acdafc93d62897abd159718ec313c22d09277dbf2fbb536c026e3f6aee770447b1d4f78dfc54afce74a56553ab348aa1f4cf565bf83964f1f09123348c4e595d8d9df00b653e7157eedbd6450c9ea7be6c8687659e563a0caaeb8ee75dff4fa7e4a88d05034bb22037dd4bbe58bf99e736fbdae6b66c1d082b0b30de80c55b5719abc475fbe778560908e4d4a57fae4f1567f335f620ae681895613f5e4f54efacefe16c1ecf319bdaec9f510253a8e47129cd215e8d8cd3c3bf89c2456aab6324c75736d9af5f1550a42>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f01479cd1d42494181d4c16588b94df4c820e4272265487dd9f78a6c5058acdafc93d62897abd159718ec313c22d09277dbf2fbb536c026e3f6aee770447b1d4f78dfc54afce74a56553ab348aa1f4cf565bf83964f1f09123348c4e595d8d9df00b653e7157eedbd6450c9ea7be6c8687659e563a0caaeb8ee75dff4fa7e4a88d05034bb22037dd4bbe58bf99e736fbdae6b66c1d082b0b30de80c55b5719abc475fbe778560908e4d4a57fae4f1567f335f620ae681895613f5e4f54efacefe16c1ecf319bdaec9f510253a8e47129cd215e8d8cd3c3bf89c2456aab6324c75736d9af5f1550a42>
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 8/5/25 09:43, Daniel Schwartz wrote:
> Well, I guess that this is a top post. But this message is getting
> longer with all the replies. I don’t think it is a memory leak. I’m
> fairly sure that I’m closing every connection immediately after using
> it. It seems that most of my database
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
> ZjQcmQRYFpfptBannerEnd
> Well, I guess that this is a top post. But this message is getting longer with all the replies.
>
> I don’t think it is a memory leak. I’m fairly sure that I’m closing every connection immediately after using it. It seems that most of my database queries are coming from web crawlers, and there are a few hundred accesses every day. I was getting error messages from Glassfish saying that it couldn’t allocate any more connection objects and then crashing. At that time the maximum pool size was the default, which is 32. So I believe it was just being overloaded by the web crawlers. Now that I have increased to 1000, the system has stopped crashing.
>
> But I have to admit that I really don’t understand how these connection pooling systems work. 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. Once a database session terminates, then that connection object becomes available for future use. 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?
>
> Dan Schwartz
>
The default is a reasonable number depending upon traffic. Is your site
fairly busy? We manage a fairly busy site with lot database activity and
even then we don't have to go 1000 connections which essentially might
boil down to 1000 concurrent requests. Are you really getting that many
requests simultaneously? As others have indicated there is a good chance
you have connection and/or other resource leaks in your code. There are
some debugging hints posted like setting max connections to 1 in your
dev environment and see if it works cleanly.
Re: [EXTERNAL EMAIL] RE: How to access a REST service
Posted by Niranjan Rao <nr...@paymentus.com>.
On 8/5/25 09:43, Daniel Schwartz wrote:
> Well, I guess that this is a top post. But this message is getting
> longer with all the replies. I don’t think it is a memory leak. I’m
> fairly sure that I’m closing every connection immediately after using
> it. It seems that most of my database
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
> ZjQcmQRYFpfptBannerEnd
> Well, I guess that this is a top post. But this message is getting longer with all the replies.
>
> I don’t think it is a memory leak. I’m fairly sure that I’m closing every connection immediately after using it. It seems that most of my database queries are coming from web crawlers, and there are a few hundred accesses every day. I was getting error messages from Glassfish saying that it couldn’t allocate any more connection objects and then crashing. At that time the maximum pool size was the default, which is 32. So I believe it was just being overloaded by the web crawlers. Now that I have increased to 1000, the system has stopped crashing.
>
> But I have to admit that I really don’t understand how these connection pooling systems work. 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. Once a database session terminates, then that connection object becomes available for future use. 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?
>
> Dan Schwartz
>
The default is a reasonable number depending upon traffic. Is your site
fairly busy? We manage a fairly busy site with lot database activity and
even then we don't have to go 1000 connections which essentially might
boil down to 1000 concurrent requests. Are you really getting that many
requests simultaneously? As others have indicated there is a good chance
you have connection and/or other resource leaks in your code. There are
some debugging hints posted like setting max connections to 1 in your
dev environment and see if it works cleanly.
Re: How to access a REST service
Posted by Clint Carrion <cl...@protonmail.com.INVALID>.
> 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 think that the search bots are just exposing the existing problem, they're not the cause of it. If you blocked them you would just be masking the underlying issue for now and when you receive an increase in traffic the problem will re-occur.
Looking at the logs that you shared, there's only 1,026 requests (bots or otherwise) over about two days to /calendar (which I presume triggers the DB request) .. this is a very small amount.
I'd suggest revisiting your code. Other than the connection handling, some other areas to look into would be: are DB requests only being triggered when necessary, how long do queries take - are there excessive joins and column/row returns.
Clint
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
Please see my reply marked DSG below.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, August 11, 2025 3:25 PM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
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.
DGS: As noted in my previous email, Glassfish had a monitoring system, and it reports that there are no leaks.
-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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
See my reply marked DGS below.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, August 11, 2025 3:32 PM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Dan,
On 8/7/25 10:29 PM, Daniel Schwartz wrote:
> Robert, Chris, and others who have responded to my queries,
>
> Everyone is convinced that I have problem with my code. Here are what I consider to be the relevant code fragments. I've also indicated where I consider it to be possible that there might be a memory leak, but I'm not sure about this.
>
> The main file is HolidaysRESTJSONResource.java. Following is the beginning fragment, which opens a database connection, executes a query to retrieve a list of countries, and closes the connection. The constructor for this class creates a DataSource by means of a DataSourceSingleton, also copied below. This DataSource object is used in HolidaysRESTJSONResource.java to create a Connection object, which is then passed to a method GetCountryList.doIt(), which creates a prepared statement, this being a DB query to retrieve a list of countries, and returns this list. I haven't copied this file here, but I did write in some print statements where the prepared statement is created and then closed. You will see these in the output log copied below.
>
> I also wrote in some print statements immediately after the Connection object is created and immediately after the Connection is closed. I believe that this is working as it should, i.e., at this point the Glassfish pooling system should mark this Connection object as no longer in use and therefore available for future use. If there is a memory leak, then this is the most likely place. In any case, I do execute a close operation on this Connection object and print out a statement about this. You can also see this in the output log.
>
> For completeness I also copied the TempDataStorage.java, in case you're curious about this. It simply holds the countryList so that the system doesn't need to keep retrieving it.
>
> The HolidaysRESTJSONResource.java has five method calls like the one shown here as GetCountryList.doIt(). All of them have the same code for opening and closing a connection. I also put some print statements in the method that returns the holidays list. These also appear in the log file.
>
> Upon reflection, I think that the only place where a memory leak might occur is in the place I indicated above---that closing the Connection object in the way I have done might not actually have that object be marked as no longer in use in the pool. However, not knowing enough about these pooling systems, I really don't know.
>
> What do you think?
You definitely have connection leaks in your code. For example:
> public String getJsonCountries() {
> if (TempDataStorage.countryList == null) {
> Connection connection = null;
> try {
> connection = dataSource.getConnection();
Exception occurring after here will leak a connection.
> System.out.println("countries connection has been opened");
> TempDataStorage.countryList = GetCountryList.doIt(connection);
> connection.close();
> System.out.println("countries connection has been closed");
> } catch (SQLException e) {
> System.out.println(e);
> if (connection != null) {
> try {
> connection.close();
> } catch (SQLException ex) {
> System.out.println(ex);
> }
> }
> }
> }
You should have a connection.close() in a finally{} block which is missing in this code. You also need to catch other types of exceptions:
- RuntimeException
- Error
- Anything else that your method is declared to throw
(currently nothing)
DGS: You point is well taken. I will add a finally block. However, as far as I know, no exceptions are being thrown. If a Java program throws an exception that isn't being caught, the program crashes and outputs a stack trace. This has never happened.
> StringListWrapper listWrapper = new StringListWrapper();
> listWrapper.setTheList(TempDataStorage.countryList);
> return new Gson().toJson(listWrapper);
> }
>
> ...
> ----------------------------------------------------------------------
> ---------
> DataSourceSingleton.java
> ...
> public class DataSourceSingleton {
>
> private static DataSourceSingleton instance = null;
> public DataSource dataSource = null;
>
> private DataSourceSingleton() {
> try {
> InitialContext ctx = new InitialContext();
> dataSource = (DataSource) ctx.lookup("jdbc/holidays");
> } catch (NamingException e) {
> System.out.println(e);
> }
> }
>
> public static DataSourceSingleton getInstance() {
> if (instance == null) {
> instance = new DataSourceSingleton();
> }
> return instance;
> }
> }
You probably need some "synchronized" keywords in there. If this were my code, I would do:
private static final DataSourceSingleton instance = new DataSourceSingleton();
...and then remove the predicate in getInstance, just returning that already-initialized static class member.
> ----------------------------------------------------------------------
> ----------
> server.log
>
> [2025-08-07T21:19:43.526-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983526] [levelValue: 800] [[
> countries connection has been opened]]
>
> [2025-08-07T21:19:43.528-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983528] [levelValue: 800] [[
> creating getCountries prepared statement]]
>
> [2025-08-07T21:19:43.529-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983529] [levelValue: 800] [[
> closing getCountries prepared statement]]
>
> [2025-08-07T21:19:43.529-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983529] [levelValue: 800] [[
> countries connection has been closed]]
>
> [2025-08-07T21:20:19.635-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1754616019635] [levelValue: 800] [[
> holidays connection has been opened]]
>
> [2025-08-07T21:20:19.704-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1754616019704] [levelValue: 800] [[
> holidays connection has been closed]]
Are you seeing any opens without closes?
When it "crashes", what do you get? I'm assuming an exception stack trace.
-chris
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Thursday, August 7, 2025 5:07 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> Dan,
>
> On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz
> <da...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
On 8/7/25 10:29 PM, Daniel Schwartz wrote:
> Robert, Chris, and others who have responded to my queries,
>
> Everyone is convinced that I have problem with my code. Here are what I consider to be the relevant code fragments. I've also indicated where I consider it to be possible that there might be a memory leak, but I'm not sure about this.
>
> The main file is HolidaysRESTJSONResource.java. Following is the beginning fragment, which opens a database connection, executes a query to retrieve a list of countries, and closes the connection. The constructor for this class creates a DataSource by means of a DataSourceSingleton, also copied below. This DataSource object is used in HolidaysRESTJSONResource.java to create a Connection object, which is then passed to a method GetCountryList.doIt(), which creates a prepared statement, this being a DB query to retrieve a list of countries, and returns this list. I haven't copied this file here, but I did write in some print statements where the prepared statement is created and then closed. You will see these in the output log copied below.
>
> I also wrote in some print statements immediately after the Connection object is created and immediately after the Connection is closed. I believe that this is working as it should, i.e., at this point the Glassfish pooling system should mark this Connection object as no longer in use and therefore available for future use. If there is a memory leak, then this is the most likely place. In any case, I do execute a close operation on this Connection object and print out a statement about this. You can also see this in the output log.
>
> For completeness I also copied the TempDataStorage.java, in case you're curious about this. It simply holds the countryList so that the system doesn't need to keep retrieving it.
>
> The HolidaysRESTJSONResource.java has five method calls like the one shown here as GetCountryList.doIt(). All of them have the same code for opening and closing a connection. I also put some print statements in the method that returns the holidays list. These also appear in the log file.
>
> Upon reflection, I think that the only place where a memory leak might occur is in the place I indicated above---that closing the Connection object in the way I have done might not actually have that object be marked as no longer in use in the pool. However, not knowing enough about these pooling systems, I really don't know.
>
> What do you think?
You definitely have connection leaks in your code. For example:
> public String getJsonCountries() {
> if (TempDataStorage.countryList == null) {
> Connection connection = null;
> try {
> connection = dataSource.getConnection();
Exception occurring after here will leak a connection.
> System.out.println("countries connection has been opened");
> TempDataStorage.countryList = GetCountryList.doIt(connection);
> connection.close();
> System.out.println("countries connection has been closed");
> } catch (SQLException e) {
> System.out.println(e);
> if (connection != null) {
> try {
> connection.close();
> } catch (SQLException ex) {
> System.out.println(ex);
> }
> }
> }
> }
You should have a connection.close() in a finally{} block which is
missing in this code. You also need to catch other types of exceptions:
- RuntimeException
- Error
- Anything else that your method is declared to throw
(currently nothing)
> StringListWrapper listWrapper = new StringListWrapper();
> listWrapper.setTheList(TempDataStorage.countryList);
> return new Gson().toJson(listWrapper);
> }
>
> ...
> -------------------------------------------------------------------------------
> DataSourceSingleton.java
> ...
> public class DataSourceSingleton {
>
> private static DataSourceSingleton instance = null;
> public DataSource dataSource = null;
>
> private DataSourceSingleton() {
> try {
> InitialContext ctx = new InitialContext();
> dataSource = (DataSource) ctx.lookup("jdbc/holidays");
> } catch (NamingException e) {
> System.out.println(e);
> }
> }
>
> public static DataSourceSingleton getInstance() {
> if (instance == null) {
> instance = new DataSourceSingleton();
> }
> return instance;
> }
> }
You probably need some "synchronized" keywords in there. If this were my
code, I would do:
private static final DataSourceSingleton instance = new
DataSourceSingleton();
...and then remove the predicate in getInstance, just returning that
already-initialized static class member.
> --------------------------------------------------------------------------------
> server.log
>
> [2025-08-07T21:19:43.526-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983526] [levelValue: 800] [[
> countries connection has been opened]]
>
> [2025-08-07T21:19:43.528-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983528] [levelValue: 800] [[
> creating getCountries prepared statement]]
>
> [2025-08-07T21:19:43.529-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983529] [levelValue: 800] [[
> closing getCountries prepared statement]]
>
> [2025-08-07T21:19:43.529-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983529] [levelValue: 800] [[
> countries connection has been closed]]
>
> [2025-08-07T21:20:19.635-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1754616019635] [levelValue: 800] [[
> holidays connection has been opened]]
>
> [2025-08-07T21:20:19.704-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1754616019704] [levelValue: 800] [[
> holidays connection has been closed]]
Are you seeing any opens without closes?
When it "crashes", what do you get? I'm assuming an exception stack trace.
-chris
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Thursday, August 7, 2025 5:07 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> Dan,
>
> On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz <da...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Robert, Chris, and others who have responded to my queries,
Everyone is convinced that I have problem with my code. Here are what I consider to be the relevant code fragments. I've also indicated where I consider it to be possible that there might be a memory leak, but I'm not sure about this.
The main file is HolidaysRESTJSONResource.java. Following is the beginning fragment, which opens a database connection, executes a query to retrieve a list of countries, and closes the connection. The constructor for this class creates a DataSource by means of a DataSourceSingleton, also copied below. This DataSource object is used in HolidaysRESTJSONResource.java to create a Connection object, which is then passed to a method GetCountryList.doIt(), which creates a prepared statement, this being a DB query to retrieve a list of countries, and returns this list. I haven't copied this file here, but I did write in some print statements where the prepared statement is created and then closed. You will see these in the output log copied below.
I also wrote in some print statements immediately after the Connection object is created and immediately after the Connection is closed. I believe that this is working as it should, i.e., at this point the Glassfish pooling system should mark this Connection object as no longer in use and therefore available for future use. If there is a memory leak, then this is the most likely place. In any case, I do execute a close operation on this Connection object and print out a statement about this. You can also see this in the output log.
For completeness I also copied the TempDataStorage.java, in case you're curious about this. It simply holds the countryList so that the system doesn't need to keep retrieving it.
The HolidaysRESTJSONResource.java has five method calls like the one shown here as GetCountryList.doIt(). All of them have the same code for opening and closing a connection. I also put some print statements in the method that returns the holidays list. These also appear in the log file.
Upon reflection, I think that the only place where a memory leak might occur is in the place I indicated above---that closing the Connection object in the way I have done might not actually have that object be marked as no longer in use in the pool. However, not knowing enough about these pooling systems, I really don't know.
What do you think?
Dan Schwartz
-----------------------------------------------------------------
HolidaysRESTJSONResource.java
...
@Path("holidaysandevents")
public class HolidaysRESTJSONResource {
@Context
private UriInfo context;
DataSource dataSource;
public HolidaysRESTJSONResource() {
dataSource = DataSourceSingleton.getInstance().dataSource;
}
@GET
@Path("/countries")
@Produces(MediaType.APPLICATION_JSON)
public String getJsonCountries() {
if (TempDataStorage.countryList == null) {
Connection connection = null;
try {
connection = dataSource.getConnection();
System.out.println("countries connection has been opened");
TempDataStorage.countryList = GetCountryList.doIt(connection);
connection.close();
System.out.println("countries connection has been closed");
} catch (SQLException e) {
System.out.println(e);
if (connection != null) {
try {
connection.close();
} catch (SQLException ex) {
System.out.println(ex);
}
}
}
}
StringListWrapper listWrapper = new StringListWrapper();
listWrapper.setTheList(TempDataStorage.countryList);
return new Gson().toJson(listWrapper);
}
...
-------------------------------------------------------------------------------
DataSourceSingleton.java
...
public class DataSourceSingleton {
private static DataSourceSingleton instance = null;
public DataSource dataSource = null;
private DataSourceSingleton() {
try {
InitialContext ctx = new InitialContext();
dataSource = (DataSource) ctx.lookup("jdbc/holidays");
} catch (NamingException e) {
System.out.println(e);
}
}
public static DataSourceSingleton getInstance() {
if (instance == null) {
instance = new DataSourceSingleton();
}
return instance;
}
}
-------------------------------------------------------------------------------
TempDataStorage.java
...
/**
*
* Temporary storage for countries data is to persist across all client accesses, i.e., each
* deployment of HolidaysRESTJSON. This eliminates unnecessary repetitive database accesses.
* If the relevant database tables are changed, then HolidaysRESTJSON must be redeployed
* to update these data items.
*/
public class TempDataStorage {
static ArrayList<String> countryList = null;
}
--------------------------------------------------------------------------------
server.log
[2025-08-07T21:19:43.526-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983526] [levelValue: 800] [[
countries connection has been opened]]
[2025-08-07T21:19:43.528-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983528] [levelValue: 800] [[
creating getCountries prepared statement]]
[2025-08-07T21:19:43.529-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983529] [levelValue: 800] [[
closing getCountries prepared statement]]
[2025-08-07T21:19:43.529-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=39 _ThreadName=Thread-8] [timeMillis: 1754615983529] [levelValue: 800] [[
countries connection has been closed]]
[2025-08-07T21:20:19.635-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1754616019635] [levelValue: 800] [[
holidays connection has been opened]]
[2025-08-07T21:20:19.704-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=36 _ThreadName=Thread-8] [timeMillis: 1754616019704] [levelValue: 800] [[
holidays connection has been closed]]
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Thursday, August 7, 2025 5:07 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
Dan,
On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz <da...@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..
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
From: Chuck Caldarale <n8...@gmail.com>
Sent: Thursday, August 7, 2025 11:52 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
> On 2025 Aug 7, at 21:43, Daniel Schwartz <da...@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 <n8...@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 <da...@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 <rt...@e-djuster.ca.INVALID>>
> Sent: Thursday, August 7, 2025 5:07 PM
> To: Tomcat Users List <us...@tomcat.apache.org>>
> Subject: Re: How to access a REST service
>
> Dan,
>
> On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz <da...@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-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
From: Rob Sargent <rs...@xmission.com>
Sent: Friday, August 8, 2025 2:38 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
> On Aug 8, 2025, at 10:23 AM, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > Hello Robert, > > From your and other people's replies, I'm learning that tracking down memory leaks can be quite daunting and possibly
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f45a39dd08e08288d170a1f429f310dcfc4c2682a0d5110f09626dd9f138e733ba0fa5243d9ee7dd687d549d0a6f29445fc21d4caf9da1e059ec09958dee9e37d7813463d01d3848dceb4ef4ec5293fb84050ce3cd2276b8bea19b4161d14dd83842327d0de3e096dbe18d41d87c4be5f369121ed17c58cd13506310466549992f7e6ec278a725774a1a15c0620add0aa3b640d9c525f8e4e45d3a21d533673a2570492beed254d67e15dcb77a6c36890130ddfd658990f8a258e01a1bc4b5ee7c9384bc31e32a6d8d5354f9e3cca8d5d137fb6f053a12592d66b61af21268785a1f165f20cdff25e>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f45a39dd08e08288d170a1f429f310dcfc4c2682a0d5110f09626dd9f138e733ba0fa5243d9ee7dd687d549d0a6f29445fc21d4caf9da1e059ec09958dee9e37d7813463d01d3848dceb4ef4ec5293fb84050ce3cd2276b8bea19b4161d14dd83842327d0de3e096dbe18d41d87c4be5f369121ed17c58cd13506310466549992f7e6ec278a725774a1a15c0620add0aa3b640d9c525f8e4e45d3a21d533673a2570492beed254d67e15dcb77a6c36890130ddfd658990f8a258e01a1bc4b5ee7c9384bc31e32a6d8d5354f9e3cca8d5d137fb6f053a12592d66b61af21268785a1f165f20cdff25e>
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 Aug 8, 2025, at 10:23 AM, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Hello Robert,
>
> From your and other people's replies, I'm learning that tracking down memory leaks can be quite daunting and possibly beyond me.
>
> I'm aware of the try-with-resources instruction and will look into it. I wrote this code before learning about this.
>
> In any case, I will follow your advice and add a "finally" block to the "try" statement. I'm currently closing the connection in case an SQL exception is thrown, but I hadn't considered the possibility of other kinds of exceptions. I suppose that there could be such exceptions, but I'm mystified regarding what those might be.
>
> However, there has been a new development. After "fishing" around in the Glassfish administration system, I found that there is a way to monitor the JDBC connection pool and get all sorts of information. Based on this, I really don't think that there is any memory leak at all.
>
> When running a simple query on my website, I see that NumConnAcquired increases by three (which is what I would expect), and immediately thereafter NumConnReleased increases by the same number. So every connection that is being acquired is also being released. I think that, if there were a memory leak, the number of connections acquired would be increasing at a faster pace than the number being released.
>
> Also, there is a NumConnUsed statistic that has a "High Water Mark" which is described as the "maximum number of connections that were used", and this is currently 160, which is not a lot.
I think most here agree 160 concurrently open db connections is a lot. I don’t recall if you gave the specs on your db server but that load would likely drag an average server quite a bit - most queries would be waiting for a chip.
Can the db sever logs give a hint of when that peak was or what was being done?
I was wondering about that too. I don't see any indication of when that 160 number occurred, but there is a date range of 8/4 through 8/8, so it could a tally of total connections over the past 4 days. I'm just not sure how to interpret many of the given data items, but there is one called "NumPotentialConnLeak" and the current value is "0 count", which I interpret as meaning that there currently are no leaks. I've decided to stop worrying about this for the time being. The system has been running okay for several days now.
>
> So it seems that the system is behaving normally. And I have noticed that since setting the maximum pool size to 1000, the system has not crashed for several days. Probably, 1000 is more than necessary, and you just need make sure you have more possible connections available than the anticipated future high-water mark. But this seems to be working.
>
> So maybe I'm just imagining problems that no longer exist. As long as the system keeps running, I'm fine with this.
>
> Thanks to everyone for their replies.
>
> Dan
>
> --
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
> On Aug 8, 2025, at 10:23 AM, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Hello Robert,
>
> From your and other people's replies, I'm learning that tracking down memory leaks can be quite daunting and possibly beyond me.
>
> I'm aware of the try-with-resources instruction and will look into it. I wrote this code before learning about this.
>
> In any case, I will follow your advice and add a "finally" block to the "try" statement. I'm currently closing the connection in case an SQL exception is thrown, but I hadn't considered the possibility of other kinds of exceptions. I suppose that there could be such exceptions, but I'm mystified regarding what those might be.
>
> However, there has been a new development. After "fishing" around in the Glassfish administration system, I found that there is a way to monitor the JDBC connection pool and get all sorts of information. Based on this, I really don't think that there is any memory leak at all.
>
> When running a simple query on my website, I see that NumConnAcquired increases by three (which is what I would expect), and immediately thereafter NumConnReleased increases by the same number. So every connection that is being acquired is also being released. I think that, if there were a memory leak, the number of connections acquired would be increasing at a faster pace than the number being released.
>
> Also, there is a NumConnUsed statistic that has a "High Water Mark" which is described as the "maximum number of connections that were used", and this is currently 160, which is not a lot.
I think most here agree 160 concurrently open db connections is a lot. I don’t recall if you gave the specs on your db server but that load would likely drag an average server quite a bit - most queries would be waiting for a chip.
Can the db sever logs give a hint of when that peak was or what was being done?
>
> So it seems that the system is behaving normally. And I have noticed that since setting the maximum pool size to 1000, the system has not crashed for several days. Probably, 1000 is more than necessary, and you just need make sure you have more possible connections available than the anticipated future high-water mark. But this seems to be working.
>
> So maybe I'm just imagining problems that no longer exist. As long as the system keeps running, I'm fine with this.
>
> Thanks to everyone for their replies.
>
> Dan
>
> --
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Chris,
Thanks again.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Wednesday, August 13, 2025 2:56 PM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Dan,
On 8/13/25 12:38 AM, Daniel Schwartz wrote:
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Monday, August 11, 2025 10:12 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> If one is going to make multiple requests (especially without much logic in-between), I would suggest reusing the same connection (wrapped with the relevant resource management logic). Obtaining a connection is a higher cost operation than a query request, and releasing and reacquiring it requires more synchronization overhead which can reduce parallelism for handling many requests at once.
>
> DGS: I don't currently know how to do this, but I think there is a way to identify a user "session" in the website and then only open one DB connection per session. I will look into it.
Do *NOT*, under any circumstances, do this.
If you let a user login (or not, maybe you don't require login) and take a db connection from the pool and not return it until they log-off (or some suitable timeout occurs), then your application will fall-over after 2 minutes no matter what your pool configuration is.
DGS: Thanks. I hadn't thought of this.
> Also, what you are suggesting above is that three, non-concurrent connections are obtained. I'm not sure we got this impression from previous communications. At least I thought you had three connections open at the same time for the request. Hence our greater concern.
>
> DGS: The connections are separate and non-concurrent---running in series.
This is completely fine. Robert's advice was if there is an opportunity to merge these application-data-requests into a single "get connection", "get data - plural", "return connection" workflow, you could get some benefit from it. But a single request which performs several of these, including "get connection" and "return connection" operations during its lifetime should not be a problem. It's just slightly less optimal from a performance perspective. Don't worry too much about it unless you see some low-hanging fruit.
DGS: Okay, thanks.
> Also, minimizing the time the DB connection is held and obtaining all the data as quickly as possible makes for more efficient reuse of connections in the pool when there are many requests contending for the DB connections.
> (Avoid holding your DB connections while reading parameters / payloads, or while responding to the client (as the write back to the click can block)).
>
> DGS: My code isn't holding anything, but Glassfish might be.
Your code looks like this:
Connection conn = getConnection;
// Do some stuff
conn.close();
During the "do some stuff" period of time, your application is "holding the connection". When you close the connection, it gets returned to the pool. That's all we are talking about: the "do some stuff" interval.
Robert is recommending that you minimize the time it takes to "do some stuff". So if you have stuff in there that isn't really working with the db directly, try to move that code outside of the "get connection" and "return connection" area. This will get the connection back into the pool as quickly as possible so it can help serve other requests.
DGS: For the first two or three connections, the "do some stuff" part takes only a few milliseconds, and the last one takes only a bit longer because it takes time to do some calculations, but it's quite quick too.
> Anyway, different designs are also valid, but that would be my approach.
> Especially if you need to deal with a large number of requests in short periods of time (which if you are peaking at 269, it suggests you are).
>
> DGS: I don't know exactly what that number 269 represents.
This came from one of your previous posts.
DGS: This number came from the Glassfish monitoring system, which presents numerous data items without explaining exactly what they mean. It is some sort of maximum, but I'm not sure what it maximizes.
> If this is a low use system or you aren't really in need of optimizing throughput and computing resources for high capacities, or the cost of computer resources is negligible compared to the cost of time to improve efficiency, then there is no compelling motivation to change it.
>
> DGS: This is my thinking too. But I'm hoping that the website will get a lot of use in the future, in which case there might be problems.
Better to sort these things out now when you aren't in a panic. :)
DGS: Good advice. But at this point, I wouldn't know what else to do regarding Glassfish. Maybe Tomcat is a better option than Glassfish. I will look into this.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Thanks Chris for adding more details and answering Dan's questions. Chris'
interpretations are what I was trying to convey.
On Wed, Aug 13, 2025 at 2:56 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> Dan,
>
> On 8/13/25 12:38 AM, Daniel Schwartz wrote:
> > -----Original Message-----
> > From: Robert Turner <rt...@e-djuster.ca.INVALID>
> > Sent: Monday, August 11, 2025 10:12 PM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: How to access a REST service
> >
> > If one is going to make multiple requests (especially without much logic
> in-between), I would suggest reusing the same connection (wrapped with the
> relevant resource management logic). Obtaining a connection is a higher
> cost operation than a query request, and releasing and reacquiring it
> requires more synchronization overhead which can reduce parallelism for
> handling many requests at once.
> >
> > DGS: I don't currently know how to do this, but I think there is a way
> to identify a user "session" in the website and then only open one DB
> connection per session. I will look into it.
>
> Do *NOT*, under any circumstances, do this.
>
> If you let a user login (or not, maybe you don't require login) and take
> a db connection from the pool and not return it until they log-off (or
> some suitable timeout occurs), then your application will fall-over
> after 2 minutes no matter what your pool configuration is.
>
> > Also, what you are suggesting above is that three, non-concurrent
> connections are obtained. I'm not sure we got this impression from previous
> communications. At least I thought you had three connections open at the
> same time for the request. Hence our greater concern.
> >
> > DGS: The connections are separate and non-concurrent---running in series.
>
> This is completely fine. Robert's advice was if there is an opportunity
> to merge these application-data-requests into a single "get connection",
> "get data - plural", "return connection" workflow, you could get some
> benefit from it. But a single request which performs several of these,
> including "get connection" and "return connection" operations during its
> lifetime should not be a problem. It's just slightly less optimal from a
> performance perspective. Don't worry too much about it unless you see
> some low-hanging fruit.
>
> > Also, minimizing the time the DB connection is held and obtaining all
> the data as quickly as possible makes for more efficient reuse of
> connections in the pool when there are many requests contending for the DB
> connections.
> > (Avoid holding your DB connections while reading parameters / payloads,
> or while responding to the client (as the write back to the click can
> block)).
> >
> > DGS: My code isn't holding anything, but Glassfish might be.
>
> Your code looks like this:
>
> Connection conn = getConnection;
>
> // Do some stuff
>
> conn.close();
>
> During the "do some stuff" period of time, your application is "holding
> the connection". When you close the connection, it gets returned to the
> pool. That's all we are talking about: the "do some stuff" interval.
> Robert is recommending that you minimize the time it takes to "do some
> stuff". So if you have stuff in there that isn't really working with the
> db directly, try to move that code outside of the "get connection" and
> "return connection" area. This will get the connection back into the
> pool as quickly as possible so it can help serve other requests.
>
> > Anyway, different designs are also valid, but that would be my approach.
> > Especially if you need to deal with a large number of requests in short
> periods of time (which if you are peaking at 269, it suggests you are).
> >
> > DGS: I don't know exactly what that number 269 represents.
>
> This came from one of your previous posts.
>
> > If this is a low use system or you aren't really in need of optimizing
> throughput and computing resources for high capacities, or the cost of
> computer resources is negligible compared to the cost of time to improve
> efficiency, then there is no compelling motivation to change it.
> >
> > DGS: This is my thinking too. But I'm hoping that the website will get
> a lot of use in the future, in which case there might be problems.
>
> Better to sort these things out now when you aren't in a panic. :)
>
> -chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
On 8/13/25 12:38 AM, Daniel Schwartz wrote:
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Monday, August 11, 2025 10:12 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> If one is going to make multiple requests (especially without much logic in-between), I would suggest reusing the same connection (wrapped with the relevant resource management logic). Obtaining a connection is a higher cost operation than a query request, and releasing and reacquiring it requires more synchronization overhead which can reduce parallelism for handling many requests at once.
>
> DGS: I don't currently know how to do this, but I think there is a way to identify a user "session" in the website and then only open one DB connection per session. I will look into it.
Do *NOT*, under any circumstances, do this.
If you let a user login (or not, maybe you don't require login) and take
a db connection from the pool and not return it until they log-off (or
some suitable timeout occurs), then your application will fall-over
after 2 minutes no matter what your pool configuration is.
> Also, what you are suggesting above is that three, non-concurrent connections are obtained. I'm not sure we got this impression from previous communications. At least I thought you had three connections open at the same time for the request. Hence our greater concern.
>
> DGS: The connections are separate and non-concurrent---running in series.
This is completely fine. Robert's advice was if there is an opportunity
to merge these application-data-requests into a single "get connection",
"get data - plural", "return connection" workflow, you could get some
benefit from it. But a single request which performs several of these,
including "get connection" and "return connection" operations during its
lifetime should not be a problem. It's just slightly less optimal from a
performance perspective. Don't worry too much about it unless you see
some low-hanging fruit.
> Also, minimizing the time the DB connection is held and obtaining all the data as quickly as possible makes for more efficient reuse of connections in the pool when there are many requests contending for the DB connections.
> (Avoid holding your DB connections while reading parameters / payloads, or while responding to the client (as the write back to the click can block)).
>
> DGS: My code isn't holding anything, but Glassfish might be.
Your code looks like this:
Connection conn = getConnection;
// Do some stuff
conn.close();
During the "do some stuff" period of time, your application is "holding
the connection". When you close the connection, it gets returned to the
pool. That's all we are talking about: the "do some stuff" interval.
Robert is recommending that you minimize the time it takes to "do some
stuff". So if you have stuff in there that isn't really working with the
db directly, try to move that code outside of the "get connection" and
"return connection" area. This will get the connection back into the
pool as quickly as possible so it can help serve other requests.
> Anyway, different designs are also valid, but that would be my approach.
> Especially if you need to deal with a large number of requests in short periods of time (which if you are peaking at 269, it suggests you are).
>
> DGS: I don't know exactly what that number 269 represents.
This came from one of your previous posts.
> If this is a low use system or you aren't really in need of optimizing throughput and computing resources for high capacities, or the cost of computer resources is negligible compared to the cost of time to improve efficiency, then there is no compelling motivation to change it.
>
> DGS: This is my thinking too. But I'm hoping that the website will get a lot of use in the future, in which case there might be problems.
Better to sort these things out now when you aren't in a panic. :)
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Monday, August 11, 2025 10:12 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
One additional set of suggestions for this project or for the future
(inline):
On Mon, Aug 11, 2025, 21:53 Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> DGS: A single simple query to my interface requires three database
> accesses, one to retrieve a list of countries, then, when the use
> selects a country, another database access to get the lists of states
> and cities associated with that country, and then assuming the
> simplest case where there are no states or cities, then a third
> database access when the user enters a year and requests the holidays
> for that country in that year. If there are states selected, then a
> fourth database access is required to get the cites for that state or to determine that there aren't any.
>
If one is going to make multiple requests (especially without much logic in-between), I would suggest reusing the same connection (wrapped with the relevant resource management logic). Obtaining a connection is a higher cost operation than a query request, and releasing and reacquiring it requires more synchronization overhead which can reduce parallelism for handling many requests at once.
DGS: I don't currently know how to do this, but I think there is a way to identify a user "session" in the website and then only open one DB connection per session. I will look into it.
Also, what you are suggesting above is that three, non-concurrent connections are obtained. I'm not sure we got this impression from previous communications. At least I thought you had three connections open at the same time for the request. Hence our greater concern.
DGS: The connections are separate and non-concurrent---running in series.
Also, minimizing the time the DB connection is held and obtaining all the data as quickly as possible makes for more efficient reuse of connections in the pool when there are many requests contending for the DB connections.
(Avoid holding your DB connections while reading parameters / payloads, or while responding to the client (as the write back to the click can block)).
DGS: My code isn't holding anything, but Glassfish might be.
Anyway, different designs are also valid, but that would be my approach.
Especially if you need to deal with a large number of requests in short periods of time (which if you are peaking at 269, it suggests you are).
DGS: I don't know exactly what that number 269 represents.
If this is a low use system or you aren't really in need of optimizing throughput and computing resources for high capacities, or the cost of computer resources is negligible compared to the cost of time to improve efficiency, then there is no compelling motivation to change it.
DGS: This is my thinking too. But I'm hoping that the website will get a lot of use in the future, in which case there might be problems.
Robert
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
One additional set of suggestions for this project or for the future
(inline):
On Mon, Aug 11, 2025, 21:53 Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> DGS: A single simple query to my interface requires three database
> accesses, one to retrieve a list of countries, then, when the use selects a
> country, another database access to get the lists of states and cities
> associated with that country, and then assuming the simplest case where
> there are no states or cities, then a third database access when the user
> enters a year and requests the holidays for that country in that year. If
> there are states selected, then a fourth database access is required to get
> the cites for that state or to determine that there aren't any.
>
If one is going to make multiple requests (especially without much logic
in-between), I would suggest reusing the same connection (wrapped with the
relevant resource management logic). Obtaining a connection is a higher
cost operation than a query request, and releasing and reacquiring it
requires more synchronization overhead which can reduce parallelism for
handling many requests at once.
Also, what you are suggesting above is that three, non-concurrent
connections are obtained. I'm not sure we got this impression from previous
communications. At least I thought you had three connections open at the
same time for the request. Hence our greater concern.
Also, minimizing the time the DB connection is held and obtaining all the
data as quickly as possible makes for more efficient reuse of connections
in the pool when there are many requests contending for the DB connections.
(Avoid holding your DB connections while reading parameters / payloads, or
while responding to the client (as the write back to the click can block)).
Anyway, different designs are also valid, but that would be my approach.
Especially if you need to deal with a large number of requests in short
periods of time (which if you are peaking at 269, it suggests you are).
If this is a low use system or you aren't really in need of optimizing
throughput and computing resources for high capacities, or the cost of
computer resources is negligible compared to the cost of time to improve
efficiency, then there is no compelling motivation to change it.
Robert
>
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hi Robert,
Thanks for your thoughts. See my replies marked DSG.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Monday, August 11, 2025 9:37 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
Dan,
According to your attached document, your high water mark was 269, which means at some point you had 269 connections in the pool at once, suggesting around that many in use at once. You likely could lower your limit to
300-500 as a result.
DGS: I could try this and see if it still works. But it seems that a higher number wouldn't hurt. The system just wouldn't need that many at any given time, so they wouldn't be created.
As a few of us have said, that is quite a high number and somewhat surprising, and as Chris said, 3 connections per request is also "odd"
(unless you are accessing 3 different databases, or some other reason that requires distinctly different connections).
DGS: A single simple query to my interface requires three database accesses, one to retrieve a list of countries, then, when the use selects a country, another database access to get the lists of states and cities associated with that country, and then assuming the simplest case where there are no states or cities, then a third database access when the user enters a year and requests the holidays for that country in that year. If there are states selected, then a fourth database access is required to get the cites for that state or to determine that there aren't any.
From the attached document, it doesn't look like you have routine leaks, but as noted before, and by others, the code could leak in certain circumstances, although it generally doesn't seem to be in your sample period.
There are very likely design / performance issues with the application related to the use of connections, but given what you've said before, this is not a priority for you at this time.
I think for a lot of us, we see a fairly concerning issue and would like to help you resolve it, but of course, it's your prerogative to do what makes sense to you.
DGS: I appreciate this, but at this point I am not really sure that there is a problem or what it might be if there is one. My current code seems to be working and Glassfish says that there aren't any leaks.
DGS: Thanks again. I greatly appreciate everyone's taking the time to respond.
Best of luck,
Robert
On Mon, Aug 11, 2025, 21:23 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Hi Chris,
>
> Please see my replies after each of your comments. I have attached a
> copy of the Glassfish page that shows the Connection Pool monitoring
> data. I don't know what all this means, whether it is good, bad, or normal.
> However, I do note the one item "NumPotentialConnLeak" with value "O
> count" and description "Number of potential connection leaks", which
> clearly means that it is not detecting any leaks. So this doesn't
> seem to be an issue.
>
> I still don't know why the system was crashing previously. The
> Glassfish log file was showing a message saying that it was unable to
> create any more connections, and then it crashed. At that time the
> maximum pool size was the default 32. The person I talked to at
> Omnifish said that maximum pool size is the maximum possible number of
> connections, so I tried raising this to 100, and the system still kept
> crashing, so then I raised it to 1000, and now it is working fine.
>
> When I initially wrote to this list, I was considering switching to
> Tomcat because of the problems I was having with Glassfish. For the
> time being, however, since everything seems to be working, I'm not
> prepared to undertake that project. Have many other things to do.
>
> Other replies below are marked DGS. But the answer to most of your
> questions is that "I don't know". I probably should try to find a
> Glassfish reference manual and try to learn what all those data items
> mean.
>
> Dan
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Monday, August 11, 2025 3:41 PM
> To: users@tomcat.apache.org
> Subject: Re: How to access a REST service
>
>
> Dan,
>
> On 8/8/25 12:21 PM, Daniel Schwartz wrote:
> > From your and other people's replies, I'm learning that tracking
> > down memory leaks can be quite daunting and possibly beyond me.
> No, you can definitely figure this out, and it will be well worth the
> trouble.
>
> > I'm aware of the try-with-resources instruction and will look into it.
> > I wrote this code before learning about this.
> >
> > In any case, I will follow your advice and add a "finally" block to
> > the "try" statement. I'm currently closing the connection in case
> > an SQL exception is thrown, but I hadn't considered the possibility
> > of other kinds of exceptions. I suppose that there could be such
> > exceptions, but I'm mystified regarding what those might be.
> >
> > However, there has been a new development. After "fishing" around
> > in the Glassfish administration system, I found that there is a way
> > to monitor the JDBC connection pool and get all sorts of information.
> > Based on this, I really don't think that there is any memory leak at
> > all.
> >
> > When running a simple query on my website, I see that
> > NumConnAcquired increases by three (which is what I would expect),
> > and immediately thereafter NumConnReleased increases by the same number.
> Wait, a single request obtains 3 connections? That sounds odd to me,
> unless you are executing more than one of these types of operations
> per request. It's not particularly odd to borrow more than one
> connection per request, but I just wanted to make sure that we were
> all understanding what it means for a "normal request".
>
> > So every connection that is being acquired is also being released. I
> > think that, if there were a memory leak, the number of connections
> > acquired would be increasing at a faster pace than the number being
> > released.
> >> Also, there is a NumConnUsed statistic that has a "High Water Mark"
> > which is described as the "maximum number of connections that were
> > used", and this is currently 160, which is not a lot.
> That sounds like a lot to me. Is that reporting the total number of
> connections requested from the pool, or the current number of
> connections that are still "checked out" of the pool?
>
> DGS: Don't know.
>
> And are you sure that pooling actually is being used?
>
> DGS: Yes.
>
> > So it seems that the system is behaving normally. And I have
> > noticed that since setting the maximum pool size to 1000, the system
> > has not crashed for several days. Probably, 1000 is more than
> > necessary, and you just need make sure you have more possible
> > connections available than the anticipated future high-water mark.
> > But this seems to be working.
> >
> > So maybe I'm just imagining problems that no longer exist. As long
> > as the system keeps running, I'm fine with this.
> >
> > Thanks to everyone for their replies.
> If you let this run for a few days, what does the NumConnUsed counter
> look like? Is it counting pool-check-outs, or is it counting
> real-connections-created?
>
> DGS: Don't know.
>
> -chris
>
> > -----Original Message-----
> > From: Robert Turner <rt...@e-djuster.ca.INVALID>
> > Sent: Friday, August 8, 2025 1:32 AM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: How to access a REST service
> >
> > (sorry for any errors, I'm bashing this out quickly on my phone
> > before going to bed)
> >
> > On Fri, Aug 8, 2025, 00:59 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
> >
> >> Hello Chuck,
> >>
> >> You are correct, I only catch SQL exceptions. I have modified my
> >> code so that the Connection object will be closed if an SQL
> >> exception is thrown, but I wasn’t aware that there are other types
> >> of exceptions that I should look for. I will look into this.
> >>
> >
> >
> > I would encourage entering "avoid java resource leak" into Google
> > and
> reading the "AI" generated details or any other articles that come up.
> The "AI" description it gave me was a reasonable overview of what we
> are trying to convey to you and how to resolve it.
> >
> > Unchecked exceptions can be thrown and the compiler will not warn
> > about
> it.
> > This may be the issue, but it it not guaranteed, but it definitely
> > is a
> potential and obvious problem with the code.
> >
> > You need to ensure that everything related to the connection
> (connection, ResultSet, Statement, PreparedStatement) are also
> released
> (closed) or they will retain references to the connection and the
> connection may not be returned to the pool.
> >
> > As previously mentioned by others, using try-with-resources for all
> > of
> these objects is strongly recommended to avoid leaks. If you are uaing
> older Java (consider upgrading), you will need to use finally blocks
> instead (as previously mentioned by others).
> >
> > Unfortunately, you have only posted a portion of the code, and it
> > may be
> the case that it the problems stems from elsewhere (like where you
> make the queries, or anywhere else that obtains a connection).
> >
> > It should be easy to get a tool to analyze the code (say your IDE
> > (if
> you use one), PMD, Spotbugs, Sonarqube, etc.) and they would likely
> point out all the potential resource leaks. Many IDEs, such as
> Intellij IDEA, also provide such analysis built in. They basically
> look for any object derived from AutoClosable and ensure you are
> closing the object in a finally clause (or in all potential code
> paths). If you aren't, you have a leak.
> >
> >
> >> However, I don’t think that this is causing a memory link, since my
> >> code has always run perfectly without throwing any exceptions at
> >> all, as far as I know.
> >>
> >
> > You may not know. The container (Glassfish or Tomcat) often catches
> > them
> and unless you are checking their logs, you may not see any evidence
> of them.
> >
> >
> >> But I’m beginning to wonder if my “close” operation is actually
> >> being recognized by Glassfish. It seems possible that this is not
> >> being communicated to Glassfish, and the Connection object
> >> continues to be marked as being in use. This would be a leak. But
> >> I don’t know if this is happening.
> >>
> >
> > It's certainly possible that some behaviour of the container and
> > it's
> pooling system is exasperating your issue, but I strongly doubt the
> container is at fault. It is almost guaranteed to be your code.
> >
> >
> > There are other possibly issues with your code, but these are less
> "critical" than your leaks, but could also be a potential source of issues.
> > Namely you have static Global's that are not protected against
> concurrency, and the containers typically run each request in separate
> threads. You could be creating more than one instance of your "singleton"
> as a result.
> >
> >
> >
> >> Dan
> >>
> >> From: Chuck Caldarale <n8...@gmail.com>
> >> Sent: Thursday, August 7, 2025 11:52 PM
> >> To: Tomcat Users List <us...@tomcat.apache.org>
> >> Subject: Re: How to access a REST service
> >>
> >>> On 2025 Aug 7, at 21:43, Daniel Schwartz <dan@danielgschwartz.com
> >> <ma...@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 <n8...@gmail.com>)<
> >> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=5361
> >> 6c
> >> 7
> >> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5
> >> b8
> >> a
> >> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e
> >> 05
> >> b
> >> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd981
> >> 4a
> >> 3
> >> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc
> >> 28
> >> 9
> >> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a2
> >> 7c
> >> e
> >> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673ef
> >> b1
> >> 4 e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
> >>>
> >> Learn More<
> >> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=5361
> >> 6c
> >> 7
> >> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5
> >> b8
> >> a
> >> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e
> >> 05
> >> b
> >> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd981
> >> 4a
> >> 3
> >> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc
> >> 28
> >> 9
> >> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a2
> >> 7c
> >> e
> >> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673ef
> >> b1
> >> 4 e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
> >>>
> >> 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 <dan@danielgschwartz.com
> >> <ma...@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 <rturner@e-djuster.ca.INVALID<mailto:
> >> rturner@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
> >>> <dan@danielgschwartz.com
> >> <ma...@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-unsubscribe@tomcat.apache.org<mailto:
> >> users-unsubscribe@tomcat.apache.org>
> >>
> >>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> >> users-help@tomcat.apache.org>
> >>
> >>>
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------------------
> >> --
> >>
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> >> users-unsubscribe@tomcat.apache.org>
> >>
> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> >> users-help@tomcat.apache.org>
> >>
> >>
> >>
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Dan,
According to your attached document, your high water mark was 269, which
means at some point you had 269 connections in the pool at once, suggesting
around that many in use at once. You likely could lower your limit to
300-500 as a result.
As a few of us have said, that is quite a high number and somewhat
surprising, and as Chris said, 3 connections per request is also "odd"
(unless you are accessing 3 different databases, or some other reason that
requires distinctly different connections).
From the attached document, it doesn't look like you have routine leaks,
but as noted before, and by others, the code could leak in certain
circumstances, although it generally doesn't seem to be in your sample
period.
There are very likely design / performance issues with the application
related to the use of connections, but given what you've said before, this
is not a priority for you at this time.
I think for a lot of us, we see a fairly concerning issue and would like to
help you resolve it, but of course, it's your prerogative to do what makes
sense to you.
Best of luck,
Robert
On Mon, Aug 11, 2025, 21:23 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Hi Chris,
>
> Please see my replies after each of your comments. I have attached a copy
> of the Glassfish page that shows the Connection Pool monitoring data. I
> don't know what all this means, whether it is good, bad, or normal.
> However, I do note the one item "NumPotentialConnLeak" with value "O
> count" and description "Number of potential connection leaks", which
> clearly means that it is not detecting any leaks. So this doesn't seem to
> be an issue.
>
> I still don't know why the system was crashing previously. The Glassfish
> log file was showing a message saying that it was unable to create any more
> connections, and then it crashed. At that time the maximum pool size was
> the default 32. The person I talked to at Omnifish said that maximum pool
> size is the maximum possible number of connections, so I tried raising this
> to 100, and the system still kept crashing, so then I raised it to 1000,
> and now it is working fine.
>
> When I initially wrote to this list, I was considering switching to Tomcat
> because of the problems I was having with Glassfish. For the time being,
> however, since everything seems to be working, I'm not prepared to
> undertake that project. Have many other things to do.
>
> Other replies below are marked DGS. But the answer to most of your
> questions is that "I don't know". I probably should try to find a
> Glassfish reference manual and try to learn what all those data items
> mean.
>
> Dan
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Monday, August 11, 2025 3:41 PM
> To: users@tomcat.apache.org
> Subject: Re: How to access a REST service
>
>
> Dan,
>
> On 8/8/25 12:21 PM, Daniel Schwartz wrote:
> > From your and other people's replies, I'm learning that tracking down
> > memory leaks can be quite daunting and possibly beyond me.
> No, you can definitely figure this out, and it will be well worth the
> trouble.
>
> > I'm aware of the try-with-resources instruction and will look into it.
> > I wrote this code before learning about this.
> >
> > In any case, I will follow your advice and add a "finally" block to
> > the "try" statement. I'm currently closing the connection in case an
> > SQL exception is thrown, but I hadn't considered the possibility of
> > other kinds of exceptions. I suppose that there could be such
> > exceptions, but I'm mystified regarding what those might be.
> >
> > However, there has been a new development. After "fishing" around in
> > the Glassfish administration system, I found that there is a way to
> > monitor the JDBC connection pool and get all sorts of information.
> > Based on this, I really don't think that there is any memory leak at
> > all.
> >
> > When running a simple query on my website, I see that NumConnAcquired
> > increases by three (which is what I would expect), and immediately
> > thereafter NumConnReleased increases by the same number.
> Wait, a single request obtains 3 connections? That sounds odd to me,
> unless you are executing more than one of these types of operations per
> request. It's not particularly odd to borrow more than one connection per
> request, but I just wanted to make sure that we were all understanding what
> it means for a "normal request".
>
> > So every connection that is being acquired is also being released. I
> > think that, if there were a memory leak, the number of connections
> > acquired would be increasing at a faster pace than the number being
> > released.
> >> Also, there is a NumConnUsed statistic that has a "High Water Mark"
> > which is described as the "maximum number of connections that were
> > used", and this is currently 160, which is not a lot.
> That sounds like a lot to me. Is that reporting the total number of
> connections requested from the pool, or the current number of connections
> that are still "checked out" of the pool?
>
> DGS: Don't know.
>
> And are you sure that pooling actually is being used?
>
> DGS: Yes.
>
> > So it seems that the system is behaving normally. And I have noticed
> > that since setting the maximum pool size to 1000, the system has not
> > crashed for several days. Probably, 1000 is more than necessary, and
> > you just need make sure you have more possible connections available
> > than the anticipated future high-water mark.
> > But this seems to be working.
> >
> > So maybe I'm just imagining problems that no longer exist. As long as
> > the system keeps running, I'm fine with this.
> >
> > Thanks to everyone for their replies.
> If you let this run for a few days, what does the NumConnUsed counter look
> like? Is it counting pool-check-outs, or is it counting
> real-connections-created?
>
> DGS: Don't know.
>
> -chris
>
> > -----Original Message-----
> > From: Robert Turner <rt...@e-djuster.ca.INVALID>
> > Sent: Friday, August 8, 2025 1:32 AM
> > To: Tomcat Users List <us...@tomcat.apache.org>
> > Subject: Re: How to access a REST service
> >
> > (sorry for any errors, I'm bashing this out quickly on my phone before
> > going to bed)
> >
> > On Fri, Aug 8, 2025, 00:59 Daniel Schwartz <da...@danielgschwartz.com>
> wrote:
> >
> >> Hello Chuck,
> >>
> >> You are correct, I only catch SQL exceptions. I have modified my
> >> code so that the Connection object will be closed if an SQL exception
> >> is thrown, but I wasn’t aware that there are other types of
> >> exceptions that I should look for. I will look into this.
> >>
> >
> >
> > I would encourage entering "avoid java resource leak" into Google and
> reading the "AI" generated details or any other articles that come up. The
> "AI" description it gave me was a reasonable overview of what we are trying
> to convey to you and how to resolve it.
> >
> > Unchecked exceptions can be thrown and the compiler will not warn about
> it.
> > This may be the issue, but it it not guaranteed, but it definitely is a
> potential and obvious problem with the code.
> >
> > You need to ensure that everything related to the connection
> (connection, ResultSet, Statement, PreparedStatement) are also released
> (closed) or they will retain references to the connection and the
> connection may not be returned to the pool.
> >
> > As previously mentioned by others, using try-with-resources for all of
> these objects is strongly recommended to avoid leaks. If you are uaing
> older Java (consider upgrading), you will need to use finally blocks
> instead (as previously mentioned by others).
> >
> > Unfortunately, you have only posted a portion of the code, and it may be
> the case that it the problems stems from elsewhere (like where you make the
> queries, or anywhere else that obtains a connection).
> >
> > It should be easy to get a tool to analyze the code (say your IDE (if
> you use one), PMD, Spotbugs, Sonarqube, etc.) and they would likely point
> out all the potential resource leaks. Many IDEs, such as Intellij IDEA,
> also provide such analysis built in. They basically look for any object
> derived from AutoClosable and ensure you are closing the object in a
> finally clause (or in all potential code paths). If you aren't, you have a
> leak.
> >
> >
> >> However, I don’t think that this is causing a memory link, since my
> >> code has always run perfectly without throwing any exceptions at all,
> >> as far as I know.
> >>
> >
> > You may not know. The container (Glassfish or Tomcat) often catches them
> and unless you are checking their logs, you may not see any evidence of
> them.
> >
> >
> >> But I’m beginning to wonder if my “close” operation is actually being
> >> recognized by Glassfish. It seems possible that this is not being
> >> communicated to Glassfish, and the Connection object continues to be
> >> marked as being in use. This would be a leak. But I don’t know if
> >> this is happening.
> >>
> >
> > It's certainly possible that some behaviour of the container and it's
> pooling system is exasperating your issue, but I strongly doubt the
> container is at fault. It is almost guaranteed to be your code.
> >
> >
> > There are other possibly issues with your code, but these are less
> "critical" than your leaks, but could also be a potential source of issues.
> > Namely you have static Global's that are not protected against
> concurrency, and the containers typically run each request in separate
> threads. You could be creating more than one instance of your "singleton"
> as a result.
> >
> >
> >
> >> Dan
> >>
> >> From: Chuck Caldarale <n8...@gmail.com>
> >> Sent: Thursday, August 7, 2025 11:52 PM
> >> To: Tomcat Users List <us...@tomcat.apache.org>
> >> Subject: Re: How to access a REST service
> >>
> >>> On 2025 Aug 7, at 21:43, Daniel Schwartz <dan@danielgschwartz.com
> >> <ma...@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 <n8...@gmail.com>)<
> >> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c
> >> 7
> >> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8
> >> a
> >> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05
> >> b
> >> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a
> >> 3
> >> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc28
> >> 9
> >> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27c
> >> e
> >> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb1
> >> 4 e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
> >>>
> >> Learn More<
> >> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c
> >> 7
> >> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8
> >> a
> >> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05
> >> b
> >> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a
> >> 3
> >> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc28
> >> 9
> >> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27c
> >> e
> >> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb1
> >> 4 e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
> >>>
> >> 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 <dan@danielgschwartz.com
> >> <ma...@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 <rturner@e-djuster.ca.INVALID<mailto:
> >> rturner@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
> >>> <dan@danielgschwartz.com
> >> <ma...@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-unsubscribe@tomcat.apache.org<mailto:
> >> users-unsubscribe@tomcat.apache.org>
> >>
> >>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> >> users-help@tomcat.apache.org>
> >>
> >>>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> >> users-unsubscribe@tomcat.apache.org>
> >>
> >> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> >> users-help@tomcat.apache.org>
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hi Chris,
Please see my replies after each of your comments. I have attached a copy of the Glassfish page that shows the Connection Pool monitoring data. I don't know what all this means, whether it is good, bad, or normal. However, I do note the one item "NumPotentialConnLeak" with value "O count" and description "Number of potential connection leaks", which clearly means that it is not detecting any leaks. So this doesn't seem to be an issue.
I still don't know why the system was crashing previously. The Glassfish log file was showing a message saying that it was unable to create any more connections, and then it crashed. At that time the maximum pool size was the default 32. The person I talked to at Omnifish said that maximum pool size is the maximum possible number of connections, so I tried raising this to 100, and the system still kept crashing, so then I raised it to 1000, and now it is working fine.
When I initially wrote to this list, I was considering switching to Tomcat because of the problems I was having with Glassfish. For the time being, however, since everything seems to be working, I'm not prepared to undertake that project. Have many other things to do.
Other replies below are marked DGS. But the answer to most of your questions is that "I don't know". I probably should try to find a Glassfish reference manual and try to learn what all those data items mean.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, August 11, 2025 3:41 PM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Dan,
On 8/8/25 12:21 PM, Daniel Schwartz wrote:
> From your and other people's replies, I'm learning that tracking down
> memory leaks can be quite daunting and possibly beyond me.
No, you can definitely figure this out, and it will be well worth the trouble.
> I'm aware of the try-with-resources instruction and will look into it.
> I wrote this code before learning about this.
>
> In any case, I will follow your advice and add a "finally" block to
> the "try" statement. I'm currently closing the connection in case an
> SQL exception is thrown, but I hadn't considered the possibility of
> other kinds of exceptions. I suppose that there could be such
> exceptions, but I'm mystified regarding what those might be.
>
> However, there has been a new development. After "fishing" around in
> the Glassfish administration system, I found that there is a way to
> monitor the JDBC connection pool and get all sorts of information.
> Based on this, I really don't think that there is any memory leak at
> all.
>
> When running a simple query on my website, I see that NumConnAcquired
> increases by three (which is what I would expect), and immediately
> thereafter NumConnReleased increases by the same number.
Wait, a single request obtains 3 connections? That sounds odd to me, unless you are executing more than one of these types of operations per request. It's not particularly odd to borrow more than one connection per request, but I just wanted to make sure that we were all understanding what it means for a "normal request".
> So every connection that is being acquired is also being released. I
> think that, if there were a memory leak, the number of connections
> acquired would be increasing at a faster pace than the number being
> released.
>> Also, there is a NumConnUsed statistic that has a "High Water Mark"
> which is described as the "maximum number of connections that were
> used", and this is currently 160, which is not a lot.
That sounds like a lot to me. Is that reporting the total number of connections requested from the pool, or the current number of connections that are still "checked out" of the pool?
DGS: Don't know.
And are you sure that pooling actually is being used?
DGS: Yes.
> So it seems that the system is behaving normally. And I have noticed
> that since setting the maximum pool size to 1000, the system has not
> crashed for several days. Probably, 1000 is more than necessary, and
> you just need make sure you have more possible connections available
> than the anticipated future high-water mark.
> But this seems to be working.
>
> So maybe I'm just imagining problems that no longer exist. As long as
> the system keeps running, I'm fine with this.
>
> Thanks to everyone for their replies.
If you let this run for a few days, what does the NumConnUsed counter look like? Is it counting pool-check-outs, or is it counting real-connections-created?
DGS: Don't know.
-chris
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Friday, August 8, 2025 1:32 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> (sorry for any errors, I'm bashing this out quickly on my phone before
> going to bed)
>
> On Fri, Aug 8, 2025, 00:59 Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
>> Hello Chuck,
>>
>> You are correct, I only catch SQL exceptions. I have modified my
>> code so that the Connection object will be closed if an SQL exception
>> is thrown, but I wasn’t aware that there are other types of
>> exceptions that I should look for. I will look into this.
>>
>
>
> I would encourage entering "avoid java resource leak" into Google and reading the "AI" generated details or any other articles that come up. The "AI" description it gave me was a reasonable overview of what we are trying to convey to you and how to resolve it.
>
> Unchecked exceptions can be thrown and the compiler will not warn about it.
> This may be the issue, but it it not guaranteed, but it definitely is a potential and obvious problem with the code.
>
> You need to ensure that everything related to the connection (connection, ResultSet, Statement, PreparedStatement) are also released (closed) or they will retain references to the connection and the connection may not be returned to the pool.
>
> As previously mentioned by others, using try-with-resources for all of these objects is strongly recommended to avoid leaks. If you are uaing older Java (consider upgrading), you will need to use finally blocks instead (as previously mentioned by others).
>
> Unfortunately, you have only posted a portion of the code, and it may be the case that it the problems stems from elsewhere (like where you make the queries, or anywhere else that obtains a connection).
>
> It should be easy to get a tool to analyze the code (say your IDE (if you use one), PMD, Spotbugs, Sonarqube, etc.) and they would likely point out all the potential resource leaks. Many IDEs, such as Intellij IDEA, also provide such analysis built in. They basically look for any object derived from AutoClosable and ensure you are closing the object in a finally clause (or in all potential code paths). If you aren't, you have a leak.
>
>
>> However, I don’t think that this is causing a memory link, since my
>> code has always run perfectly without throwing any exceptions at all,
>> as far as I know.
>>
>
> You may not know. The container (Glassfish or Tomcat) often catches them and unless you are checking their logs, you may not see any evidence of them.
>
>
>> But I’m beginning to wonder if my “close” operation is actually being
>> recognized by Glassfish. It seems possible that this is not being
>> communicated to Glassfish, and the Connection object continues to be
>> marked as being in use. This would be a leak. But I don’t know if
>> this is happening.
>>
>
> It's certainly possible that some behaviour of the container and it's pooling system is exasperating your issue, but I strongly doubt the container is at fault. It is almost guaranteed to be your code.
>
>
> There are other possibly issues with your code, but these are less "critical" than your leaks, but could also be a potential source of issues.
> Namely you have static Global's that are not protected against concurrency, and the containers typically run each request in separate threads. You could be creating more than one instance of your "singleton" as a result.
>
>
>
>> Dan
>>
>> From: Chuck Caldarale <n8...@gmail.com>
>> Sent: Thursday, August 7, 2025 11:52 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: Re: How to access a REST service
>>
>>> On 2025 Aug 7, at 21:43, Daniel Schwartz <dan@danielgschwartz.com
>> <ma...@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 <n8...@gmail.com>)<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c
>> 7
>> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8
>> a
>> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05
>> b
>> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a
>> 3
>> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc28
>> 9
>> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27c
>> e
>> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb1
>> 4 e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
>>>
>> Learn More<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c
>> 7
>> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8
>> a
>> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05
>> b
>> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a
>> 3
>> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc28
>> 9
>> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27c
>> e
>> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb1
>> 4 e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
>>>
>> 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 <dan@danielgschwartz.com
>> <ma...@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 <rturner@e-djuster.ca.INVALID<mailto:
>> rturner@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
>>> <dan@danielgschwartz.com
>> <ma...@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-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
On 8/8/25 12:21 PM, Daniel Schwartz wrote:
> From your and other people's replies, I'm learning that tracking
> down memory leaks can be quite daunting and possibly beyond me.
No, you can definitely figure this out, and it will be well worth the
trouble.
> I'm aware of the try-with-resources instruction and will look into
> it. I wrote this code before learning about this.
>
> In any case, I will follow your advice and add a "finally" block to
> the "try" statement. I'm currently closing the connection in case
> an SQL exception is thrown, but I hadn't considered the possibility
> of other kinds of exceptions. I suppose that there could be such
> exceptions, but I'm mystified regarding what those might be.
>
> However, there has been a new development. After "fishing" around
> in the Glassfish administration system, I found that there is a way
> to monitor the JDBC connection pool and get all sorts of
> information. Based on this, I really don't think that there is any
> memory leak at all.
>
> When running a simple query on my website, I see that
> NumConnAcquired increases by three (which is what I would expect),
> and immediately thereafter NumConnReleased increases by the same
> number.
Wait, a single request obtains 3 connections? That sounds odd to me,
unless you are executing more than one of these types of operations per
request. It's not particularly odd to borrow more than one connection
per request, but I just wanted to make sure that we were all
understanding what it means for a "normal request".
> So every connection that is being acquired is also being released. I
> think that, if there were a memory leak, the number of connections
> acquired would be increasing at a faster pace than the number being
> released.
>> Also, there is a NumConnUsed statistic that has a "High Water Mark"
> which is described as the "maximum number of connections that were
> used", and this is currently 160, which is not a lot.
That sounds like a lot to me. Is that reporting the total number of
connections requested from the pool, or the current number of
connections that are still "checked out" of the pool?
And are you sure that pooling actually is being used?
> So it seems that the system is behaving normally. And I have
> noticed that since setting the maximum pool size to 1000, the system
> has not crashed for several days. Probably, 1000 is more than
> necessary, and you just need make sure you have more possible
> connections available than the anticipated future high-water mark.
> But this seems to be working.
>
> So maybe I'm just imagining problems that no longer exist. As long
> as the system keeps running, I'm fine with this.
>
> Thanks to everyone for their replies.
If you let this run for a few days, what does the NumConnUsed counter
look like? Is it counting pool-check-outs, or is it counting
real-connections-created?
-chris
> -----Original Message-----
> From: Robert Turner <rt...@e-djuster.ca.INVALID>
> Sent: Friday, August 8, 2025 1:32 AM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> (sorry for any errors, I'm bashing this out quickly on my phone before going to bed)
>
> On Fri, Aug 8, 2025, 00:59 Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
>> Hello Chuck,
>>
>> You are correct, I only catch SQL exceptions. I have modified my code
>> so that the Connection object will be closed if an SQL exception is
>> thrown, but I wasn’t aware that there are other types of exceptions
>> that I should look for. I will look into this.
>>
>
>
> I would encourage entering "avoid java resource leak" into Google and reading the "AI" generated details or any other articles that come up. The "AI" description it gave me was a reasonable overview of what we are trying to convey to you and how to resolve it.
>
> Unchecked exceptions can be thrown and the compiler will not warn about it.
> This may be the issue, but it it not guaranteed, but it definitely is a potential and obvious problem with the code.
>
> You need to ensure that everything related to the connection (connection, ResultSet, Statement, PreparedStatement) are also released (closed) or they will retain references to the connection and the connection may not be returned to the pool.
>
> As previously mentioned by others, using try-with-resources for all of these objects is strongly recommended to avoid leaks. If you are uaing older Java (consider upgrading), you will need to use finally blocks instead (as previously mentioned by others).
>
> Unfortunately, you have only posted a portion of the code, and it may be the case that it the problems stems from elsewhere (like where you make the queries, or anywhere else that obtains a connection).
>
> It should be easy to get a tool to analyze the code (say your IDE (if you use one), PMD, Spotbugs, Sonarqube, etc.) and they would likely point out all the potential resource leaks. Many IDEs, such as Intellij IDEA, also provide such analysis built in. They basically look for any object derived from AutoClosable and ensure you are closing the object in a finally clause (or in all potential code paths). If you aren't, you have a leak.
>
>
>> However, I don’t think that this is causing a memory link, since my
>> code has always run perfectly without throwing any exceptions at all,
>> as far as I know.
>>
>
> You may not know. The container (Glassfish or Tomcat) often catches them and unless you are checking their logs, you may not see any evidence of them.
>
>
>> But I’m beginning to wonder if my “close” operation is actually being
>> recognized by Glassfish. It seems possible that this is not being
>> communicated to Glassfish, and the Connection object continues to be
>> marked as being in use. This would be a leak. But I don’t know if
>> this is happening.
>>
>
> It's certainly possible that some behaviour of the container and it's pooling system is exasperating your issue, but I strongly doubt the container is at fault. It is almost guaranteed to be your code.
>
>
> There are other possibly issues with your code, but these are less "critical" than your leaks, but could also be a potential source of issues.
> Namely you have static Global's that are not protected against concurrency, and the containers typically run each request in separate threads. You could be creating more than one instance of your "singleton" as a result.
>
>
>
>> Dan
>>
>> From: Chuck Caldarale <n8...@gmail.com>
>> Sent: Thursday, August 7, 2025 11:52 PM
>> To: Tomcat Users List <us...@tomcat.apache.org>
>> Subject: Re: How to access a REST service
>>
>>> On 2025 Aug 7, at 21:43, Daniel Schwartz <dan@danielgschwartz.com
>> <ma...@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 <n8...@gmail.com>)<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
>> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
>> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
>> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
>> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
>> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
>> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
>> e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
>>>
>> Learn More<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
>> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
>> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
>> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
>> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
>> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
>> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
>> e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
>>>
>> 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 <dan@danielgschwartz.com
>> <ma...@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 <rturner@e-djuster.ca.INVALID<mailto:
>> rturner@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
>>> <dan@danielgschwartz.com
>> <ma...@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-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Chris,
Have you actually tried out my website: www,worldholidaysandevents,com [replace commas with periods]. If you see how it works, this might answer many of your questions.
More comments below.
Dan
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Thursday, August 14, 2025 9:21 AM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Dan,
On 8/12/25 10:52 PM, Daniel Schwartz wrote:
> If you go to my website,
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.worldholidaysa
> ndevents.com&d=DwIDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=oFNq_hrTBDUEKGoGwwKZtrn1fzqspMlEAI2L0cMrH4mEdjIFrgaTHKJCPajHdgtQ&s=QlPiDJ5MIOpt_OBVEqbGa2ImGuhP6xb97mlrh7uXKCU&e=, and make a request for holiday info for, say, Tallahassee, Florida, USA, 2025, you will see the following actions:
>
> 1. The Countries list is filled with a list of countries. This is one DB connection.
>
> 2. When you select United States of America, the States and Cities lists are filled with US states and cities. This is one more DB connection, actually two queries in one connection.
Great. Any time you know you must perform multiple db-related actions, you should definitely do them with a single connection all at once.
DGS: This would be impossible unless I group these requests into a user "session", which I have been advised by someone, maybe you, is not a good idea. The problem with this is that the "session" could remain open for a long time, thereby keeping the DB connection officially active even though it's not being used. I agree that this is something I wouldn't want.
> 3. When you select Florida from the States list, then the cities list is refilled with just Florida cities. This is one more DB connection.
Yes and no. "When you select" implies that there is user interaction.
For a web application, "user interaction" means "request is made from client (browser) to server (your application running in Glassfish/Tomcat)". From the perspective of your code, each of (1), (2), and (3) is a single connection in a single request. When you click "Florida" on your page, you are not repeating queries (1) and (2) again before proceeding to (3). Only (3) is performed, and only requires a single connection to do so.
If you *are* repeating (1) and (2) before (3), you might consider whether or not it's necessary to do so.
DGS: I am not repeating anything. Look at the website and you will see how it works.
> 4. When you select 2025 as the year and click “Explore” this is another DB connection, calculating dates and returning the list of holidays and events.
I'm assuming that this operation gets a connection, gets all necessary data, then returns the connection. After that it does whatever other preparation is necessary to return the response to the client, and then the request-response workflow is complete. This should also only take one connection.
Everything you described above should be possible with a single connection in the pool. If your pool grows in development with only you making serial requests, then "something else" is going on.
DGS: Again, this would only be possible by associating those connections with a user "session", which I have been told is a bad idea.
> So the way the system currently operates, all these DB connections are necessary. However, if there were some way to identify a user “session”, then all of these queries could be carried out in one session and with only one DB connection per session. Probably there is a way to do this, but I haven’t explored it yet. Right now, if you run these operations, you’ll see that the response is very quick. However, I don’t know what might happen if I were to get a lot of users.
Assuming that "session" above means "HttpSession" then definitely do not do this. You want a connection to be out of the pool for as short a time as possible.
DGS: Right. It *was* you that advised me not to do this. I appreciate the insight.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
On 8/12/25 10:52 PM, Daniel Schwartz wrote:
> If you go to my website, www.worldholidaysandevents.com, and make a
> request for holiday info for, say, Tallahassee, Florida, USA, 2025,
> you will see the following actions:
>
> 1. The Countries list is filled with a list of countries. This is one DB connection.
>
> 2. When you select United States of America, the States and Cities lists are filled with US states and cities. This is one more DB connection, actually two queries in one connection.
Great. Any time you know you must perform multiple db-related actions,
you should definitely do them with a single connection all at once.
> 3. When you select Florida from the States list, then the cities list is refilled with just Florida cities. This is one more DB connection.
Yes and no. "When you select" implies that there is user interaction.
For a web application, "user interaction" means "request is made from
client (browser) to server (your application running in
Glassfish/Tomcat)". From the perspective of your code, each of (1), (2),
and (3) is a single connection in a single request. When you click
"Florida" on your page, you are not repeating queries (1) and (2) again
before proceeding to (3). Only (3) is performed, and only requires a
single connection to do so.
If you *are* repeating (1) and (2) before (3), you might consider
whether or not it's necessary to do so.
> 4. When you select 2025 as the year and click “Explore” this is another DB connection, calculating dates and returning the list of holidays and events.
I'm assuming that this operation gets a connection, gets all necessary
data, then returns the connection. After that it does whatever other
preparation is necessary to return the response to the client, and then
the request-response workflow is complete. This should also only take
one connection.
Everything you described above should be possible with a single
connection in the pool. If your pool grows in development with only you
making serial requests, then "something else" is going on.
> So the way the system currently operates, all these DB connections are necessary. However, if there were some way to identify a user “session”, then all of these queries could be carried out in one session and with only one DB connection per session. Probably there is a way to do this, but I haven’t explored it yet. Right now, if you run these operations, you’ll see that the response is very quick. However, I don’t know what might happen if I were to get a lot of users.
Assuming that "session" above means "HttpSession" then definitely do not
do this. You want a connection to be out of the pool for as short a time
as possible.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Rob,
More remarks marked with DGS.
Dan
From: Rob Sargent <rs...@xmission.com>
Sent: Tuesday, August 12, 2025 4:47 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
> On Aug 12, 2025, at 2:29 PM, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > Hello Felix, > > See my replies marked with DGS. > > Dan > > DGS: I explained this in a previous email. Each user interaction
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f7d83eb5bc0da9ce032742e1727d69909aabd7a803384b835c7cd8bae99c1ec0bf5963d3abfa0fb2dbddcfb7188813f83a28396921439fc9d27c7e1b17517952e7ac323bc29f618abe08be370043eb0ee805afd1d089d228e15dbea14e3ccfd11b25a9a4753f4d782cc66e817bfe34484472f7e0df37681ecbdd7cc77993ce8c38d90f6e0dc3e8be2737f7e7b1a1a41c7b6b94a0c6dde45e1cc4e80b862723696a80b35810dc1ed4c40ecd69833beadd0eadd1366f64b511db69ea145108a4301b048308d4c661078700c558d0b7c00a9291ce02375032346c65684296505585c4d1911820c6e2685>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f7d83eb5bc0da9ce032742e1727d69909aabd7a803384b835c7cd8bae99c1ec0bf5963d3abfa0fb2dbddcfb7188813f83a28396921439fc9d27c7e1b17517952e7ac323bc29f618abe08be370043eb0ee805afd1d089d228e15dbea14e3ccfd11b25a9a4753f4d782cc66e817bfe34484472f7e0df37681ecbdd7cc77993ce8c38d90f6e0dc3e8be2737f7e7b1a1a41c7b6b94a0c6dde45e1cc4e80b862723696a80b35810dc1ed4c40ecd69833beadd0eadd1366f64b511db69ea145108a4301b048308d4c661078700c558d0b7c00a9291ce02375032346c65684296505585c4d1911820c6e2685>
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 Aug 12, 2025, at 2:29 PM, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Hello Felix,
>
> See my replies marked with DGS.
>
> Dan
>
> DGS: I explained this in a previous email. Each user interaction requires either 3 or 4 database queries. That’s how my system works. There’s no way around this. But it’s really quite quick. Three of the four queries are simple SQL table look-up queries; only one requires any complex computations.
>
We can’t see exactly how those three queries are performed. They could be:
- on three separate and serial db calls
- all rolled into a single batch of DML
- each sql statement sent simultaneously (nearly) on a separate thread.
The first two require only one db connection. Each call will acquire and release the connection. And the first of those will hold that connection for the shorter time, the second for the longer time.
The third option will possibly finish the db work fastest id the is no contention amongst the queries. But this is the only one which requires more than one simultaneous db connection.
Does any of these match your architecture?
DGS: If you go to my website, www.worldholidaysandevents.com, and make a request for holiday info for, say, Tallahassee, Florida, USA, 2025, you will see the following actions:
1. The Countries list is filled with a list of countries. This is one DB connection.
2. When you select United States of America, the States and Cities lists are filled with US states and cities. This is one more DB connection, actually two queries in one connection.
3. When you select Florida from the States list, then the cities list is refilled with just Florida cities. This is one more DB connection.
4. When you select 2025 as the year and click “Explore” this is another DB connection, calculating dates and returning the list of holidays and events.
So the way the system currently operates, all these DB connections are necessary. However, if there were some way to identify a user “session”, then all of these queries could be carried out in one session and with only one DB connection per session. Probably there is a way to do this, but I haven’t explored it yet. Right now, if you run these operations, you’ll see that the response is very quick. However, I don’t know what might happen if I were to get a lot of users.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
> On Aug 12, 2025, at 2:29 PM, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Hello Felix,
>
> See my replies marked with DGS.
>
> Dan
>
> DGS: I explained this in a previous email. Each user interaction requires either 3 or 4 database queries. That’s how my system works. There’s no way around this. But it’s really quite quick. Three of the four queries are simple SQL table look-up queries; only one requires any complex computations.
>
We can’t see exactly how those three queries are performed. They could be:
- on three separate and serial db calls
- all rolled into a single batch of DML
- each sql statement sent simultaneously (nearly) on a separate thread.
The first two require only one db connection. Each call will acquire and release the connection. And the first of those will hold that connection for the shorter time, the second for the longer time.
The third option will possibly finish the db work fastest id the is no contention amongst the queries. But this is the only one which requires more than one simultaneous db connection.
Does any of these match your architecture?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Felix,
See my replies marked with DGS.
Dan
From: Felix Schumacher <fe...@internetallee.de>
Sent: Tuesday, August 12, 2025 2:47 PM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Am 08.08.25 um 18:21 schrieb Daniel Schwartz:
Hello Robert,
From your and other people's replies, I'm learning that tracking down memory leaks can be quite daunting and possibly beyond me.
I'm aware of the try-with-resources instruction and will look into it. I wrote this code before learning about this.
In any case, I will follow your advice and add a "finally" block to the "try" statement. I'm currently closing the connection in case an SQL exception is thrown, but I hadn't considered the possibility of other kinds of exceptions. I suppose that there could be such exceptions, but I'm mystified regarding what those might be.
However, there has been a new development. After "fishing" around in the Glassfish administration system, I found that there is a way to monitor the JDBC connection pool and get all sorts of information. Based on this, I really don't think that there is any memory leak at all.
When running a simple query on my website, I see that NumConnAcquired increases by three (which is what I would expect), and immediately thereafter NumConnReleased increases by the same number. So every connection that is being acquired is also being released. I think that, if there were a memory leak, the number of connections acquired would be increasing at a faster pace than the number being released.
Also, there is a NumConnUsed statistic that has a "High Water Mark" which is described as the "maximum number of connections that were used", and this is currently 160, which is not a lot.
So, if every page hit takes up three connections (as I read it above), that would imply, that you have around 50ish concurrent page hits in maximum. Is that consistent with your data?
If so, you probably don't have a connection leak, but rather an unusual program design that uses (in my opinion) far too many connections for each page hit.
DGS: I explained this in a previous email. Each user interaction requires either 3 or 4 database queries. That’s how my system works. There’s no way around this. But it’s really quite quick. Three of the four queries are simple SQL table look-up queries; only one requires any complex computations.
If you don't see a correlation between concurrent requests to your service and your database (now, that you are able to view those metrics), I would set the reclaim option for the database pool as described at https://glassfish.org/docs/latest/administration-guide.html#statement-leak-detection-and-leaked-statement-reclamation (note I haven't run Glassfish myself, but I like the log abandoned feature from tomcats db pool).
DGS: Thanks for the link. I took a quick look, but it’s quite long and would take me a lot of work to absorb it. Maybe later.
Felix
So it seems that the system is behaving normally. And I have noticed that since setting the maximum pool size to 1000, the system has not crashed for several days. Probably, 1000 is more than necessary, and you just need make sure you have more possible connections available than the anticipated future high-water mark. But this seems to be working.
So maybe I'm just imagining problems that no longer exist. As long as the system keeps running, I'm fine with this.
Thanks to everyone for their replies.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Friday, August 8, 2025 1:32 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
(sorry for any errors, I'm bashing this out quickly on my phone before going to bed)
On Fri, Aug 8, 2025, 00:59 Daniel Schwartz <da...@danielgschwartz.com> wrote:
Hello Chuck,
You are correct, I only catch SQL exceptions. I have modified my code
so that the Connection object will be closed if an SQL exception is
thrown, but I wasn’t aware that there are other types of exceptions
that I should look for. I will look into this.
I would encourage entering "avoid java resource leak" into Google and reading the "AI" generated details or any other articles that come up. The "AI" description it gave me was a reasonable overview of what we are trying to convey to you and how to resolve it.
Unchecked exceptions can be thrown and the compiler will not warn about it.
This may be the issue, but it it not guaranteed, but it definitely is a potential and obvious problem with the code.
You need to ensure that everything related to the connection (connection, ResultSet, Statement, PreparedStatement) are also released (closed) or they will retain references to the connection and the connection may not be returned to the pool.
As previously mentioned by others, using try-with-resources for all of these objects is strongly recommended to avoid leaks. If you are uaing older Java (consider upgrading), you will need to use finally blocks instead (as previously mentioned by others).
Unfortunately, you have only posted a portion of the code, and it may be the case that it the problems stems from elsewhere (like where you make the queries, or anywhere else that obtains a connection).
It should be easy to get a tool to analyze the code (say your IDE (if you use one), PMD, Spotbugs, Sonarqube, etc.) and they would likely point out all the potential resource leaks. Many IDEs, such as Intellij IDEA, also provide such analysis built in. They basically look for any object derived from AutoClosable and ensure you are closing the object in a finally clause (or in all potential code paths). If you aren't, you have a leak.
However, I don’t think that this is causing a memory link, since my
code has always run perfectly without throwing any exceptions at all,
as far as I know.
You may not know. The container (Glassfish or Tomcat) often catches them and unless you are checking their logs, you may not see any evidence of them.
But I’m beginning to wonder if my “close” operation is actually being
recognized by Glassfish. It seems possible that this is not being
communicated to Glassfish, and the Connection object continues to be
marked as being in use. This would be a leak. But I don’t know if
this is happening.
It's certainly possible that some behaviour of the container and it's pooling system is exasperating your issue, but I strongly doubt the container is at fault. It is almost guaranteed to be your code.
There are other possibly issues with your code, but these are less "critical" than your leaks, but could also be a potential source of issues.
Namely you have static Global's that are not protected against concurrency, and the containers typically run each request in separate threads. You could be creating more than one instance of your "singleton" as a result.
Dan
From: Chuck Caldarale <n8...@gmail.com>
Sent: Thursday, August 7, 2025 11:52 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
On 2025 Aug 7, at 21:43, Daniel Schwartz <da...@danielgschwartz.com>
<ma...@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 <n8...@gmail.com>)<
https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
Learn More<
https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
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 <da...@danielgschwartz.com>
<ma...@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 <rt...@e-djuster.ca.INVALID><mailto:
rturner@e-djuster.ca.INVALID<ma...@e-djuster.ca.INVALID>>>
Sent: Thursday, August 7, 2025 5:07 PM
To: Tomcat Users List <us...@tomcat.apache.org><mailto:
users@tomcat.apache.org<ma...@tomcat.apache.org>>>
Subject: Re: How to access a REST service
Dan,
On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz
<da...@danielgschwartz.com>
<ma...@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-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org><mailto:
users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org><mailto:
users-help@tomcat.apache.org<ma...@tomcat.apache.org>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
users-unsubscribe@tomcat.apache.org><ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
users-help@tomcat.apache.org><ma...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: How to access a REST service
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 08.08.25 um 18:21 schrieb Daniel Schwartz:
> Hello Robert,
>
> From your and other people's replies, I'm learning that tracking down memory leaks can be quite daunting and possibly beyond me.
>
> I'm aware of the try-with-resources instruction and will look into it. I wrote this code before learning about this.
>
> In any case, I will follow your advice and add a "finally" block to the "try" statement. I'm currently closing the connection in case an SQL exception is thrown, but I hadn't considered the possibility of other kinds of exceptions. I suppose that there could be such exceptions, but I'm mystified regarding what those might be.
>
> However, there has been a new development. After "fishing" around in the Glassfish administration system, I found that there is a way to monitor the JDBC connection pool and get all sorts of information. Based on this, I really don't think that there is any memory leak at all.
>
> When running a simple query on my website, I see that NumConnAcquired increases by three (which is what I would expect), and immediately thereafter NumConnReleased increases by the same number. So every connection that is being acquired is also being released. I think that, if there were a memory leak, the number of connections acquired would be increasing at a faster pace than the number being released.
>
> Also, there is a NumConnUsed statistic that has a "High Water Mark" which is described as the "maximum number of connections that were used", and this is currently 160, which is not a lot.
So, if every page hit takes up three connections (as I read it above),
that would imply, that you have around 50ish concurrent page hits in
maximum. Is that consistent with your data?
If so, you probably don't have a connection leak, but rather an unusual
program design that uses (in my opinion) far too many connections for
each page hit.
If you don't see a correlation between concurrent requests to your
service and your database (now, that you are able to view those
metrics), I would set the reclaim option for the database pool as
described at
https://glassfish.org/docs/latest/administration-guide.html#statement-leak-detection-and-leaked-statement-reclamation
(note I haven't run Glassfish myself, but I like the log abandoned
feature from tomcats db pool).
Felix
>
> So it seems that the system is behaving normally. And I have noticed that since setting the maximum pool size to 1000, the system has not crashed for several days. Probably, 1000 is more than necessary, and you just need make sure you have more possible connections available than the anticipated future high-water mark. But this seems to be working.
>
> So maybe I'm just imagining problems that no longer exist. As long as the system keeps running, I'm fine with this.
>
> Thanks to everyone for their replies.
>
> Dan
>
> -----Original Message-----
> From: Robert Turner<rt...@e-djuster.ca.INVALID>
> Sent: Friday, August 8, 2025 1:32 AM
> To: Tomcat Users List<us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> (sorry for any errors, I'm bashing this out quickly on my phone before going to bed)
>
> On Fri, Aug 8, 2025, 00:59 Daniel Schwartz<da...@danielgschwartz.com> wrote:
>
>> Hello Chuck,
>>
>> You are correct, I only catch SQL exceptions. I have modified my code
>> so that the Connection object will be closed if an SQL exception is
>> thrown, but I wasn’t aware that there are other types of exceptions
>> that I should look for. I will look into this.
>>
>
> I would encourage entering "avoid java resource leak" into Google and reading the "AI" generated details or any other articles that come up. The "AI" description it gave me was a reasonable overview of what we are trying to convey to you and how to resolve it.
>
> Unchecked exceptions can be thrown and the compiler will not warn about it.
> This may be the issue, but it it not guaranteed, but it definitely is a potential and obvious problem with the code.
>
> You need to ensure that everything related to the connection (connection, ResultSet, Statement, PreparedStatement) are also released (closed) or they will retain references to the connection and the connection may not be returned to the pool.
>
> As previously mentioned by others, using try-with-resources for all of these objects is strongly recommended to avoid leaks. If you are uaing older Java (consider upgrading), you will need to use finally blocks instead (as previously mentioned by others).
>
> Unfortunately, you have only posted a portion of the code, and it may be the case that it the problems stems from elsewhere (like where you make the queries, or anywhere else that obtains a connection).
>
> It should be easy to get a tool to analyze the code (say your IDE (if you use one), PMD, Spotbugs, Sonarqube, etc.) and they would likely point out all the potential resource leaks. Many IDEs, such as Intellij IDEA, also provide such analysis built in. They basically look for any object derived from AutoClosable and ensure you are closing the object in a finally clause (or in all potential code paths). If you aren't, you have a leak.
>
>
>> However, I don’t think that this is causing a memory link, since my
>> code has always run perfectly without throwing any exceptions at all,
>> as far as I know.
>>
> You may not know. The container (Glassfish or Tomcat) often catches them and unless you are checking their logs, you may not see any evidence of them.
>
>
>> But I’m beginning to wonder if my “close” operation is actually being
>> recognized by Glassfish. It seems possible that this is not being
>> communicated to Glassfish, and the Connection object continues to be
>> marked as being in use. This would be a leak. But I don’t know if
>> this is happening.
>>
> It's certainly possible that some behaviour of the container and it's pooling system is exasperating your issue, but I strongly doubt the container is at fault. It is almost guaranteed to be your code.
>
>
> There are other possibly issues with your code, but these are less "critical" than your leaks, but could also be a potential source of issues.
> Namely you have static Global's that are not protected against concurrency, and the containers typically run each request in separate threads. You could be creating more than one instance of your "singleton" as a result.
>
>
>
>> Dan
>>
>> From: Chuck Caldarale<n8...@gmail.com>
>> Sent: Thursday, August 7, 2025 11:52 PM
>> To: Tomcat Users List<us...@tomcat.apache.org>
>> Subject: Re: How to access a REST service
>>
>>> On 2025 Aug 7, at 21:43, Daniel Schwartz <dan@danielgschwartz.com
>> <ma...@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<n8...@gmail.com>)<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
>> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
>> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
>> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
>> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
>> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
>> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
>> e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
>> Learn More<
>> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
>> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
>> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
>> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
>> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
>> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
>> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
>> e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
>> 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 <dan@danielgschwartz.com
>> <ma...@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 <rturner@e-djuster.ca.INVALID<mailto:
>> rturner@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
>>> <dan@danielgschwartz.com
>> <ma...@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-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>>> For additional commands, e-mail:users-help@tomcat.apache.org<mailto:
>> users-help@tomcat.apache.org>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail:users-unsubscribe@tomcat.apache.org<mailto:
>> users-unsubscribe@tomcat.apache.org>
>>
>> For additional commands, e-mail:users-help@tomcat.apache.org<mailto: users-help@tomcat.apache.org>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:users-help@tomcat.apache.org
>
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Robert,
From your and other people's replies, I'm learning that tracking down memory leaks can be quite daunting and possibly beyond me.
I'm aware of the try-with-resources instruction and will look into it. I wrote this code before learning about this.
In any case, I will follow your advice and add a "finally" block to the "try" statement. I'm currently closing the connection in case an SQL exception is thrown, but I hadn't considered the possibility of other kinds of exceptions. I suppose that there could be such exceptions, but I'm mystified regarding what those might be.
However, there has been a new development. After "fishing" around in the Glassfish administration system, I found that there is a way to monitor the JDBC connection pool and get all sorts of information. Based on this, I really don't think that there is any memory leak at all.
When running a simple query on my website, I see that NumConnAcquired increases by three (which is what I would expect), and immediately thereafter NumConnReleased increases by the same number. So every connection that is being acquired is also being released. I think that, if there were a memory leak, the number of connections acquired would be increasing at a faster pace than the number being released.
Also, there is a NumConnUsed statistic that has a "High Water Mark" which is described as the "maximum number of connections that were used", and this is currently 160, which is not a lot.
So it seems that the system is behaving normally. And I have noticed that since setting the maximum pool size to 1000, the system has not crashed for several days. Probably, 1000 is more than necessary, and you just need make sure you have more possible connections available than the anticipated future high-water mark. But this seems to be working.
So maybe I'm just imagining problems that no longer exist. As long as the system keeps running, I'm fine with this.
Thanks to everyone for their replies.
Dan
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Friday, August 8, 2025 1:32 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
(sorry for any errors, I'm bashing this out quickly on my phone before going to bed)
On Fri, Aug 8, 2025, 00:59 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Hello Chuck,
>
> You are correct, I only catch SQL exceptions. I have modified my code
> so that the Connection object will be closed if an SQL exception is
> thrown, but I wasn’t aware that there are other types of exceptions
> that I should look for. I will look into this.
>
I would encourage entering "avoid java resource leak" into Google and reading the "AI" generated details or any other articles that come up. The "AI" description it gave me was a reasonable overview of what we are trying to convey to you and how to resolve it.
Unchecked exceptions can be thrown and the compiler will not warn about it.
This may be the issue, but it it not guaranteed, but it definitely is a potential and obvious problem with the code.
You need to ensure that everything related to the connection (connection, ResultSet, Statement, PreparedStatement) are also released (closed) or they will retain references to the connection and the connection may not be returned to the pool.
As previously mentioned by others, using try-with-resources for all of these objects is strongly recommended to avoid leaks. If you are uaing older Java (consider upgrading), you will need to use finally blocks instead (as previously mentioned by others).
Unfortunately, you have only posted a portion of the code, and it may be the case that it the problems stems from elsewhere (like where you make the queries, or anywhere else that obtains a connection).
It should be easy to get a tool to analyze the code (say your IDE (if you use one), PMD, Spotbugs, Sonarqube, etc.) and they would likely point out all the potential resource leaks. Many IDEs, such as Intellij IDEA, also provide such analysis built in. They basically look for any object derived from AutoClosable and ensure you are closing the object in a finally clause (or in all potential code paths). If you aren't, you have a leak.
> However, I don’t think that this is causing a memory link, since my
> code has always run perfectly without throwing any exceptions at all,
> as far as I know.
>
You may not know. The container (Glassfish or Tomcat) often catches them and unless you are checking their logs, you may not see any evidence of them.
> But I’m beginning to wonder if my “close” operation is actually being
> recognized by Glassfish. It seems possible that this is not being
> communicated to Glassfish, and the Connection object continues to be
> marked as being in use. This would be a leak. But I don’t know if
> this is happening.
>
It's certainly possible that some behaviour of the container and it's pooling system is exasperating your issue, but I strongly doubt the container is at fault. It is almost guaranteed to be your code.
There are other possibly issues with your code, but these are less "critical" than your leaks, but could also be a potential source of issues.
Namely you have static Global's that are not protected against concurrency, and the containers typically run each request in separate threads. You could be creating more than one instance of your "singleton" as a result.
> Dan
>
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Thursday, August 7, 2025 11:52 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> > On 2025 Aug 7, at 21:43, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@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 <n8...@gmail.com>)<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
> e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
> >
> Learn More<
> https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7
> 465645f5fed27a22a24a04d2b4474850fcd4085279f5deb0a4b45aff271dc217bd5b8a
> c8e65b868f686679b9d5ae69c216b8828c6ab976fd096f84ebdac1ecb38a6f62a2e05b
> 1ce3cda3ef1fc6615c2d5d63b3db6ac3d93719e10964cf6ecb92b637712794fd9814a3
> 6d8e401e9510d22d52433dc8526a1fd76ffd29c927dd092a286a002fa6edad24fdc289
> 956069ff246bd9f54272522f4c2b34608a52f7c8a6db9c157660efc922fcaa993a27ce
> 11dcae209b3f911b99a3e50e92edf0e120af447100e9d80cd45918b2f85aa8673efb14
> e6bddb38cdfaa2e1ba5496bad5db8df0857d443aeb0399f46406f
> >
> 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 <dan@danielgschwartz.com
> <ma...@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 <rturner@e-djuster.ca.INVALID<mailto:
> rturner@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
> > <dan@danielgschwartz.com
> <ma...@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-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
> >
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
Re: How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
(sorry for any errors, I'm bashing this out quickly on my phone before
going to bed)
On Fri, Aug 8, 2025, 00:59 Daniel Schwartz <da...@danielgschwartz.com> wrote:
> Hello Chuck,
>
> You are correct, I only catch SQL exceptions. I have modified my code so
> that the Connection object will be closed if an SQL exception is thrown,
> but I wasn’t aware that there are other types of exceptions that I should
> look for. I will look into this.
>
I would encourage entering "avoid java resource leak" into Google and
reading the "AI" generated details or any other articles that come up. The
"AI" description it gave me was a reasonable overview of what we are trying
to convey to you and how to resolve it.
Unchecked exceptions can be thrown and the compiler will not warn about it.
This may be the issue, but it it not guaranteed, but it definitely is a
potential and obvious problem with the code.
You need to ensure that everything related to the connection (connection,
ResultSet, Statement, PreparedStatement) are also released (closed) or they
will retain references to the connection and the connection may not be
returned to the pool.
As previously mentioned by others, using try-with-resources for all of
these objects is strongly recommended to avoid leaks. If you are uaing
older Java (consider upgrading), you will need to use finally blocks
instead (as previously mentioned by others).
Unfortunately, you have only posted a portion of the code, and it may be
the case that it the problems stems from elsewhere (like where you make the
queries, or anywhere else that obtains a connection).
It should be easy to get a tool to analyze the code (say your IDE (if you
use one), PMD, Spotbugs, Sonarqube, etc.) and they would likely point out
all the potential resource leaks. Many IDEs, such as Intellij IDEA, also
provide such analysis built in. They basically look for any object derived
from AutoClosable and ensure you are closing the object in a finally clause
(or in all potential code paths). If you aren't, you have a leak.
> However, I don’t think that this is causing a memory link, since my code
> has always run perfectly without throwing any exceptions at all, as far as
> I know.
>
You may not know. The container (Glassfish or Tomcat) often catches them
and unless you are checking their logs, you may not see any evidence of
them.
> But I’m beginning to wonder if my “close” operation is actually being
> recognized by Glassfish. It seems possible that this is not being
> communicated to Glassfish, and the Connection object continues to be marked
> as being in use. This would be a leak. But I don’t know if this is
> happening.
>
It's certainly possible that some behaviour of the container and it's
pooling system is exasperating your issue, but I strongly doubt the
container is at fault. It is almost guaranteed to be your code.
There are other possibly issues with your code, but these are less
"critical" than your leaks, but could also be a potential source of issues.
Namely you have static Global's that are not protected against concurrency,
and the containers typically run each request in separate threads. You
could be creating more than one instance of your "singleton" as a result.
> Dan
>
> From: Chuck Caldarale <n8...@gmail.com>
> Sent: Thursday, August 7, 2025 11:52 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> > On 2025 Aug 7, at 21:43, Daniel Schwartz <dan@danielgschwartz.com
> <ma...@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 <n8...@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 <dan@danielgschwartz.com
> <ma...@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 <rturner@e-djuster.ca.INVALID<mailto:
> rturner@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 <dan@danielgschwartz.com
> <ma...@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-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> > For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
> >
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<mailto:
> users-unsubscribe@tomcat.apache.org>
>
> For additional commands, e-mail: users-help@tomcat.apache.org<mailto:
> users-help@tomcat.apache.org>
>
>
>
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Thorsten,
-----Original Message-----
From: Thorsten Heit <he...@icloud.com.INVALID>
Sent: Friday, August 8, 2025 2:55 PM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Hi Daniel,
> You are correct, I only catch SQL exceptions. I have modified my code so that the Connection object will be closed if an SQL exception is thrown, but I wasn’t aware that there are other types of exceptions that I should look for. I will look into this.
>
> However, I don’t think that this is causing a memory link, since my code has always run perfectly without throwing any exceptions at all, as far as I know.
Have a look again at your code. You insist of not having a memory leak, but as already mentioned several times in this thread you're not correctly closing objects, especially in case of an exception.
DGS: Please see my recent replies to Rob Sargent and others. The Glassfish monitoring system seems to say that there currently are no leaks.
In the code snippet you presented you only tried to close the connection object itself, but what about other JDBC objects created/used in your code? What about (prepared) statements, result object instances etc.? Do you also close them?
DGS: Yes, everything is being closed.
Please do yourself a favor and use try-with-resources for all classes that implement AutoCloseable. This makes life much easier.
DGS: I discussed this in my previous email to this list. I don't think that approach will work in my situation.
DGS: Thanks for your replies.
DGS: Dan
Regards
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Thorsten Heit <he...@icloud.com.INVALID>.
Hi Daniel,
> You are correct, I only catch SQL exceptions. I have modified my code so that the Connection object will be closed if an SQL exception is thrown, but I wasn’t aware that there are other types of exceptions that I should look for. I will look into this.
>
> However, I don’t think that this is causing a memory link, since my code has always run perfectly without throwing any exceptions at all, as far as I know.
Have a look again at your code. You insist of not having a memory leak,
but as already mentioned several times in this thread you're not
correctly closing objects, especially in case of an exception.
In the code snippet you presented you only tried to close the connection
object itself, but what about other JDBC objects created/used in your
code? What about (prepared) statements, result object instances etc.? Do
you also close them?
Please do yourself a favor and use try-with-resources for all classes
that implement AutoCloseable. This makes life much easier.
Regards
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Chuck,
You are correct, I only catch SQL exceptions. I have modified my code so that the Connection object will be closed if an SQL exception is thrown, but I wasn’t aware that there are other types of exceptions that I should look for. I will look into this.
However, I don’t think that this is causing a memory link, since my code has always run perfectly without throwing any exceptions at all, as far as I know.
But I’m beginning to wonder if my “close” operation is actually being recognized by Glassfish. It seems possible that this is not being communicated to Glassfish, and the Connection object continues to be marked as being in use. This would be a leak. But I don’t know if this is happening.
Dan
From: Chuck Caldarale <n8...@gmail.com>
Sent: Thursday, August 7, 2025 11:52 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
> On 2025 Aug 7, at 21:43, Daniel Schwartz <da...@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 <n8...@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 <da...@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 <rt...@e-djuster.ca.INVALID>>
> Sent: Thursday, August 7, 2025 5:07 PM
> To: Tomcat Users List <us...@tomcat.apache.org>>
> Subject: Re: How to access a REST service
>
> Dan,
>
> On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz <da...@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-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: How to access a REST service
Posted by Chuck Caldarale <n8...@gmail.com>.
> On 2025 Aug 7, at 21:43, Daniel Schwartz <da...@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 <rt...@e-djuster.ca.INVALID>
> Sent: Thursday, August 7, 2025 5:07 PM
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> Dan,
>
> On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz <da...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Robert,
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?
Thanks,
Dan Schwartz
-----Original Message-----
From: Robert Turner <rt...@e-djuster.ca.INVALID>
Sent: Thursday, August 7, 2025 5:07 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
Dan,
On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz <da...@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..
Re: How to access a REST service
Posted by Robert Turner <rt...@e-djuster.ca.INVALID>.
Dan,
On Thu, Aug 7, 2025 at 5:01 PM Daniel Schwartz <da...@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..
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
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.
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.
Best regards,
Dan Schwartz
---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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Well, I guess that this is a top post. But this message is getting longer with all the replies.
I don’t think it is a memory leak. I’m fairly sure that I’m closing every connection immediately after using it. It seems that most of my database queries are coming from web crawlers, and there are a few hundred accesses every day. I was getting error messages from Glassfish saying that it couldn’t allocate any more connection objects and then crashing. At that time the maximum pool size was the default, which is 32. So I believe it was just being overloaded by the web crawlers. Now that I have increased to 1000, the system has stopped crashing.
But I have to admit that I really don’t understand how these connection pooling systems work. 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. Once a database session terminates, then that connection object becomes available for future use. 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?
Dan Schwartz
From: Rob Sargent <rs...@xmission.com>
Sent: Tuesday, August 5, 2025 12:57 AM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
> On Aug 4, 2025, at 8:11 PM, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > Hello Rob, > > I don’t know what a “top post” is or why it should warrant an apology, but I appreciate your taking the time to reply. This
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f65c91d16fc04fd4044b524db9431d4455fd10bc4cf0136584b8f801e0092b93e98c8ef864d9d0ad20e1fed468b5cf45c502c1dbea2144040376aa1813426065709ce03dc3895b11bf1062104116d3d6bbbaa7de6465f4815ede75f97828cdee881437677a9b92b8ceff48ce61ae9baee912b827b449fdd42d66386c3a29495d8c623817048730f3f4b015fce1a31d591e12eae9ac9d3e6dfb15d7b634ba80b662ce7997ce5a9468031b556446dbdb7b43c5ddea5c8257f737bec3eb978f51def90a62f5230f09ba43c9ecf6cc2bff2b7f8fc6ab49cbd18ccc8db290b0b7fad3dbbed36fb39b68ea6>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f65c91d16fc04fd4044b524db9431d4455fd10bc4cf0136584b8f801e0092b93e98c8ef864d9d0ad20e1fed468b5cf45c502c1dbea2144040376aa1813426065709ce03dc3895b11bf1062104116d3d6bbbaa7de6465f4815ede75f97828cdee881437677a9b92b8ceff48ce61ae9baee912b827b449fdd42d66386c3a29495d8c623817048730f3f4b015fce1a31d591e12eae9ac9d3e6dfb15d7b634ba80b662ce7997ce5a9468031b556446dbdb7b43c5ddea5c8257f737bec3eb978f51def90a62f5230f09ba43c9ecf6cc2bff2b7f8fc6ab49cbd18ccc8db290b0b7fad3dbbed36fb39b68ea6>
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 Aug 4, 2025, at 8:11 PM, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Hello Rob,
>
> I don’t know what a “top post” is or why it should warrant an apology, but I appreciate your taking the time to reply. This looks interesting.
>
> I’m currently using Glassfish, which has built in connection pooling. I was having trouble with its crashing frequently with a message saying that it was unable to allocate any more connections. Then I learned that the default pool size was only 32 and that this is the maximum allowed number of concurrent connections, so I increased this to 1000, and now it runs fine. I am new at this, though, and any new info is helpful. Thanks.
>
> Dan Schwartz
1000 is a rather large number of open connections. For one thing they are quite memory intensive. I suspect you are (still) leaking connections - not re-using those with which you have completed a database task. You will likely hit the same error if your system stays up for any length of time.
I recommend going back to Chris’s article to get this leak under control.
PS
This is a bottom post, wherein the new text follows the original.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
> On Aug 4, 2025, at 8:11 PM, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Hello Rob,
>
> I don’t know what a “top post” is or why it should warrant an apology, but I appreciate your taking the time to reply. This looks interesting.
>
> I’m currently using Glassfish, which has built in connection pooling. I was having trouble with its crashing frequently with a message saying that it was unable to allocate any more connections. Then I learned that the default pool size was only 32 and that this is the maximum allowed number of concurrent connections, so I increased this to 1000, and now it runs fine. I am new at this, though, and any new info is helpful. Thanks.
>
> Dan Schwartz
1000 is a rather large number of open connections. For one thing they are quite memory intensive. I suspect you are (still) leaking connections - not re-using those with which you have completed a database task. You will likely hit the same error if your system stays up for any length of time.
I recommend going back to Chris’s article to get this leak under control.
PS
This is a bottom post, wherein the new text follows the original.
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Rob,
I don’t know what a “top post” is or why it should warrant an apology, but I appreciate your taking the time to reply. This looks interesting.
I’m currently using Glassfish, which has built in connection pooling. I was having trouble with its crashing frequently with a message saying that it was unable to allocate any more connections. Then I learned that the default pool size was only 32 and that this is the maximum allowed number of concurrent connections, so I increased this to 1000, and now it runs fine. I am new at this, though, and any new info is helpful. Thanks.
Dan Schwartz
From: Rob Sargent <rs...@xmission.com>
Sent: Monday, August 4, 2025 1:49 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
Another top post apology. If this is your first Java/database rodeo you might want to look at why pools are a good idea and whether or not they fit your need. Maybe here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-3A__www.cockroachlabs.com_blog_what-2Dis-2Dconnection-2Dpooling_-26sa-3DU-26sqi-3D2-26ved-3D2ahUKEwjYm7y42vGOAxV5OzQIHRYbJswQFnoECBUQAQ-26usg-3DAOvVaw3CwmC-2DQEJojMaYtOvsdRes&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=e7w4teh9aIQALHe76U1py0iyqtcjXfx02vzzglOFkc9dh0BgfasDq2oRvIzwK7x-&s=_UWjBLunOHYm7UwZkR5lAR4MUYt2NLMH0w-75mkZZrc&e=
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f2ebf5c9af87d45b424babbbc37daee570ddbcd67c5c68ab379532cb66ab114de01fd9c37e8c61332c8ea1c93987de7e6e2237d38978c92d8e5bd9b5ef7c7c5a4e56b9c36a9347726e69a42772382671b484352203aca56dccb5b8f82aab573aaa485a5c26a75d957ea7cfcf526b1163e259bf5d16dc1cc5a6a59bc88574e12d5aeffda19710131b21fc8121ce924f7373f3bf532bfd26c8c19f7bbf1bbac5e15a4e7e1514f73078722852bad09f7e1b85f27a8cd23abacc73b555597358d6786ebe4cced3771c4c6675226e333b5fbcc104a3e71b9a7db970557831dbd194d1bf5c08d5c74d5c2d8>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f2ebf5c9af87d45b424babbbc37daee570ddbcd67c5c68ab379532cb66ab114de01fd9c37e8c61332c8ea1c93987de7e6e2237d38978c92d8e5bd9b5ef7c7c5a4e56b9c36a9347726e69a42772382671b484352203aca56dccb5b8f82aab573aaa485a5c26a75d957ea7cfcf526b1163e259bf5d16dc1cc5a6a59bc88574e12d5aeffda19710131b21fc8121ce924f7373f3bf532bfd26c8c19f7bbf1bbac5e15a4e7e1514f73078722852bad09f7e1b85f27a8cd23abacc73b555597358d6786ebe4cced3771c4c6675226e333b5fbcc104a3e71b9a7db970557831dbd194d1bf5c08d5c74d5c2d8>
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
Another top post apology.
If this is your first Java/database rodeo you might want to look at why pools are a good idea and whether or not they fit your need.
Maybe here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-3A__www.cockroachlabs.com_blog_what-2Dis-2Dconnection-2Dpooling_-26sa-3DU-26sqi-3D2-26ved-3D2ahUKEwjYm7y42vGOAxV5OzQIHRYbJswQFnoECBUQAQ-26usg-3DAOvVaw3CwmC-2DQEJojMaYtOvsdRes&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=e7w4teh9aIQALHe76U1py0iyqtcjXfx02vzzglOFkc9dh0BgfasDq2oRvIzwK7x-&s=_UWjBLunOHYm7UwZkR5lAR4MUYt2NLMH0w-75mkZZrc&e=
> On Aug 4, 2025, at 10:31 AM, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Hello Chris,
>
> Thanks. This looks helpful.
>
> Dan Schwartz
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>>
> Sent: Monday, August 4, 2025 10:15 AM
> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> Daniel,
>
> Apologies for top-posting, but I would highly recommend reading this:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.christopherschultz.net_2009_03_16_properly-2Dhandling-2Dpooled-2Djdbc-2Dconnections_&d=DwIDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=064mdQS9YsKOGXjo7gBDQ2Mi-puZWT6oWPOKTs_HzFX46_g9-I_RzQ4NZsP5yFkU&s=asZCa1h2Ah3YYzVVNf_SaATQFdLYcoF_wkrSSt6a-Nw&e=
>
> -chris
>
>> On 8/1/25 3:33 PM, Daniel Schwartz wrote:
>> Hello Thorsten,
>>
>> Please see my replies below, marked DGS.
>>
>> -----Original Message-----
>> From: Thorsten Heit <he...@icloud.com.INVALID>>
>> Sent: Friday, August 1, 2025 5:32 AM
>> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>> Subject: Re: How to access a REST service
>>
>> Hi,
>>
>>> Daniel,
>>> You might take a look at java’s “ try with” construct
>>
>> DGS: Someone else recommended this. I will look into it. I see that an issue with my current code is that the database connection won't be closed if an error is thrown.
>>
>> This is an important step, indeed:
>>
>>>> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
>>>> --------------------------------------------------------------------
>>>> -
>>>> ----- public class HolidaysRESTJSONResource {
>>>>
>>>> DataSource dataSource;
>>>>
>>>> public HolidaysRESTJSONResource() {
>>>> dataSource = DataSourceSingleton.getInstance().dataSource;
>>>> }
>>>>
>>>> @GET
>>>> @Path("/countries")
>>>> @Produces(MediaType.APPLICATION_JSON)
>>>> public String getJsonCountries() {
>>>> ...
>>>> Connection connection;
>>>> try {
>>>> connection = dataSource.getConnection();
>>>> TempDataStorage.countryList =
>>>> GetCountryList.doIt(connection);
>>>> connection.close();
>>>> ...
>>>> }
>>
>> A couple of questions:
>>
>> 1) How often is your class instantiated/created? Is it a singleton? A new one per each incoming request?
>>
>> DGS: It is created with every database query. For each user query there can be 1-3 database queries, and the same user can make an unlimited number of queries. I know it would be better if I could somehow identify a "user session" and only create one connection per session, but I don't know how to do this.
>>
>> 2) What happens in case of an exception in your try block? Looking at
>> the above snipped the connection isn't closed.
>>
>> DGS: Yes, that's an issue, which I have noted in the foregoing. I'll change to the "try-with" approach.
>>
>>>> The constructor for HolidaysRESTJSONResource creates a DataSource by
>>>> creating an instance of the following DataSourceSingleton class and
>>>> retrieving the value of the DataSource instance variable. I
>>>> borrowed this code from somewhere. It seems to work. The MySql
>>>> database is called "holidays".
>>
>> 3) Have a look at the version of the database driver you're using. Is
>> there perhaps a newer one? If yes, have a look at the release notes
>> and check the changes. Perhaps there's a leak in the driver itself...?
>>
>> DGS: I'm using the latest MySQL 8 driver.
>>
>>>> Back in HolidaysRESTJSONResource, in the method getJsonCountries(),
>>>> the DataSource object, called "dataSource", is used to create the
>>>> connection object, and this is used in a method call
>>>> GetCountryList.doIt() to retrieve a list of countries from the
>>>> database. Then this connection object is closed. I think that this
>>>> is all that is needed to prevent memory leaks. Is this correct? I
>>>> do this for every such method call that accesses the database.
>>
>> AFAICT only in case of proper execution wrt to the code snippet
>> presented. In case of an exception during the #doIt(...) call this
>> won't happen (correctly) and can result in a memory leak (AFAIK).
>>
>> DGS: Good point. The doIt() method can throw an exception. I will look into this.
>>
>> What happens in case of multiple simultaneously incoming requests?
>> Does your database (and driver) allow enough parallel connections so
>> that each request is processed correctly?
>>
>> DGS: I have the Glassfish database connections maximum pool size set to 1000. This seems to be enough. When I submitted this question, the system was crashing occasionally, but then I noticed that the pool size had inadvertently been reset to the default 32. This must have happened when I reinstalled Glassfish and then neglected to update pool size. It seems to be working now. No crashes in the last day.
>>
>> DGS: Thanks for taking the time to respond. Do you know of a way to identify the start and end of a user session?
>>
>> Regards
>>
>> Thorsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello again, Rob,
Thanks for your reply. This is admittedly beyond my level of expertise, but I'm learning.
A little context. My website is www.worldholidaysandevents.com. This has two components: (1) a backend webservice running Glassfish and MySql, and (2) a website that serves as a user interface that consumes the webservice and which was recently created using Next.js.
The new website was written by a former student that I can still consult with as needed, but otherwise the "team" is just me. The student was very knowledgeable, having done this same kind of work in India before coming to my university. He set this up with an nginx front end, and I can see the accesses in the nginx access.log file. This file is too large for email, but you can view it at www.cs.fsu.edu/~schwartz/access.log. This contains all accesses since Monday, 8/4. The lines that make a reference to "calendar" and some combination of "country", "state", "city", "year" are all database requests.
The IP address 73.118.50.199 is me, running tests. Many of the others are created by web crawlers, with names like Googlebot, DotBot, PetalBot, SemrushBot, bingbot, etc.
However, many of the entries also don't seem to be from webcrawlers, but appear to be bogus requests. For example, the following line occurs repeatedly:
96.9.89.82 - - [04/Aug/2025:22:49:12 +0000] "GET /_next/static/css/a2a6f669bb486c52.css HTTP/1.1" 200 6473 "https://www.worldholidaysandevents.com/calendar?country=Cambodia&year=1983" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36"
And there are other similar types of requests that seem to be manufactured by some robot and that are not identified as coming from a webcrawler (or at least no webcrawler name is given).
My student says that the webcrawlers serve a useful purpose in helping with SEO, so they are a necessary evil. But the others I believe should be blocked, and I understand that this can be done by listing the IP addresses somewhere in nginx. I'm trying figure out how to do this.
Let me also mention that I recently talked with a person at a company called Omnifish, based in Prague I think, that specializes in consulting for Glassfish. He said that the total number of concurrent connections is limited by the maximum size of the pool. Accordingly, getting an error message saying that no additional connections can be created, and the system crashing, occurs when all the connections in the pool are currently in use. He considered this to be normal behavior. That's why I set the size to 1000. It seems to be working. However, if I were designing a pooling system, I wouldn't do it this way, and it seems that other pooling systems do allow for additional connections outside the pool.
Anyway, any further insights you or anyone can give will be appreciated.
Dan Schwartz
From: Rob Sargent <rs...@xmission.com>
Sent: Tuesday, August 5, 2025 11:40 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
> On Aug 5, 2025, at 11:54 AM, Daniel Schwartz <da...@danielgschwartz.com>> wrote: > > Hello again Rob, > > I just read that article you referenced by Cockroach Labs. I found the statement: > > "If we make the
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f1933ea4495d1e4e6e586f0daa8cc6fc871f8631d90342b3e3b73ecb5c6821f786c62f34375bd457a77a4668c15a9446ce1bc5132cf77cbf0be1808f5ebde108808a9a78dcfd981c6b6676df0a8d4944f8b685e15e03ad23ccc798ffdc9c0341efc607b18a96bf37ec3de055760a4984a04f4e70bcbd9fe5e5bc5f1cee0293f413ed97673720d5a9c3d52f1de8787f821f6f776e586b31e3afd1d2c6ea875591c4de3f4928fe99a35f78a1ba82c74b95c02e67da46fe368ef5c1fe726f0c54de0a8d360ef3c80b54db3657b681de4e15544d0a1a88908fa8d27b97335b585492acb5cb53586e3f107>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f1933ea4495d1e4e6e586f0daa8cc6fc871f8631d90342b3e3b73ecb5c6821f786c62f34375bd457a77a4668c15a9446ce1bc5132cf77cbf0be1808f5ebde108808a9a78dcfd981c6b6676df0a8d4944f8b685e15e03ad23ccc798ffdc9c0341efc607b18a96bf37ec3de055760a4984a04f4e70bcbd9fe5e5bc5f1cee0293f413ed97673720d5a9c3d52f1de8787f821f6f776e586b31e3afd1d2c6ea875591c4de3f4928fe99a35f78a1ba82c74b95c02e67da46fe368ef5c1fe726f0c54de0a8d360ef3c80b54db3657b681de4e15544d0a1a88908fa8d27b97335b585492acb5cb53586e3f107>
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 Aug 5, 2025, at 11:54 AM, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Hello again Rob,
>
> I just read that article you referenced by Cockroach Labs. I found the statement:
>
> "If we make the pool too small (i.e. choose too few connections), we’ll introduce latency, as operations have to wait for an available connection to open up before they can execute."
>
> This implies that if the number of concurrent accesses exceeds the number of connection objects in the pool, then the system simply waits until some of the currently active connections terminate and the connection objects become available.
>
> This is not what was happening with Glassfish. When the number of simultaneous requests exceeds the pool size, the system outputs an error message and crashes. It doesn't just wait until some active connections terminate so that the connection objects become available. It seems that different pooling systems have different policies.
>
Bottom posting is generally preferred. Crop to appropriate portion of original.
Are web crawlers making database requests?
Do you know which db calls are actually being made? And when?
Is the switch from 32 to 1000 the only change you made? I don’t think I am the only one here who thinks that is a red herring.
You may need to give more information: db server, connection configuration, servlet code, logs (app, middle tier, dbserver).
I suspect you may have been compromised. Is there anyone at your sight who can comment on this?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
> On Aug 5, 2025, at 11:54 AM, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Hello again Rob,
>
> I just read that article you referenced by Cockroach Labs. I found the statement:
>
> "If we make the pool too small (i.e. choose too few connections), we’ll introduce latency, as operations have to wait for an available connection to open up before they can execute."
>
> This implies that if the number of concurrent accesses exceeds the number of connection objects in the pool, then the system simply waits until some of the currently active connections terminate and the connection objects become available.
>
> This is not what was happening with Glassfish. When the number of simultaneous requests exceeds the pool size, the system outputs an error message and crashes. It doesn't just wait until some active connections terminate so that the connection objects become available. It seems that different pooling systems have different policies.
>
Bottom posting is generally preferred. Crop to appropriate portion of original.
Are web crawlers making database requests?
Do you know which db calls are actually being made? And when?
Is the switch from 32 to 1000 the only change you made? I don’t think I am the only one here who thinks that is a red herring.
You may need to give more information: db server, connection configuration, servlet code, logs (app, middle tier, dbserver).
I suspect you may have been compromised. Is there anyone at your sight who can comment on this?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello again Rob,
I just read that article you referenced by Cockroach Labs. I found the statement:
"If we make the pool too small (i.e. choose too few connections), we’ll introduce latency, as operations have to wait for an available connection to open up before they can execute."
This implies that if the number of concurrent accesses exceeds the number of connection objects in the pool, then the system simply waits until some of the currently active connections terminate and the connection objects become available.
This is not what was happening with Glassfish. When the number of simultaneous requests exceeds the pool size, the system outputs an error message and crashes. It doesn't just wait until some active connections terminate so that the connection objects become available. It seems that different pooling systems have different policies.
Dan Schwartz
From: Rob Sargent <rs...@xmission.com>
Sent: Monday, August 4, 2025 1:49 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
Another top post apology. If this is your first Java/database rodeo you might want to look at why pools are a good idea and whether or not they fit your need. Maybe here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-3A__www.cockroachlabs.com_blog_what-2Dis-2Dconnection-2Dpooling_-26sa-3DU-26sqi-3D2-26ved-3D2ahUKEwjYm7y42vGOAxV5OzQIHRYbJswQFnoECBUQAQ-26usg-3DAOvVaw3CwmC-2DQEJojMaYtOvsdRes&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=e7w4teh9aIQALHe76U1py0iyqtcjXfx02vzzglOFkc9dh0BgfasDq2oRvIzwK7x-&s=_UWjBLunOHYm7UwZkR5lAR4MUYt2NLMH0w-75mkZZrc&e=
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f2ebf5c9af87d45b424babbbc37daee570ddbcd67c5c68ab379532cb66ab114de01fd9c37e8c61332c8ea1c93987de7e6e2237d38978c92d8e5bd9b5ef7c7c5a4e56b9c36a9347726e69a42772382671b484352203aca56dccb5b8f82aab573aaa485a5c26a75d957ea7cfcf526b1163e259bf5d16dc1cc5a6a59bc88574e12d5aeffda19710131b21fc8121ce924f7373f3bf532bfd26c8c19f7bbf1bbac5e15a4e7e1514f73078722852bad09f7e1b85f27a8cd23abacc73b555597358d6786ebe4cced3771c4c6675226e333b5fbcc104a3e71b9a7db970557831dbd194d1bf5c08d5c74d5c2d8>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f2ebf5c9af87d45b424babbbc37daee570ddbcd67c5c68ab379532cb66ab114de01fd9c37e8c61332c8ea1c93987de7e6e2237d38978c92d8e5bd9b5ef7c7c5a4e56b9c36a9347726e69a42772382671b484352203aca56dccb5b8f82aab573aaa485a5c26a75d957ea7cfcf526b1163e259bf5d16dc1cc5a6a59bc88574e12d5aeffda19710131b21fc8121ce924f7373f3bf532bfd26c8c19f7bbf1bbac5e15a4e7e1514f73078722852bad09f7e1b85f27a8cd23abacc73b555597358d6786ebe4cced3771c4c6675226e333b5fbcc104a3e71b9a7db970557831dbd194d1bf5c08d5c74d5c2d8>
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
Another top post apology.
If this is your first Java/database rodeo you might want to look at why pools are a good idea and whether or not they fit your need.
Maybe here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-3A__www.cockroachlabs.com_blog_what-2Dis-2Dconnection-2Dpooling_-26sa-3DU-26sqi-3D2-26ved-3D2ahUKEwjYm7y42vGOAxV5OzQIHRYbJswQFnoECBUQAQ-26usg-3DAOvVaw3CwmC-2DQEJojMaYtOvsdRes&d=DwIFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=e7w4teh9aIQALHe76U1py0iyqtcjXfx02vzzglOFkc9dh0BgfasDq2oRvIzwK7x-&s=_UWjBLunOHYm7UwZkR5lAR4MUYt2NLMH0w-75mkZZrc&e=
> On Aug 4, 2025, at 10:31 AM, Daniel Schwartz <da...@danielgschwartz.com>> wrote:
>
> Hello Chris,
>
> Thanks. This looks helpful.
>
> Dan Schwartz
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>>
> Sent: Monday, August 4, 2025 10:15 AM
> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
> Subject: Re: How to access a REST service
>
> Daniel,
>
> Apologies for top-posting, but I would highly recommend reading this:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.christopherschultz.net_2009_03_16_properly-2Dhandling-2Dpooled-2Djdbc-2Dconnections_&d=DwIDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=064mdQS9YsKOGXjo7gBDQ2Mi-puZWT6oWPOKTs_HzFX46_g9-I_RzQ4NZsP5yFkU&s=asZCa1h2Ah3YYzVVNf_SaATQFdLYcoF_wkrSSt6a-Nw&e=
>
> -chris
>
>> On 8/1/25 3:33 PM, Daniel Schwartz wrote:
>> Hello Thorsten,
>>
>> Please see my replies below, marked DGS.
>>
>> -----Original Message-----
>> From: Thorsten Heit <he...@icloud.com.INVALID>>
>> Sent: Friday, August 1, 2025 5:32 AM
>> To: users@tomcat.apache.org<ma...@tomcat.apache.org>
>> Subject: Re: How to access a REST service
>>
>> Hi,
>>
>>> Daniel,
>>> You might take a look at java’s “ try with” construct
>>
>> DGS: Someone else recommended this. I will look into it. I see that an issue with my current code is that the database connection won't be closed if an error is thrown.
>>
>> This is an important step, indeed:
>>
>>>> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
>>>> --------------------------------------------------------------------
>>>> -
>>>> ----- public class HolidaysRESTJSONResource {
>>>>
>>>> DataSource dataSource;
>>>>
>>>> public HolidaysRESTJSONResource() {
>>>> dataSource = DataSourceSingleton.getInstance().dataSource;
>>>> }
>>>>
>>>> @GET
>>>> @Path("/countries")
>>>> @Produces(MediaType.APPLICATION_JSON)
>>>> public String getJsonCountries() {
>>>> ...
>>>> Connection connection;
>>>> try {
>>>> connection = dataSource.getConnection();
>>>> TempDataStorage.countryList =
>>>> GetCountryList.doIt(connection);
>>>> connection.close();
>>>> ...
>>>> }
>>
>> A couple of questions:
>>
>> 1) How often is your class instantiated/created? Is it a singleton? A new one per each incoming request?
>>
>> DGS: It is created with every database query. For each user query there can be 1-3 database queries, and the same user can make an unlimited number of queries. I know it would be better if I could somehow identify a "user session" and only create one connection per session, but I don't know how to do this.
>>
>> 2) What happens in case of an exception in your try block? Looking at
>> the above snipped the connection isn't closed.
>>
>> DGS: Yes, that's an issue, which I have noted in the foregoing. I'll change to the "try-with" approach.
>>
>>>> The constructor for HolidaysRESTJSONResource creates a DataSource by
>>>> creating an instance of the following DataSourceSingleton class and
>>>> retrieving the value of the DataSource instance variable. I
>>>> borrowed this code from somewhere. It seems to work. The MySql
>>>> database is called "holidays".
>>
>> 3) Have a look at the version of the database driver you're using. Is
>> there perhaps a newer one? If yes, have a look at the release notes
>> and check the changes. Perhaps there's a leak in the driver itself...?
>>
>> DGS: I'm using the latest MySQL 8 driver.
>>
>>>> Back in HolidaysRESTJSONResource, in the method getJsonCountries(),
>>>> the DataSource object, called "dataSource", is used to create the
>>>> connection object, and this is used in a method call
>>>> GetCountryList.doIt() to retrieve a list of countries from the
>>>> database. Then this connection object is closed. I think that this
>>>> is all that is needed to prevent memory leaks. Is this correct? I
>>>> do this for every such method call that accesses the database.
>>
>> AFAICT only in case of proper execution wrt to the code snippet
>> presented. In case of an exception during the #doIt(...) call this
>> won't happen (correctly) and can result in a memory leak (AFAIK).
>>
>> DGS: Good point. The doIt() method can throw an exception. I will look into this.
>>
>> What happens in case of multiple simultaneously incoming requests?
>> Does your database (and driver) allow enough parallel connections so
>> that each request is processed correctly?
>>
>> DGS: I have the Glassfish database connections maximum pool size set to 1000. This seems to be enough. When I submitted this question, the system was crashing occasionally, but then I noticed that the pool size had inadvertently been reset to the default 32. This must have happened when I reinstalled Glassfish and then neglected to update pool size. It seems to be working now. No crashes in the last day.
>>
>> DGS: Thanks for taking the time to respond. Do you know of a way to identify the start and end of a user session?
>>
>> Regards
>>
>> Thorsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
>
Re: How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
Another top post apology.
If this is your first Java/database rodeo you might want to look at why pools are a good idea and whether or not they fit your need.
Maybe here:
https://www.google.com/url?q=https://www.cockroachlabs.com/blog/what-is-connection-pooling/&sa=U&sqi=2&ved=2ahUKEwjYm7y42vGOAxV5OzQIHRYbJswQFnoECBUQAQ&usg=AOvVaw3CwmC-QEJojMaYtOvsdRes
> On Aug 4, 2025, at 10:31 AM, Daniel Schwartz <da...@danielgschwartz.com> wrote:
>
> Hello Chris,
>
> Thanks. This looks helpful.
>
> Dan Schwartz
>
> -----Original Message-----
> From: Christopher Schultz <ch...@christopherschultz.net>
> Sent: Monday, August 4, 2025 10:15 AM
> To: users@tomcat.apache.org
> Subject: Re: How to access a REST service
>
> Daniel,
>
> Apologies for top-posting, but I would highly recommend reading this:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.christopherschultz.net_2009_03_16_properly-2Dhandling-2Dpooled-2Djdbc-2Dconnections_&d=DwIDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=064mdQS9YsKOGXjo7gBDQ2Mi-puZWT6oWPOKTs_HzFX46_g9-I_RzQ4NZsP5yFkU&s=asZCa1h2Ah3YYzVVNf_SaATQFdLYcoF_wkrSSt6a-Nw&e=
>
> -chris
>
>> On 8/1/25 3:33 PM, Daniel Schwartz wrote:
>> Hello Thorsten,
>>
>> Please see my replies below, marked DGS.
>>
>> -----Original Message-----
>> From: Thorsten Heit <he...@icloud.com.INVALID>
>> Sent: Friday, August 1, 2025 5:32 AM
>> To: users@tomcat.apache.org
>> Subject: Re: How to access a REST service
>>
>> Hi,
>>
>>> Daniel,
>>> You might take a look at java’s “ try with” construct
>>
>> DGS: Someone else recommended this. I will look into it. I see that an issue with my current code is that the database connection won't be closed if an error is thrown.
>>
>> This is an important step, indeed:
>>
>>>> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
>>>> --------------------------------------------------------------------
>>>> -
>>>> ----- public class HolidaysRESTJSONResource {
>>>>
>>>> DataSource dataSource;
>>>>
>>>> public HolidaysRESTJSONResource() {
>>>> dataSource = DataSourceSingleton.getInstance().dataSource;
>>>> }
>>>>
>>>> @GET
>>>> @Path("/countries")
>>>> @Produces(MediaType.APPLICATION_JSON)
>>>> public String getJsonCountries() {
>>>> ...
>>>> Connection connection;
>>>> try {
>>>> connection = dataSource.getConnection();
>>>> TempDataStorage.countryList =
>>>> GetCountryList.doIt(connection);
>>>> connection.close();
>>>> ...
>>>> }
>>
>> A couple of questions:
>>
>> 1) How often is your class instantiated/created? Is it a singleton? A new one per each incoming request?
>>
>> DGS: It is created with every database query. For each user query there can be 1-3 database queries, and the same user can make an unlimited number of queries. I know it would be better if I could somehow identify a "user session" and only create one connection per session, but I don't know how to do this.
>>
>> 2) What happens in case of an exception in your try block? Looking at
>> the above snipped the connection isn't closed.
>>
>> DGS: Yes, that's an issue, which I have noted in the foregoing. I'll change to the "try-with" approach.
>>
>>>> The constructor for HolidaysRESTJSONResource creates a DataSource by
>>>> creating an instance of the following DataSourceSingleton class and
>>>> retrieving the value of the DataSource instance variable. I
>>>> borrowed this code from somewhere. It seems to work. The MySql
>>>> database is called "holidays".
>>
>> 3) Have a look at the version of the database driver you're using. Is
>> there perhaps a newer one? If yes, have a look at the release notes
>> and check the changes. Perhaps there's a leak in the driver itself...?
>>
>> DGS: I'm using the latest MySQL 8 driver.
>>
>>>> Back in HolidaysRESTJSONResource, in the method getJsonCountries(),
>>>> the DataSource object, called "dataSource", is used to create the
>>>> connection object, and this is used in a method call
>>>> GetCountryList.doIt() to retrieve a list of countries from the
>>>> database. Then this connection object is closed. I think that this
>>>> is all that is needed to prevent memory leaks. Is this correct? I
>>>> do this for every such method call that accesses the database.
>>
>> AFAICT only in case of proper execution wrt to the code snippet
>> presented. In case of an exception during the #doIt(...) call this
>> won't happen (correctly) and can result in a memory leak (AFAIK).
>>
>> DGS: Good point. The doIt() method can throw an exception. I will look into this.
>>
>> What happens in case of multiple simultaneously incoming requests?
>> Does your database (and driver) allow enough parallel connections so
>> that each request is processed correctly?
>>
>> DGS: I have the Glassfish database connections maximum pool size set to 1000. This seems to be enough. When I submitted this question, the system was crashing occasionally, but then I noticed that the pool size had inadvertently been reset to the default 32. This must have happened when I reinstalled Glassfish and then neglected to update pool size. It seems to be working now. No crashes in the last day.
>>
>> DGS: Thanks for taking the time to respond. Do you know of a way to identify the start and end of a user session?
>>
>> Regards
>>
>> Thorsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Chris,
Thanks. This looks helpful.
Dan Schwartz
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Monday, August 4, 2025 10:15 AM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Daniel,
Apologies for top-posting, but I would highly recommend reading this:
https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.christopherschultz.net_2009_03_16_properly-2Dhandling-2Dpooled-2Djdbc-2Dconnections_&d=DwIDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=064mdQS9YsKOGXjo7gBDQ2Mi-puZWT6oWPOKTs_HzFX46_g9-I_RzQ4NZsP5yFkU&s=asZCa1h2Ah3YYzVVNf_SaATQFdLYcoF_wkrSSt6a-Nw&e=
-chris
On 8/1/25 3:33 PM, Daniel Schwartz wrote:
> Hello Thorsten,
>
> Please see my replies below, marked DGS.
>
> -----Original Message-----
> From: Thorsten Heit <he...@icloud.com.INVALID>
> Sent: Friday, August 1, 2025 5:32 AM
> To: users@tomcat.apache.org
> Subject: Re: How to access a REST service
>
> Hi,
>
>> Daniel,
>> You might take a look at java’s “ try with” construct
>
> DGS: Someone else recommended this. I will look into it. I see that an issue with my current code is that the database connection won't be closed if an error is thrown.
>
> This is an important step, indeed:
>
>>> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
>>> --------------------------------------------------------------------
>>> -
>>> ----- public class HolidaysRESTJSONResource {
>>>
>>> DataSource dataSource;
>>>
>>> public HolidaysRESTJSONResource() {
>>> dataSource = DataSourceSingleton.getInstance().dataSource;
>>> }
>>>
>>> @GET
>>> @Path("/countries")
>>> @Produces(MediaType.APPLICATION_JSON)
>>> public String getJsonCountries() {
>>> ...
>>> Connection connection;
>>> try {
>>> connection = dataSource.getConnection();
>>> TempDataStorage.countryList =
>>> GetCountryList.doIt(connection);
>>> connection.close();
>>> ...
>>> }
>
> A couple of questions:
>
> 1) How often is your class instantiated/created? Is it a singleton? A new one per each incoming request?
>
> DGS: It is created with every database query. For each user query there can be 1-3 database queries, and the same user can make an unlimited number of queries. I know it would be better if I could somehow identify a "user session" and only create one connection per session, but I don't know how to do this.
>
> 2) What happens in case of an exception in your try block? Looking at
> the above snipped the connection isn't closed.
>
> DGS: Yes, that's an issue, which I have noted in the foregoing. I'll change to the "try-with" approach.
>
>>> The constructor for HolidaysRESTJSONResource creates a DataSource by
>>> creating an instance of the following DataSourceSingleton class and
>>> retrieving the value of the DataSource instance variable. I
>>> borrowed this code from somewhere. It seems to work. The MySql
>>> database is called "holidays".
>
> 3) Have a look at the version of the database driver you're using. Is
> there perhaps a newer one? If yes, have a look at the release notes
> and check the changes. Perhaps there's a leak in the driver itself...?
>
> DGS: I'm using the latest MySQL 8 driver.
>
>>> Back in HolidaysRESTJSONResource, in the method getJsonCountries(),
>>> the DataSource object, called "dataSource", is used to create the
>>> connection object, and this is used in a method call
>>> GetCountryList.doIt() to retrieve a list of countries from the
>>> database. Then this connection object is closed. I think that this
>>> is all that is needed to prevent memory leaks. Is this correct? I
>>> do this for every such method call that accesses the database.
>
> AFAICT only in case of proper execution wrt to the code snippet
> presented. In case of an exception during the #doIt(...) call this
> won't happen (correctly) and can result in a memory leak (AFAIK).
>
> DGS: Good point. The doIt() method can throw an exception. I will look into this.
>
> What happens in case of multiple simultaneously incoming requests?
> Does your database (and driver) allow enough parallel connections so
> that each request is processed correctly?
>
> DGS: I have the Glassfish database connections maximum pool size set to 1000. This seems to be enough. When I submitted this question, the system was crashing occasionally, but then I noticed that the pool size had inadvertently been reset to the default 32. This must have happened when I reinstalled Glassfish and then neglected to update pool size. It seems to be working now. No crashes in the last day.
>
> DGS: Thanks for taking the time to respond. Do you know of a way to identify the start and end of a user session?
>
> Regards
>
> Thorsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Daniel,
Apologies for top-posting, but I would highly recommend reading this:
https://blog.christopherschultz.net/2009/03/16/properly-handling-pooled-jdbc-connections/
-chris
On 8/1/25 3:33 PM, Daniel Schwartz wrote:
> Hello Thorsten,
>
> Please see my replies below, marked DGS.
>
> -----Original Message-----
> From: Thorsten Heit <he...@icloud.com.INVALID>
> Sent: Friday, August 1, 2025 5:32 AM
> To: users@tomcat.apache.org
> Subject: Re: How to access a REST service
>
> Hi,
>
>> Daniel,
>> You might take a look at java’s “ try with” construct
>
> DGS: Someone else recommended this. I will look into it. I see that an issue with my current code is that the database connection won't be closed if an error is thrown.
>
> This is an important step, indeed:
>
>>> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
>>> ---------------------------------------------------------------------
>>> ----- public class HolidaysRESTJSONResource {
>>>
>>> DataSource dataSource;
>>>
>>> public HolidaysRESTJSONResource() {
>>> dataSource = DataSourceSingleton.getInstance().dataSource;
>>> }
>>>
>>> @GET
>>> @Path("/countries")
>>> @Produces(MediaType.APPLICATION_JSON)
>>> public String getJsonCountries() {
>>> ...
>>> Connection connection;
>>> try {
>>> connection = dataSource.getConnection();
>>> TempDataStorage.countryList =
>>> GetCountryList.doIt(connection);
>>> connection.close();
>>> ...
>>> }
>
> A couple of questions:
>
> 1) How often is your class instantiated/created? Is it a singleton? A new one per each incoming request?
>
> DGS: It is created with every database query. For each user query there can be 1-3 database queries, and the same user can make an unlimited number of queries. I know it would be better if I could somehow identify a "user session" and only create one connection per session, but I don't know how to do this.
>
> 2) What happens in case of an exception in your try block? Looking at
> the above snipped the connection isn't closed.
>
> DGS: Yes, that's an issue, which I have noted in the foregoing. I'll change to the "try-with" approach.
>
>>> The constructor for HolidaysRESTJSONResource creates a DataSource by
>>> creating an instance of the following DataSourceSingleton class and
>>> retrieving the value of the DataSource instance variable. I borrowed
>>> this code from somewhere. It seems to work. The MySql database is
>>> called "holidays".
>
> 3) Have a look at the version of the database driver you're using. Is
> there perhaps a newer one? If yes, have a look at the release notes and
> check the changes. Perhaps there's a leak in the driver itself...?
>
> DGS: I'm using the latest MySQL 8 driver.
>
>>> Back in HolidaysRESTJSONResource, in the method getJsonCountries(),
>>> the DataSource object, called "dataSource", is used to create the
>>> connection object, and this is used in a method call
>>> GetCountryList.doIt() to retrieve a list of countries from the
>>> database. Then this connection object is closed. I think that this
>>> is all that is needed to prevent memory leaks. Is this correct? I do
>>> this for every such method call that accesses the database.
>
> AFAICT only in case of proper execution wrt to the code snippet
> presented. In case of an exception during the #doIt(...) call this won't
> happen (correctly) and can result in a memory leak (AFAIK).
>
> DGS: Good point. The doIt() method can throw an exception. I will look into this.
>
> What happens in case of multiple simultaneously incoming requests? Does
> your database (and driver) allow enough parallel connections so that
> each request is processed correctly?
>
> DGS: I have the Glassfish database connections maximum pool size set to 1000. This seems to be enough. When I submitted this question, the system was crashing occasionally, but then I noticed that the pool size had inadvertently been reset to the default 32. This must have happened when I reinstalled Glassfish and then neglected to update pool size. It seems to be working now. No crashes in the last day.
>
> DGS: Thanks for taking the time to respond. Do you know of a way to identify the start and end of a user session?
>
> Regards
>
> Thorsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Thorsten,
Please see my replies below, marked DGS.
-----Original Message-----
From: Thorsten Heit <he...@icloud.com.INVALID>
Sent: Friday, August 1, 2025 5:32 AM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Hi,
> Daniel,
> You might take a look at java’s “ try with” construct
DGS: Someone else recommended this. I will look into it. I see that an issue with my current code is that the database connection won't be closed if an error is thrown.
This is an important step, indeed:
>> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
>> ---------------------------------------------------------------------
>> ----- public class HolidaysRESTJSONResource {
>>
>> DataSource dataSource;
>>
>> public HolidaysRESTJSONResource() {
>> dataSource = DataSourceSingleton.getInstance().dataSource;
>> }
>>
>> @GET
>> @Path("/countries")
>> @Produces(MediaType.APPLICATION_JSON)
>> public String getJsonCountries() {
>> ...
>> Connection connection;
>> try {
>> connection = dataSource.getConnection();
>> TempDataStorage.countryList =
>> GetCountryList.doIt(connection);
>> connection.close();
>> ...
>> }
A couple of questions:
1) How often is your class instantiated/created? Is it a singleton? A new one per each incoming request?
DGS: It is created with every database query. For each user query there can be 1-3 database queries, and the same user can make an unlimited number of queries. I know it would be better if I could somehow identify a "user session" and only create one connection per session, but I don't know how to do this.
2) What happens in case of an exception in your try block? Looking at
the above snipped the connection isn't closed.
DGS: Yes, that's an issue, which I have noted in the foregoing. I'll change to the "try-with" approach.
>> The constructor for HolidaysRESTJSONResource creates a DataSource by
>> creating an instance of the following DataSourceSingleton class and
>> retrieving the value of the DataSource instance variable. I borrowed
>> this code from somewhere. It seems to work. The MySql database is
>> called "holidays".
3) Have a look at the version of the database driver you're using. Is
there perhaps a newer one? If yes, have a look at the release notes and
check the changes. Perhaps there's a leak in the driver itself...?
DGS: I'm using the latest MySQL 8 driver.
>> Back in HolidaysRESTJSONResource, in the method getJsonCountries(),
>> the DataSource object, called "dataSource", is used to create the
>> connection object, and this is used in a method call
>> GetCountryList.doIt() to retrieve a list of countries from the
>> database. Then this connection object is closed. I think that this
>> is all that is needed to prevent memory leaks. Is this correct? I do
>> this for every such method call that accesses the database.
AFAICT only in case of proper execution wrt to the code snippet
presented. In case of an exception during the #doIt(...) call this won't
happen (correctly) and can result in a memory leak (AFAIK).
DGS: Good point. The doIt() method can throw an exception. I will look into this.
What happens in case of multiple simultaneously incoming requests? Does
your database (and driver) allow enough parallel connections so that
each request is processed correctly?
DGS: I have the Glassfish database connections maximum pool size set to 1000. This seems to be enough. When I submitted this question, the system was crashing occasionally, but then I noticed that the pool size had inadvertently been reset to the default 32. This must have happened when I reinstalled Glassfish and then neglected to update pool size. It seems to be working now. No crashes in the last day.
DGS: Thanks for taking the time to respond. Do you know of a way to identify the start and end of a user session?
Regards
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello again, Thorsten,
You can ignore my query about identifying the start and end of user sessions. Upon further reflection, I realize that this can't be done within the webservice. My webservice is the backend for a website the uses Next.js, and I think that this is where the sessions are identified, using cookies or some such technique. I will look into this.
Dan
-----Original Message-----
From: Thorsten Heit <he...@icloud.com.INVALID>
Sent: Friday, August 1, 2025 5:32 AM
To: users@tomcat.apache.org
Subject: Re: How to access a REST service
Hi,
> Daniel,
> You might take a look at java’s “ try with” construct
This is an important step, indeed:
>> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
>> ---------------------------------------------------------------------
>> ----- public class HolidaysRESTJSONResource {
>>
>> DataSource dataSource;
>>
>> public HolidaysRESTJSONResource() {
>> dataSource = DataSourceSingleton.getInstance().dataSource;
>> }
>>
>> @GET
>> @Path("/countries")
>> @Produces(MediaType.APPLICATION_JSON)
>> public String getJsonCountries() {
>> ...
>> Connection connection;
>> try {
>> connection = dataSource.getConnection();
>> TempDataStorage.countryList =
>> GetCountryList.doIt(connection);
>> connection.close();
>> ...
>> }
A couple of questions:
1) How often is your class instantiated/created? Is it a singleton? A new one per each incoming request?
2) What happens in case of an exception in your try block? Looking at
the above snipped the connection isn't closed.
>> The constructor for HolidaysRESTJSONResource creates a DataSource by
>> creating an instance of the following DataSourceSingleton class and
>> retrieving the value of the DataSource instance variable. I borrowed
>> this code from somewhere. It seems to work. The MySql database is
>> called "holidays".
3) Have a look at the version of the database driver you're using. Is
there perhaps a newer one? If yes, have a look at the release notes and
check the changes. Perhaps there's a leak in the driver itself...?
>> Back in HolidaysRESTJSONResource, in the method getJsonCountries(),
>> the DataSource object, called "dataSource", is used to create the
>> connection object, and this is used in a method call
>> GetCountryList.doIt() to retrieve a list of countries from the
>> database. Then this connection object is closed. I think that this
>> is all that is needed to prevent memory leaks. Is this correct? I do
>> this for every such method call that accesses the database.
AFAICT only in case of proper execution wrt to the code snippet
presented. In case of an exception during the #doIt(...) call this won't
happen (correctly) and can result in a memory leak (AFAIK).
What happens in case of multiple simultaneously incoming requests? Does
your database (and driver) allow enough parallel connections so that
each request is processed correctly?
Regards
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to access a REST service
Posted by Thorsten Heit <he...@icloud.com.INVALID>.
Hi,
> Daniel,
> You might take a look at java’s “ try with” construct
This is an important step, indeed:
>> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
>> --------------------------------------------------------------------------
>> public class HolidaysRESTJSONResource {
>>
>> DataSource dataSource;
>>
>> public HolidaysRESTJSONResource() {
>> dataSource = DataSourceSingleton.getInstance().dataSource;
>> }
>>
>> @GET
>> @Path("/countries")
>> @Produces(MediaType.APPLICATION_JSON)
>> public String getJsonCountries() {
>> ...
>> Connection connection;
>> try {
>> connection = dataSource.getConnection();
>> TempDataStorage.countryList = GetCountryList.doIt(connection);
>> connection.close();
>> ...
>> }
A couple of questions:
1) How often is your class instantiated/created? Is it a singleton? A
new one per each incoming request?
2) What happens in case of an exception in your try block? Looking at
the above snipped the connection isn't closed.
>> The constructor for HolidaysRESTJSONResource creates a DataSource by
>> creating an instance of the following DataSourceSingleton class and
>> retrieving the value of the DataSource instance variable. I borrowed
>> this code from somewhere. It seems to work. The MySql database is
>> called "holidays".
3) Have a look at the version of the database driver you're using. Is
there perhaps a newer one? If yes, have a look at the release notes and
check the changes. Perhaps there's a leak in the driver itself...?
>> Back in HolidaysRESTJSONResource, in the method getJsonCountries(),
>> the DataSource object, called "dataSource", is used to create the
>> connection object, and this is used in a method call
>> GetCountryList.doIt() to retrieve a list of countries from the
>> database. Then this connection object is closed. I think that this
>> is all that is needed to prevent memory leaks. Is this correct? I do
>> this for every such method call that accesses the database.
AFAICT only in case of proper execution wrt to the code snippet
presented. In case of an exception during the #doIt(...) call this won't
happen (correctly) and can result in a memory leak (AFAIK).
What happens in case of multiple simultaneously incoming requests? Does
your database (and driver) allow enough parallel connections so that
each request is processed correctly?
Regards
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: How to access a REST service
Posted by Daniel Schwartz <da...@danielgschwartz.com>.
Hello Rob,
Thanks. I wrote this before I knew about the “try-with” feature, but will look into it. I see that an issue with my current code is that the connection won’t be closed if an error is thrown.
Best regards,
Dan
From: Rob Sargent <rs...@xmission.com>
Sent: Thursday, July 31, 2025 11:22 PM
To: Tomcat Users List <us...@tomcat.apache.org>
Cc: Tomcat Users List <us...@tomcat.apache.org>
Subject: Re: How to access a REST service
Daniel, You might take a look at java’s “ try with” construct The try-with-resources Statement (The Java™ Tutorials > Essential Java Classes > Exceptions) docs.oracle.com --------------------------------------------------------------------------------------------------------------
NkdkJdXPPEBannerStart
Be Careful With This Message
From (Rob Sargent <rs...@xmission.com>)<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f43cdb6b8a8a52fa3034cb686bdec16527bc6702454bf60bc53c293e94b791a875d6eef29456ccde42b0f1f2e37268fc23df4e1a4c20f59fbfd081ad91e2206beca270f4502ddce16efdf9c0027285e07a7ead6a0d71b2f7cc67a347c0cc24f535337c9f1799502fdd6fe0419af566980908394dacbaa83d51a09ff16e0358c73c1ae9661daf2f8d969452b484810e64edad60cae5b674bc26056eb22d41f2a4d1e4cdcc1124a1e67d2a3aa0ed3c5f949128180ed87e8b5f6c8a8fc40cb5925515b14d3fa45c2c3198a8fa11c0ff352ea71fde364d47d4aff649892e45b646ae1d29f30e4a6f2352b>
Learn More<https://godaddy1.cloud-protect.net/email-details/?k=k1&payload=53616c7465645f5f43cdb6b8a8a52fa3034cb686bdec16527bc6702454bf60bc53c293e94b791a875d6eef29456ccde42b0f1f2e37268fc23df4e1a4c20f59fbfd081ad91e2206beca270f4502ddce16efdf9c0027285e07a7ead6a0d71b2f7cc67a347c0cc24f535337c9f1799502fdd6fe0419af566980908394dacbaa83d51a09ff16e0358c73c1ae9661daf2f8d969452b484810e64edad60cae5b674bc26056eb22d41f2a4d1e4cdcc1124a1e67d2a3aa0ed3c5f949128180ed87e8b5f6c8a8fc40cb5925515b14d3fa45c2c3198a8fa11c0ff352ea71fde364d47d4aff649892e45b646ae1d29f30e4a6f2352b>
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
Daniel,
You might take a look at java’s “ try with” construct
The try-with-resources Statement (The Java™ Tutorials > Essential Java Classes > Exceptions)<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oracle.com_javase_tutorial_essential_exceptions_tryResourceClose.html&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=-hacTP6KVKuoWm9UAmO35pU3860b8Zy2BhScJ-KwihYqxah3UKba5boSuGVBsRx0&s=mNhXT4swanwGi8JqA0d0saa_QrNH6RP9EBEnFjz-kE0&e=>
docs.oracle.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oracle.com_javase_tutorial_essential_exceptions_tryResourceClose.html&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=-hacTP6KVKuoWm9UAmO35pU3860b8Zy2BhScJ-KwihYqxah3UKba5boSuGVBsRx0&s=mNhXT4swanwGi8JqA0d0saa_QrNH6RP9EBEnFjz-kE0&e=>
[favicon.ico]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oracle.com_javase_tutorial_essential_exceptions_tryResourceClose.html&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AbCalLxzopgQUG9LLcXdB80OM-GtDfItX76RMxNYqz4&m=-hacTP6KVKuoWm9UAmO35pU3860b8Zy2BhScJ-KwihYqxah3UKba5boSuGVBsRx0&s=mNhXT4swanwGi8JqA0d0saa_QrNH6RP9EBEnFjz-kE0&e=>
--------------------------------------------------------------------------------------------------------------
Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
--------------------------------------------------------------------------
public class HolidaysRESTJSONResource {
DataSource dataSource;
public HolidaysRESTJSONResource() {
dataSource = DataSourceSingleton.getInstance().dataSource;
}
@GET
@Path("/countries")
@Produces(MediaType.APPLICATION_JSON)
public String getJsonCountries() {
...
Connection connection;
try {
connection = dataSource.getConnection();
TempDataStorage.countryList = GetCountryList.doIt(connection);
connection.close();
...
}
--------------------------------------------------------------------------
The constructor for HolidaysRESTJSONResource creates a DataSource by creating an instance of the following DataSourceSingleton class and retrieving the value of the DataSource instance variable. I borrowed this code from somewhere. It seems to work. The MySql database is called "holidays".
--------------------------------------------------------------------------
public class DataSourceSingleton {
private static DataSourceSingleton instance = null;
public DataSource dataSource = null;
private DataSourceSingleton() {
try {
InitialContext ctx = new InitialContext();
dataSource = (DataSource) ctx.lookup("jdbc/holidays");
} catch (NamingException e) {
System.out.println(e);
}
}
public static DataSourceSingleton getInstance() {
if (instance == null) {
instance = new DataSourceSingleton();
}
return instance;
}
}
--------------------------------------------------------------------------
Back in HolidaysRESTJSONResource, in the method getJsonCountries(), the DataSource object, called "dataSource", is used to create the connection object, and this is used in a method call GetCountryList.doIt() to retrieve a list of countries from the database. Then this connection object is closed. I think that this is all that is needed to prevent memory leaks. Is this correct? I do this for every such method call that accesses the database.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: users-help@tomcat.apache.org<ma...@tomcat.apache.org>
Re: How to access a REST service
Posted by Rob Sargent <rs...@xmission.com>.
Daniel,
You might take a look at java’s “ try with” construct
[| [The try-with-resources Statement (The Java™ Tutorials > Essential Java
Classes >
Exceptions)](https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html)[docs.oracle.com](https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html)|
[](https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html)
---|---
](https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html)
>
> \--------------------------------------------------------------------------------------------------------------
> Here is a fragment of the code from the file HolidaysRESTJSONResource.jar.
> \--------------------------------------------------------------------------
> public class HolidaysRESTJSONResource {
>
> DataSource dataSource;
>
> public HolidaysRESTJSONResource() {
> dataSource = DataSourceSingleton.getInstance().dataSource;
> }
>
> @GET
> @Path("/countries")
> @Produces(MediaType.APPLICATION_JSON)
> public String getJsonCountries() {
> ...
> Connection connection;
> try {
> connection = dataSource.getConnection();
> TempDataStorage.countryList = GetCountryList.doIt(connection);
> connection.close();
> ...
> }
> \--------------------------------------------------------------------------
>
> The constructor for HolidaysRESTJSONResource creates a DataSource by
> creating an instance of the following DataSourceSingleton class and
> retrieving the value of the DataSource instance variable. I borrowed this
> code from somewhere. It seems to work. The MySql database is called
> "holidays".
>
> \--------------------------------------------------------------------------
> public class DataSourceSingleton {
>
> private static DataSourceSingleton instance = null;
> public DataSource dataSource = null;
>
> private DataSourceSingleton() {
> try {
> InitialContext ctx = new InitialContext();
> dataSource = (DataSource) ctx.lookup("jdbc/holidays");
> } catch (NamingException e) {
> System.out.println(e);
> }
> }
>
> public static DataSourceSingleton getInstance() {
> if (instance == null) {
> instance = new DataSourceSingleton();
> }
> return instance;
> }
> }
> \--------------------------------------------------------------------------
>
> Back in HolidaysRESTJSONResource, in the method getJsonCountries(), the
> DataSource object, called "dataSource", is used to create the connection
> object, and this is used in a method call GetCountryList.doIt() to retrieve
> a list of countries from the database. Then this connection object is
> closed. I think that this is all that is needed to prevent memory leaks.
> Is this correct? I do this for every such method call that accesses the
> database.
> \---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> \---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>