If you close it then this particular instance will become unusable...

I'll need to ask Dan if implementing AutoCloseable or Closeable can help with closing such clients that are created in Spring contexts, but you can always close it if you have Spring calling a destroy method in your bean that holds WebClient.

if you do not close it at all explicitly then I guess the underlying connection/socket will stay around until HttpConduit will eventually be GCed and the underlying connection recycled...

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/

Reply via email to