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