[jbossws-issues] [JBoss JIRA] (JBWS-3966) Avoid calling BusFactory.setThreadDefaultBus(null) in JBossWSInvoker
[
https://issues.jboss.org/browse/JBWS-3966?page=com.atlassian.jira.plugin....
]
Alessio Soldano updated JBWS-3966:
----------------------------------
Description:
The invocation BusFactory.setThreadDefaultBus(null) in JBossWSInvoker (just before
invoking the actual user endpoint business code) is problematic performance-wise because
CXF internally removes the ThreadLocal association of the current thread bus with the
thread. When the JBossWSInvoker restores the former thread default bus just after the user
endpoint business code execution, that ThreadLocal being unset causes CXF to access the
BusFactory THREAD_BUSSES WeakHashMap within a synchronized block. Under heavy load, this
easily become one of the contention hot spots in the WS invocation.
Now, the reason why the JBossWSInvoker calls BusFactory.setThreadDefaultBus(null) is to
prevent the user from having access to the Bus that the integration code uses for running
the deployment endpoints, to prevent users from influencing or breaking the integration
(response processing, for example) in any way.
To be honest this also has a minor side effect of always wiping a thread default Bus the
user might have set in its endpoint business code, regardless of which thread the code is
being executed on.
As a consequence, it makes sense to create an additional Bus for the user endpoint code;
that Bus will be set as thread default each time the JBossWSInvoker handles control to
business methods of endpoints from the same deployment. This would prevent the BusFactory
ThreadLocal from being removed (performance improvement when the integration deployment
bus is later restored) and give back the same bus to the user on multiple invocations to
the same deployment's endpoints.
was:
The invocation to
Analyse if we can avoid invoking BusFactory::setThreadDefaultBus in some scenarios, to
reduce contention on its THREAD_BUSSES WeakHashMap.
Avoid calling BusFactory.setThreadDefaultBus(null) in JBossWSInvoker
--------------------------------------------------------------------
Key: JBWS-3966
URL: https://issues.jboss.org/browse/JBWS-3966
Project: JBoss Web Services
Issue Type: Enhancement
Components: jbossws-cxf
Reporter: Alessio Soldano
Assignee: Alessio Soldano
Fix For: jbossws-cxf-5.2.0.Final
The invocation BusFactory.setThreadDefaultBus(null) in JBossWSInvoker (just before
invoking the actual user endpoint business code) is problematic performance-wise because
CXF internally removes the ThreadLocal association of the current thread bus with the
thread. When the JBossWSInvoker restores the former thread default bus just after the user
endpoint business code execution, that ThreadLocal being unset causes CXF to access the
BusFactory THREAD_BUSSES WeakHashMap within a synchronized block. Under heavy load, this
easily become one of the contention hot spots in the WS invocation.
Now, the reason why the JBossWSInvoker calls BusFactory.setThreadDefaultBus(null) is to
prevent the user from having access to the Bus that the integration code uses for running
the deployment endpoints, to prevent users from influencing or breaking the integration
(response processing, for example) in any way.
To be honest this also has a minor side effect of always wiping a thread default Bus the
user might have set in its endpoint business code, regardless of which thread the code is
being executed on.
As a consequence, it makes sense to create an additional Bus for the user endpoint code;
that Bus will be set as thread default each time the JBossWSInvoker handles control to
business methods of endpoints from the same deployment. This would prevent the BusFactory
ThreadLocal from being removed (performance improvement when the integration deployment
bus is later restored) and give back the same bus to the user on multiple invocations to
the same deployment's endpoints.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)