You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@tomcat.apache.org by Niranjan Rao <nr...@paymentus.com> on 2025/08/05 16:54:06 UTC

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 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 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.