[
https://issues.jboss.org/browse/JBWS-3847?page=com.atlassian.jira.plugin....
]
Tadayoshi Sato commented on JBWS-3847:
--------------------------------------
This issue appears to have been resolved in CXF 3.0.x, as {{JaxWsEndpointImpl}} has
introduced the following guard clause in {{addHandlerInterceptors}} method:
{code:java}
public void addHandlerInterceptors() {
if (handlerInterceptorsAdded) {
return;
}
handlerInterceptorsAdded = true;
{code}
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
{{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)