Dan,
Like Robert, I am confused.
Read on for more replies...
On 8/14/25 12:55 AM, Daniel Schwartz wrote:
From: Chuck Caldarale <n82...@gmail.com>
Sent: Wednesday, August 13, 2025 10:29 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: [EXTERNAL EMAIL] How to access a REST service
-----Original Message-----
From: Christopher Schultz
<ch...@christopherschultz.net<mailto:ch...@christopherschultz.net>>
Sent: Wednesday, August 13, 2025 2:21 PM
To: users@tomcat.apache.org<mailto: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
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
