[
https://issues.jboss.org/browse/JBWS-3847?page=com.atlassian.jira.plugin....
]
Alessio Soldano commented on JBWS-3847:
---------------------------------------
As noted in a comment above, this is solved by CXF-6038 fix and hence requires moving to
Apache CXF 3.0.3. However, I've optimized the HandlerChainSortInterceptor so that it
reduces the calls to setHandlerChain to the actual minimum required, effectively
mitigating the leak; see JBWS-3848 for more details.
Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor
----------------------------------------------------------------
Key: JBWS-3847
URL:
https://issues.jboss.org/browse/JBWS-3847
Project: JBoss Web Services
Issue Type: Bug
Components: jbossws-cxf
Affects Versions: jbossws-cxf-4.3
Reporter: Tadayoshi Sato
Fix For: jbossws-cxf-5.0
{{HandlerChainSortInterceptor.handleMessage(Message)}} sorts and sets JAX-WS handlers
every time it handles a SOAP message:
{code:java}
public void handleMessage(Message message) throws Fault
{
if (binding != null) {
@SuppressWarnings("rawtypes")
List<Handler> list = binding.getHandlerChain();
if (list != null && !list.isEmpty()) {
Collections.sort(list, comparator);
binding.setHandlerChain(list);
}
}
}
{code}
However, inside the {{org.apache.cxf.jaxws.binding.AbstractBindingImpl}} and
{{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} implementations the handler chain is
not reset every time but piled up with interceptors, which leads to subtle but indefinite
memory leak in JBoss WS CXF client.
Furthermore, {{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} holds the interceptors as
a kind of {{java.util.concurrent.CopyOnWriteArrayList}}. So modifying the growing list of
interceptors per each message should cause a growing performance drawback, which is also
not a good implementation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)