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 PMTo: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... 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-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
OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
