[
https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186902#comment-15186902
]
Yotam Madem commented on CXF-6825:
----------------------------------
I was thinking about it again
Let's look at the code we had before my change:
synchronized (THREAD_BUSSES) {
h = THREAD_BUSSES.get(cur);
}
<<AT THIS POINT CONTEXT SWITCH CAN HAPPEN>>
if (h == null || h.stale) {
In case that context switch happens at this point and
clearDefaultBusForAnyThread is working, it will lead to the exact same results
as if we didn't use the synchronized block.
Still, the "if (h == null || h.stale)" can happen during the operation of
clearDefaultBusForAnyThread because it is out of any synchronized block.
> Performance bottle neck due to synchronize block on each read
> -------------------------------------------------------------
>
> Key: CXF-6825
> URL: https://issues.apache.org/jira/browse/CXF-6825
> Project: CXF
> Issue Type: Bug
> Components: Bus, JAX-RS
> Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.0, 3.1.6
> Environment: All environments
> Reporter: Yotam Madem
> Fix For: 3.2.0, 3.1.6
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In our (IBM MobileFirst foundation) performance tests it is possible to see
> that many threads are stuck at:
> "LargeThreadPool-thread-1505" daemon prio=10 tid=0x00007f10f020b800
> nid=0x31fc waiting for monitor entry [0x00007f12bfffd000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.cxf.BusFactory.getThreadBusHolder(BusFactory.java:120)
> - waiting to lock <0x00000000c6b99020> (a java.util.WeakHashMap)
> at
> org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(BusFactory.java:202)
>
> (We use version 3.1.0)
> I did a test fix locally and it seems to resolve our problem so I submitted 2
> pull requests:
> for 3.1.6: https://github.com/apache/cxf/pull/119
> for 3.2.0: https://github.com/apache/cxf/pull/120
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
