> On 2025 Aug 14, at 23:49, Daniel Schwartz <[email protected]> wrote: > > I will work on answers your various questions. However, I decided to first > explore the comment (by someone) that a servlet can "swallow" an exception, > which I take to mean that it can throw an exception without reporting the > exception or terminating the program. > > I have this system running on a PC identified as localhost. The test URL is: > > http://localhost:8080/HolidaysRESTJSON-1.0-SNAPSHOT/webresources/holidaysandevents/countries > > > I ran two tests. First, I wrote in code to throw an SQL exception, which did > get caught in my catch clause, which printed out some messages and a stack > trace. The web browser showed the retrieved list of countries, but nothing > else. > > Second, I replaced the line that throws the SQL exception by one that tries > to do a division by zero. This of course was not caught, but it did print > out a stack trace and reported a 505 error in the browser, and the program > did terminate.
What do you mean by “the program did terminate”? Did GlassFish actually exit? GlassFish is the actual “program" here - your application is simply a web service running inside the GlassFish container. Perhaps you meant that a response was returned to the client. > I take this to mean that exceptions are not being "swallowed" by my program. Correct, but the exception actually is being swallowed by GlassFish, after logging its occurrence and returning a 500 (not 505) response to the client. The thread that encountered the exception returns to the GlassFish thread pool and does not exit. > When/if an exception occurs, there is definitely some indication of this, > either in the server.log or the browser. Because I have never seen either of > these actions, I'm fairly sure that my program is not throwing exceptions and > all database connections are being closed immediately after they are used, > i.e., no memory leaks in this respect. Resource leaks can also occur by not always closing Statement, PreparedStatement, or ResultSet objects (as mentioned way back in this thread), at least some of which your application must be using. Each such resource is associated with a DB connection, but whether or not failing to explicitly close them can cause an active connection to be unavailable for reuse depends on the implementation details of the JDBC driver and the connection pool. At least in the past, sometimes a garbage collection was required to reset connections to the point they could be recycled. Another thing to check for is retaining references to the connection or subsidiary resources in class or instance variables in your code. This seems unlikely in a web service, but should be looked at just in case. > [2025-08-14T23:45:29.328-0400] [glassfish 4.1] [WARNING] [] > [javax.enterprise.web] [tid: _ThreadID=36 _ThreadName=http-listener-1(1)] > [timeMillis: 1755229529328] [levelValue: 900] [[ > > StandardWrapperValve[com.worldholidaysandevents.restjsonwebservice.ApplicationConfig]: > Servlet.service() for servlet > com.worldholidaysandevents.restjsonwebservice.ApplicationConfig threw > exception > java.lang.ArithmeticException: / by zero > at > com.worldholidaysandevents.restjsonwebservice.HolidaysRESTJSONResource.getJsonCountries(HolidaysRESTJSONResource.java:53) Note the use of “servlet" in the above exception message, demonstrating that GlassFish does indeed encapsulate web services inside servlets. Also, the exception is only logged at the warning, not error, level. If only error logging is enabled, you would never see such a message in the logs. - Chuck --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
