[ 
https://issues.apache.org/jira/browse/CXF-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187303#comment-15187303
 ] 

Yotam Madem commented on CXF-6825:
----------------------------------

Just checked this ConcurrentReferenceHashMap.java. It has some important tuning 
parameters in the constructor such as:

    * @param initialCapacity  the initial capacity. The implementation
     *                         performs internal sizing to accommodate this 
many elements.
     * @param loadFactor       the load factor threshold, used to control 
resizing.
     *                         Resizing may be performed when the average 
number of elements per
     *                         bin exceeds this threshold.
     * @param concurrencyLevel the estimated number of concurrently
     *                         updating threads. The implementation performs 
internal sizing
     *                         to try to accommodate this many threads.
Do you think we should externalize those so that the CXF user will be able to 
change their values? Looks like this is may be a good thing to do. In most 
cases, customers know the number of threads which are going to access their 
system (this can be a good value for initialSize) and the concurrencyLevel is 
also measurable.

> 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)

Reply via email to