> On Aug 5, 2015, at 12:04 PM, Jose María Zaragoza <[email protected]> wrote: > > > I'm trying to understand how is the high-level behaviour ( client side, so > far ) > Please, let me know if I'm wrong ( I'm sure about that ) > > 1) I guess that a WebClient instance uses a new HttpURLConnection per > thread/IO operation ( and executes openConnection() every time ) > 2) I guess that HttpURLConnection can reuses a TCP connection
Correct. > 3) I guess that HttpConduit manages HttpURLConnection life-cycle and I > guess that, if TCP connection is closed *by server/firewall* ( sends > FIN packet ), it closes underlying TCP connection ( I don't know how > either HttpURLConnection.disconnect() or instream.close() Well, not really. We call instream.close() and that’s about it. The HttpURLConnection stuff built into the JDK takes care of all the TCP related things as well as the keep-alive stuff and such. We don’t even have access to the TCP socket stuff to do much with it. > My questions are about what happens if a firewall closes a TCP > connection , established between my WebClient and a server > My client should close underlying TCP connection but that is managed > by HttpConduit , right ? No. By the internals of the HttpURLConnection stuff in the JDK. When we call the “openConnection()” method of the HttpURLConnection, internally it looks at the information we have set on the HttpURLConnection (host, port, etc..) and grabs a “com.sun.*.Something” from it’s internal connection pool and the HttpURLConnection then uses whatever that is for the communication. It’s not something we really have any control over. Dan > > Maybe I'm wrong at all , sorry > > Regards > > > >> >> Cheers, Sergey >> >> On 05/08/15 13:33, Jose María Zaragoza wrote: >>> >>> 2015-08-05 12:08 GMT+02:00 Sergey Beryozkin <[email protected]>: >>>> >>>> Hi >>>> On 04/08/15 20:26, Jose María Zaragoza wrote: >>>>> >>>>> >>>>> 2015-08-02 23:12 GMT+02:00 Sergey Beryozkin <[email protected]>: >>>>>> >>>>>> >>>>>> Hi >>>>>> Can you cast a proxy to WebClient (via its utility method >>>>>> WebClient.client()) and close it, and also enable the auto-closure of >>>>>> the >>>>>> Response ? >>>>>> Sergey >>>>> >>>>> >>>>> >>>>> Hi >>>>> >>>>> I'm using CXF 2.7.8 to invoke REST services by WebClient API & JAX-RS >>>>> Client Proxy-based API >>>>> Is required to call explicitly close() method in WebClient ? >>>> >>>> >>>> Calling close() helps with the proactive conduit (HTTP client state) >>>> cleanup, it is a good idea to call close() >>>>> >>>>> >>>>> Anyway I would like to keep alive some TCP connection ( default value >>>>> ) . I wonder in which cases i should set auto-closure or call >>>>> explicitly close() >>>>> >>>> The auto-closure can only be applied to JAX-RS Response streams, in cases >>>> where you have a code like >>>> Book book = proxy.getBook(); >>>> or >>>> Book book = webClient.get().readEntity(Book.class); >>> >>> >>> Thanks >>> >>> My code looks like >>> >>> WebClient client; >>> >>> try >>> { >>> javax.ws.rs.core.Response r = this.client.path("/users/{phone}/id", >>> phone).get(); >>> IdGETResponseType idGETResponseType = (IdGETResponseType) >>> r.readEntity(IdGETResponseType.class); >>> ... >>> .... >>> } >>> finally >>> { >>> // Clean >>> if (client != null) >>> client.reset(); >>> } >>> >>> Should I perform a explicit close on WelcClient object ? What happens >>> if I dont ? >>> >>> >>> WebClient is injected by Spring container >>> >>> <jaxrs:client id="client" >>> address="${api.endpoint}" >>> serviceClass="org.apache.cxf.jaxrs.client.WebClient" >>> threadSafe="true"> >>> <jaxrs:headers> >>> <entry key="Content-Type" >>> value="application/json;charset=UTF-8"/> >>> <entry key="Accept" value="application/json"/> >>> </jaxrs:headers> >>> <jaxrs:providers> >>> <ref bean="jsonProvider"/> >>> </jaxrs:providers> >>> >>> </jaxrs:client> >>> >>> Regards >>> >>>> >>>> we've had side-effects with the Response stream auto-closures in cases >>>> like >>>> >>>> Document domDoc = webClient.get().readEntity(Document.class); >>>> >>>> WebClient was also auto-closed in 3.1.1 which was reverted in 3.2.2 >>>> because >>>> when WebClient is copied and one of these clients gets out of scope then >>>> its >>>> (shared) http conduit gets closed and the other client gets broken. I >>>> might >>>> revisit it and make sure the conduit is cloned in such cases, but not >>>> right >>>> now... >>>>> >>>>> >>>>> I'm already calling reset() method for cleaning thread-local info ( I >>>>> guess ) >>>> >>>> >>>> if you intend to share the client between multiple threads then it should >>>> be >>>> up to Spring/etc to close it when the context goes out of scope >>>> >>>> Cheers, Sergey >>>> >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> >>>>>> >>>>>> On 31/07/15 02:59, Xiaobin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> I am using CXF 2.7.5. I have an application using >>>>>>> JAXRSClientFactoryBean >>>>>>> to >>>>>>> generate proxy, and use following code to close client when it is >>>>>>> done: >>>>>>> >>>>>>> ClientConfiguration config = WebClient.getConfig(root); >>>>>>> HTTPConduit conduit = config.getHttpConduit(); >>>>>>> if (conduit == null) { >>>>>>> throw new IllegalArgumentException(); >>>>>>> } >>>>>>> conduit.close(); >>>>>>> >>>>>>> As time goes on, I noticed that there are many connections shown by >>>>>>> netstat >>>>>>> in CLOSE_WAIT state. >>>>>>> >>>>>>> I understand that because of CXF-5144, it won't be able to re-use >>>>>>> connections. But besides this, is there anything I can do with those >>>>>>> CLOSE_WAIT connections ? Are these going to time out eventually or ? >>>>>>> >>>>>>> Also, I am wondering if setting ConnectionType.CLOSE would help ? >>>>>>> >>>>>>> Look forward to your suggestions! Thanks in advance. >>>>>>> >>>>>>> >>>>>>> -Xiaobin >>>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Sergey Beryozkin >>>> >>>> Talend Community Coders >>>> http://coders.talend.com/ >> >> >> >> -- >> Sergey Beryozkin >> >> Talend Community Coders >> http://coders.talend.com/ -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
