cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yotam Madem (JIRA)" <>
Subject [jira] [Commented] (CXF-6825) Performance bottle neck due to synchronize block on each read
Date Wed, 09 Mar 2016 16:01:40 GMT


Yotam Madem commented on CXF-6825:

Just checked this 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
     *                         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:
>             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(
> 	- waiting to lock <0x00000000c6b99020> (a java.util.WeakHashMap)
> 	at org.apache.cxf.BusFactory.getAndSetThreadDefaultBus(
> (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:
> for 3.2.0:

This message was sent by Atlassian JIRA

View raw message