[
https://issues.apache.org/jira/browse/CXF-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926582#comment-15926582
]
Sergey Beryozkin commented on CXF-7277:
---------------------------------------
Yes by default the proxy state is available after the call - can be useful if
the response headers can be checked. I agree in most cases this may not be
needed by auto-resetting by default is problematic anyway as it will break the
code dealing with the response input stream directly, or other types like DOM
ones, etc.
You can always do
{code:java}
try {
proxy.invoke();
} finally {
WebClient.getClient(proxy).reset();
}
{code}
but I did update the code a bit to check if ClientConfiguration has a
'resetResponseStateImmediately' set to true - you can enable it in the setter
where the proxy is injected in, WebClient.getConfig(proxy). I think this is as
far as we should go given the code above can be done right now too...
thanks
> Make ClientProxyImpl reset client state after a call
> ----------------------------------------------------
>
> Key: CXF-7277
> URL: https://issues.apache.org/jira/browse/CXF-7277
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Affects Versions: 3.1.10
> Reporter: Vladimir Kulev
> Priority: Minor
>
> It would be nice to call {{getState().reset()}} in
> {{ClientProxyImpl.invoke()}} final block. My use case is
> {{JAXRSClientFactoryBean}} in thread-local configuration, which combined with
> big thread pool can cause a kind of memory leak. I never need to access the
> state after I get result from the proxy, but if you think somebody may need,
> let's make it configurable.
> There is "timeToKeepState" of course, but it's far from ideal because
> response objects still cannot be garbage collected immediately and there's
> small added overhead of having all that extra threads.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
