[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3847?page=com.atlassian.jira.plugin.... ]
Alessio Soldano edited comment on JBWS-3847 at 10/22/14 10:19 AM:
------------------------------------------------------------------
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 number of calls to setHandlerChain() to the actual minimum required, effectively mitigating the leak; see JBWS-3848 for more details.
was (Author: asoldano):
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)
9 years, 10 months
[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor
by Alessio Soldano (JIRA)
[ 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)
9 years, 10 months
[JBoss JIRA] (JBWS-3848) Optimize HandlerChainSortInterceptor
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-3848:
-------------------------------------
Summary: Optimize HandlerChainSortInterceptor
Key: JBWS-3848
URL: https://issues.jboss.org/browse/JBWS-3848
Project: JBoss Web Services
Issue Type: Enhancement
Components: jbossws-cxf
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-5.0
HandlerChainSortInterceptor needs to be optimized to avoid setting the handler chain after having sorted it if the sort operation actually did nothing relevant.
We should detect if we really need to sort (because of PRE/POST handlers) and relax the sorting requirement (we only care about the PRE/POST thing, not about the internal order of user handlers).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3847?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3847:
----------------------------------
Fix Version/s: jbossws-cxf-5.0
> 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)
9 years, 10 months
[JBoss JIRA] (JBWS-3843) EJB3 Web Service returns Invalid User on parallel invocations
by Mustafa Musaji (JIRA)
[ https://issues.jboss.org/browse/JBWS-3843?page=com.atlassian.jira.plugin.... ]
Mustafa Musaji updated JBWS-3843:
---------------------------------
Priority: Critical (was: Major)
> EJB3 Web Service returns Invalid User on parallel invocations
> -------------------------------------------------------------
>
> Key: JBWS-3843
> URL: https://issues.jboss.org/browse/JBWS-3843
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf, jbossws-integration, ws-security
> Affects Versions: jbossws-cxf-4.3.1
> Environment: JBoss EAP 6.3.1
> Reporter: Mustafa Musaji
> Assignee: Jim Ma
> Priority: Critical
> Fix For: jbossws-cxf-5.0
>
> Attachments: ClientSample.java, javaee-ws-with-security_1413372207000.zip
>
>
> EJB3 Web Service using username token for authentication fails when you load test it with parallel invocations. See attached reproducer.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3847?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBWS-3847:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1155490
> 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)
9 years, 10 months
[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor
by Tadayoshi Sato (JIRA)
[ 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)
9 years, 10 months
[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor
by Tadayoshi Sato (JIRA)
Tadayoshi Sato created JBWS-3847:
------------------------------------
Summary: 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)
9 years, 10 months
[JBoss JIRA] (JBWS-3846) Refactor creation process of jaxws handlers from predefined configurations
by Alessio Soldano (JIRA)
Alessio Soldano created JBWS-3846:
-------------------------------------
Summary: Refactor creation process of jaxws handlers from predefined configurations
Key: JBWS-3846
URL: https://issues.jboss.org/browse/JBWS-3846
Project: JBoss Web Services
Issue Type: Task
Components: jbossws-cxf, jbossws-integration
Reporter: Alessio Soldano
Fix For: jbossws-cxf-5.0
We currently have no special integration with the container for jaxws handlers created from a predefined client/endpoint configuration. We need to support @PostConstruct, @PreDestroy methods, as well as @EJB, @Resource and CDI injection.
Most likely this basically boils down to having AS components created for these handlers too, the same we have for jaxws handlers created after having parsed the @HandlerChain annotation. See org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_HANDLER and org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor as starting point.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months