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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
