activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yves Rey (JIRA)" <>
Subject [jira] [Commented] (AMQ-3454) Contention on a mutex during a stress when using SimpleAuthenticationPlugin
Date Tue, 10 Jul 2012 12:00:45 GMT


Yves Rey commented on AMQ-3454:

Hi Gary,

Yes, I saw your changes and I agree they will significantly reduce the contention on the mutex,
but there is still a copy made in RegionBroker#getDestinationMap. That copy is now out of
the mutex thus will not trigger contention, but is still much heavier than doing a hash lookup.
Also, since you are returning a reference of the map, I believe the read lock in getDestinationMap
is likely useless. And I wonder that even if it is not the case currently, some code could
modify the content of the returned map outside the mutex mechanism that guarantees integrity
of the list of destinations.


> Contention on a mutex during a stress when using SimpleAuthenticationPlugin
> ---------------------------------------------------------------------------
>                 Key: AMQ-3454
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.5.0
>            Reporter: William
>            Assignee: Gary Tully
>            Priority: Critical
>             Fix For: 5.6.0
>         Attachments: RWLockDestinations.txt,, amq-dump
> I am testing ActiveMQ 5.5 with my own stress test. I tried to implement a stress test
that use jms ressource in the same fashion that my application would do. 
> For that, I used jms template (from Spring) and  a pooled connection factory (as recommended).
I run a fixed number of thread that plublish on fixed number of topics. Each thread pick up
a topic and enter a loop that will send a message on the choosen topic.
> The issue is reproductible with SimpleAuthenticationPlugin active.  
> Configuration of the test : 
> * 100 topics
> * more than one thread per topic (actually 1500 producer threads)
> Common connection properties :
> * alwaysSessionAsync=false
> * dispatchAsync=false 
> * optimizeAcknowledge=true
> * socketBufferSize=131072&trace=true&wireFormat.cacheSize=2048&wireFormat.tcpNoDelayEnabled=true&wireFormat.tightEncodingEnabled=true&keepAlive=true&soTimeout=10000&connectionTimeout=10000\
> Producers : 
> * Message are not persistent
> * There is no transaction
> * Message expiration time is 30s
> * Unsing JMS template singleton with a PooledConnectionFactory
> * 3 JVM running 
> * connection options alwaysSyncSend=true,copyMessageOnSend=false
> Consumers :
> * just listening to each topic with a SimpleMessageListenerContainer and count messages
> * 3 JVM running 
> In attachment, you will find activemq config file and thread dumps. I can attach the
producer/consumers code if you need it but I think you have your own tests.
> This Jira is critical for me because security is mandatory for our use.
> If you need more information, please ask.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message