[resteasy] Re: RestEasy 4.7.9 - java.lang.IllegalStateException: Connection pool shutdown

Hi James, "*Do you use a CDI container by chance?*" No, I don't. "*However, the client should not be closed if it's going to be used again....*" Even if we create a new client instance in every single run of the deployed war application (a jsp+java based app served by Tomcat)? [that war file is using our rest client what is using RestEasy as a dependency] I believe it should not kill the whole underlying connection pool for Tomcat. This is not happening with the current version we are using (v3.0.18). We can create and close as many client instances as we want as long as we always keep in mind if we have closed the previous one or haven't. I know it is inefficient and expensive, but it was not written by me and that's what I wanted to fix originally. And that was what revealed the differences between v3.0.18 and v4.x.x. Or maybe the mechanism used by v3.0.18 is the faulty one? (so it is not OK that v3.0.18 is not killing the pool after a single client.close()) Best regards, Zsolt Melich James Perkins <jperkins(a)redhat.com&gt; ezt írta (időpont: 2023. aug. 9., Sze, 17:44): > > > On Wed, Aug 9, 2023 at 1:53 AM Zsolt Melich <stocek86(a)gmail.com&gt; wrote: > >> Hi James, >> >> Thanks for the info! >> >> Meanwhile, I've modified one of our test app (that calls all the APIs we >> can call in an IVR call) to check if the same happens. I can say, more or >> less, the same happens. >> >> If I close the client somewhere between two API calls, I'm not able to >> make any more successful API calls in the same run of the tool. (even if I >> create a completely new client instance for the next API call) >> > > If the client is closed, it definitely cannot be used anymore. Do you use > a CDI container by chance? There could be a different way to manage the > client resource is why I ask. > > >> The only difference I experienced is that I don't need to restart >> anything (~Tomcat service) to make it work again in the next run. It works >> again until the temporary line closes the client. >> It looks like you are right about the pool closure in your last sentence. >> >> The official documentation of this RestEasy release says that the socket >> closure is done in ApacheHttpClient43.finalize() under the hood, but I'm >> not sure if I can really trust in that. >> The affected IVR serves 20.000+ calls a day. A memory leak would not be >> good. >> > > That should only happen if the client wasn't closed by other means. I > wouldn't rely on the finalizer either TBH. Client management can > potentially be tricky. However, the client should not be closed if it's > going to be used again. In Jakarta REST 3.1, for Jakarta EE 10, the > jakarta.ws.rs.client.Client extends AutoCloseable so it can be used in > try-with-resources. There is definitely some overhead in creating a client, > but it's likely not that significant. However, sharing a client should work > fine as well. > > >> >> Maybe the same tests should be done with release 5.x.x. >> >> Regards, >> Zsolt Melich >> >> James Perkins <jperkins(a)redhat.com&gt; ezt írta (időpont: 2023. aug. 7., >> H, 16:59): >> >>> Hello, >>> Just an FYI. The 4.7 version is no longer maintained. If you're still >>> using Jakarta EE 8, you'd want to use the 5.0 versions. >>> >>> On Mon, Aug 7, 2023 at 5:01 AM Zsolt Melich <stocek86(a)gmail.com&gt; wrote: >>> >>>> Hi all! >>>> >>>> I'm facing with the error message in the subject since I had to switch >>>> from RestEasy v3.0.18 (I know, quite old) to v4.7.9. >>>> We have a great, complex IVR application (written in Java 8), what is >>>> using RestEasy for the WS client we have for the API calls throughout a >>>> calls. The application is deployed to a Tomcat 9 application server. >>>> >>>> The current version of the client creates a RestEasy client instance >>>> for each API invocation, then close the response and the client (with the >>>> close() method). This is quite expensive, so I planned to change this when >>>> I switch to v4.7.9. >>>> In the new version I create the client at the beginning, closing the >>>> response (to let the resource back to the pool) after each invocation, and >>>> shut down the client with close() at the very end (only once). >>>> We create the PoolingHttpClientConnectionManager instance, the engine >>>> instance (ApacheHttpClient43Engine) and the httpClient instance manually, >>>> then we pass the engine to the ClientBuilder to create the client instance. >>>> >>>> The problem is that I can make only one IVR test call without any >>>> issue. At the very end of the first call, the connection is being closed. >>>> In the second call I got the exception from the subject for the very first >>>> API call. >>>> I checked the logs, traced my test calls and everything is looking >>>> fine (the app does not close the connection before the invocation). After a >>>> Tomcat restart I'm able to do a successful test call again, but only for >>>> one time! After a successful call, I'm getting the same exception in the >>>> next call... >>>> >>>> Does the close() method of the client instance destroy the whole >>>> connection pool for later calls as well when I close the connection at the >>>> end of the first call? Is this normal? >>>> We didn't have this issue with v.3.0.18. >>>> >>> >>> It shouldn't close the pool, no. If you close the client and attempt to >>> reuse the same connection pool, that would likely not work. I believe >>> internally when you close the client, the connection pool is also closed. >>> >>> >>>> >>>> P.S. : I know I haven't provided any exact code yet, but I try to >>>> clarify and understand the mechanics first. >>>> >>>> Thanks for the helping replies in advance! >>>> _______________________________________________ >>>> resteasy mailing list -- resteasy(a)lists.jboss.org >>>> To unsubscribe send an email to resteasy-leave(a)lists.jboss.org >>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>> List Archives: >>>> https://lists.jboss.org/archives/list/resteasy@lists.jboss.org/message/WA... >>>> >>> >>> >>> -- >>> James R. Perkins >>> JBoss by Red Hat >>> >> > > -- > James R. Perkins > JBoss by Red Hat >