Hi Chuck, See my reply below.
Dan 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 > On 2025 Aug 13, at 20:27, Daniel Schwartz > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > Chris, > > > See my reply to your comment. > > Dan > -----Original Message----- > > From: Christopher Schultz > <ch...@christopherschultz.net<mailto:ch...@christopherschultz.net>> NkdkJdXPPEBannerStart Be Careful With This Message From (Chuck Caldarale <n82...@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 > <d...@danielgschwartz.com<mailto:d...@danielgschwartz.com>> wrote: > > Chris, > > See my reply to your comment. > > Dan > -----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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> For additional commands, e-mail: users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>
