[ 
https://issues.apache.org/activemq/browse/AMQ-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brad Willard updated AMQ-2745:
------------------------------

    Affects Version/s: 5.4.0

Confirmed this is still an issue in the 5.4 snapshot 
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.4-SNAPSHOT/apache-activemq-5.4-SNAPSHOT-bin.tar.gz

> Deadlock or Performance Bottleneck when reading messages with Correlation
> -------------------------------------------------------------------------
>
>                 Key: AMQ-2745
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2745
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.1, 5.3.2, 5.4.0
>         Environment: Java 64-bit, Windows 2008 Server, Centos 5 64bit,  
> Ubuntu 110 64-bit
>            Reporter: Brad Willard
>         Attachments: activemq.xml, PutMessages.java, ReadMessages.java
>
>
> We have a situation where we are posting messages to a queue with two 
> different correlation ids specifically intended to reach two different 
> clients who subscribe with message selectors for the appropriate correlation. 
>  The clients are reading with message listeners.  When one client stops 
> reading the expected behavior, and the behavior we saw on 5.3.0, is that the 
> messages with the correlation for the stopped client will backup on the queue 
> and will not effect the performance of the second client who is still reading 
> the messages with the other correlation.  With our memory config messages can 
> backup into the hundreds of thousands before noticing any performance impact 
> on the active client.
> However this is not the case in 5.3.1 or 5.3.2.  With 5.3.1 once enough 
> messages backup for the stopped client, suddenly the active client's 
> performance drops drastically 20 ms reads to 30,000ms reads.  We will see 
> this within a few hundred messages.  I believe there is some kind of 
> deadlock, or buffering bottleneck that was introduced on the client side.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to