Btw, Hantsy, this is not helpful to this thread and only introduces more things to learn that aren't part of the problem the OP is trying to solve.
On Mon, Aug 18, 2025, 22:44 hantsy bai <han...@gmail.com> wrote: > When using Glassfish you can define your own DataSource > via @DataSourceDefinition, and inject it via @Resource annotation, which is > supported since Java EE 7. > > For example, > > @DataSourceDefinition(name="jndiname here", .....) > @ApplicaitonScoped > class DatabaseConfig{} > > use it like this, > @Resource(lookup="jndi name") DataSource ds > > More simply, since Java EE 7, default resources are available for > DataSource, JMS etc. > > You can inject the default DataSource directly via > > @Resource DataSource datasource > > --- > > Regards, > > *Hantsy Bai* > > Self-employed consultant, fullstack developer, agile coach, > freelancer/remote worker > > GitHub: https://github.com/hantsy > > Twitter: https://twitter.com/@hantsy > Medium: https://medium.com/@hantsy > > > On Tue, Aug 19, 2025 at 10:23 AM Daniel Schwartz <d...@danielgschwartz.com> > wrote: > > > Everyone, > > > > I wasn't resisting using the try-with-resources construct, only when I > > tried to do this, I was getting compiler errors. But I evidently wasn't > > doing it right, because I tried it again and this time it worked. > > > > Following is the new code for getting the list of countries. It uses > this > > construct and in addition has an extra catch clause for any kind of > > exception. I have done this in all six places where a connection is > being > > created. > > > > I restarted Glassfish earlier today and dropped in the new .war file. It > > has been running for 6-8 hours now. The log files show no evidence of > any > > exceptions being thrown. The current contents of the JDBC monitor page > are > > copied below. I don't know how to interpret most of this, but I do note > > that the number of connections released equals the number acquired. > Also, > > I have set the Connection Leak Timeout to be 10 seconds, and the > > NumPotentialConnLeak is still at 0. > > > > In addition, I did some further experimenting with the pool size, and now > > I find that if I set the minimum back to 8 and the maximum to 32, which > are > > the defaults, the system keeps running and doesn't output that "can't > > allocate more connections" message. For me this is very puzzling. Did > my > > code changes have anything to do with this? > > > > Anyway, my interpretation of all this is as before, that there are no > > memory leaks. Is this correct? > > > > I'm trying to upgrade to the current version of Glassfish, but haven't > > gotten this working yet. > > > > Dan > > > > > > > ----------------------------------------------------------------------------- > > @Path("holidaysandevents") > > public class HolidaysRESTJSONResource { > > > > @Context > > private UriInfo context; > > > > DataSource dataSource; > > > > public HolidaysRESTJSONResource() { > > dataSource = DataSourceSingleton.getInstance().dataSource; > > } > > > > @GET > > @Path("/countries") > > @Produces(MediaType.APPLICATION_JSON) > > public String getJsonCountries() { > > if (TempDataStorage.countryList == null) { > > // Connection connection = null; > > try (Connection connection = dataSource.getConnection()){ > > // connection = dataSource.getConnection(); > > TempDataStorage.countryList = > > GetCountryList.doIt(connection); > > } catch (SQLException e) { > > System.out.println("Sql Exception" + e.getStackTrace()); > > } catch (Exception e) { > > System.out.println("Other Exception" + > e.getStackTrace()); > > } > > > > //finally { > > // if (connection != null) { > > // try { > > // connection.close(); > > // } catch (SQLException e) { > > // System.out.println(e.getStackTrace()); > > // } > > // } > > // } > > } > > StringListWrapper listWrapper = new StringListWrapper(); > > listWrapper.setTheList(TempDataStorage.countryList); > > return new Gson().toJson(listWrapper); > > } > > > > > --------------------------------------------------------------------------------- > > Resource Monitoring > > Click Configure Monitoring and enable monitoring for a component or > > service by selecting either LOW or HIGH. See the Online Help for more > > information. > > > > Instance Name: > > server > > > > Resource : > > HolidaysConnectionPool > > Application : > > Monitor (14 Statistics) > > Collapse Group JDBC Connection Pool Statistics : HolidaysConnectionPool > > > > NumConnCreated 20 count Aug 18, 2025 5:47:56 PM Aug 19, 2025 > > 12:37:57 AM -- The number of physical connections that were > > created since the last reset. > > NumConnFree 1count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM > > High Water Mark: 3 count > > Low Water Mark: 0 count > > The total number of free connections in the pool as of the last sampling. > > NumConnReleased 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025 > > 1:48:33 AM -- Number of logical connections released to the pool. > > NumPotentialConnLeak 0 count Aug 18, 2025 5:47:56 PM -- -- > > Number of potential connection leaks > > NumConnFailedValidation 0 count Aug 18, 2025 5:47:56 PM -- -- > > The total number of connections in the connection pool that failed > > validation from the start time until the last sample time. > > ConnRequestWaitTime 0millisecond Aug 18, 2025 5:47:56 PM Aug 19, > > 2025 1:48:33 AM High Water Mark: 921 millisecond > > Low Water Mark: 0 millisecond > > The longest and shortest wait times of connection requests. The current > > value indicates the wait time of the last request that was serviced by > the > > pool. > > NumConnAcquired 325 count Aug 18, 2025 5:47:56 PM Aug 19, 2025 > > 1:48:33 AM -- Number of logical connections acquired from the pool. > > AverageConnWaitTime 12 millisecond Aug 18, 2025 5:47:56 PM Aug 19, > > 2025 1:49:00 AM -- Average wait-time-duration per successful > > connection request > > NumConnDestroyed 19 count Aug 18, 2025 5:47:56 PM Aug 19, > > 2025 12:37:57 AM -- Number of physical connections that were > > destroyed since the last reset. > > NumConnSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM -- > > -- Number of connections succesfully matched > > NumConnNotSuccessfullyMatched 0 count Aug 18, 2025 5:47:56 PM -- > > -- Number of connections rejected during matching > > NumConnUsed 0count Aug 18, 2025 5:47:56 PM Aug 19, 2025 1:48:33 AM > > High Water Mark: 2 count > > Low Water Mark: 0 count > > Provides connection usage statistics. The total number of connections > that > > are currently being used, as well as information about the maximum number > > of connections that were used (the high water mark). > > WaitQueueLength 0 count Aug 18, 2025 5:47:56 PM -- -- Number of > > connection requests in the queue waiting to be serviced. > > NumConnTimedOut 0 count Aug 18, 2025 5:47:56 PM -- -- The total > > number of connections in the pool that timed out between the start time > and > > the last sample time. > > > > -----Original Message----- > > From: Robert Turner <rtur...@e-djuster.ca.INVALID> > > Sent: Monday, August 18, 2025 11:13 AM > > To: Tomcat Users List <users@tomcat.apache.org> > > Subject: Re: [EXTERNAL EMAIL] How to access a REST service > > > > For instance, what happens when the year parameter for the "calender" > > request is not a number? > > Or if parameters are missing? > > Have you tested these situations? > > > > On Mon, Aug 18, 2025 at 10:52 AM Robert Turner <rtur...@e-djuster.ca> > > wrote: > > > > > Daniel, > > > > > > You have a leak - this we are certain of. You just don't yet know what > > > causes it (it's clearly not a "standard use case" and the robots are > > > likely triggering it). > > > > > > If I have my bets it is an unhandled unchecked exception (I'd even > > > guess that it is likely a NumberFormatException) while processing one > > > of your operations. Since you are reluctant to move your code to > > > "try-with-resources" handling of the resource objects (which would > > > make the code easier to read and avoid this problem), you will > > > continue to see the problem unless you ensure that you are catching all > > exceptions (e.g. > > > Throwable) (which is a bad practice in general). > > > > > > The 388 connection cound is the existing leaked connections from > > > previous operations since you last started the Glassfish server and > > > pool. I did suggest you restart Glassfish after adjusting that > > > parameter to reset the numbers and the systems. > > > > > > From my testing, I am very confident that the different versions will > > > not behave differently in the context of your application. > > > > > > Please have some confidence that we do know what we are talking about. > > > Your problem is common and not unique. > > > > > > If I get some time, and with your permission, I might try to look at > > > your server operations and see if I can trigger it for you... but if > > > you share the code for all the operations (no need to share the DB > > > queries, just the Java code), I bet we can find it quickly. However, > > > us solving it for you avoids you benefiting from the learning > experience. > > > > > > Robert > > > > > > > > > On Mon, Aug 18, 2025 at 10:44 AM Daniel Schwartz > > > <d...@danielgschwartz.com> > > > wrote: > > > > > >> Chris, > > >> > > >> I thought it was you. I too have a job and family, and this is only > > >> a side project, so my time also is limited. > > >> > > >> Anyway, I'm wondering if there really is a problem, or whether this > > >> is just normal Glassfish behavior. Yesterday I changed the Glassfish > > >> settings so that leak monitoring is activated, and today I got: > > >> > > >> NumPotentialConnLeak 0 count Aug 8, 2025 3:18:57 PM -- -- > > >> Number of potential connection leaks > > >> > > >> Also, this value: > > >> > > >> NumConnUsed 388count Aug 4, 2025 2:47:24 AM Aug 18, 2025 > > >> 2:34:54 PM High Water Mark: 390 count Low Water Mark: 0 count > > >> Provides connection usage statistics. The total number of connections > > >> that are currently being used, as well as information about the > > >> maximum number of connections that were used (the high water mark). > > >> > > >> Has remained unchanged at 388. > > >> > > >> There has been suspicion that my system has a memory leak, but all > > >> indications are that this is not happening. > > >> > > >> I'm currently trying to upgrade to the current version of Glassfish > > >> to see if this behaves differently, but haven't gotten it working yet. > > >> > > >> Dan > > >> > > >> > > >> -----Original Message----- > > >> From: Christopher Schultz <ch...@christopherschultz.net> > > >> Sent: Monday, August 18, 2025 10:29 AM > > >> To: users@tomcat.apache.org > > >> Subject: Re: [EXTERNAL EMAIL] How to access a REST service > > >> > > >> Daniel, > > >> > > >> On 8/16/25 10:57 PM, Daniel Schwartz wrote: > > >> > There was a Chris too, but I think he made his recommendation and > > >> > left. > > >> I'm still here, but I do have a job and a family. Rob, Robert and > > >> Chuck were making plenty of noise so I decided to reduce the clutter. > > >> > > >> > I'm coming to think that his advice was the best, namely, to just > > >> > live with the current situation as long as it is working. > > >> I gave no such advice. I think you should chase this down until you > > >> understand the cause and have it fixed. > > >> > > >> -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 > > >