[
https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189007#comment-15189007
]
Alessio Soldano commented on CXF-6825:
--------------------------------------
Well, to me those tuning could be something addressed as a later improvement to
the change here. We could start with sensible values, perhaps similar to the
default of the JDK ConcurrentHashMap and then add options for letting the user
tune them.
> 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)
