[jira] Updated: (AMQ-2745) Deadlock or Performance Bottleneck when reading messages with Correlation

["Brad Willard (JIRA)" <ji...@apache.org>]

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

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

          Environment: Java 64-bit, Windows 2008 Server, Centos 5 64bit,  Ubuntu 110 64-bit, OS X 10.5, 10.6  (was: Java 64-bit, Windows 2008 Server, Centos 5 64bit,  Ubuntu 110 64-bit)
    Affects Version/s: 5.4.1

I have confirmed this is still a problem in 5.4.1  I have also confirmed you can reproduce this problem with the default activemq configuration file.  Disabling flow control has no effect, neither does lowering the message pre-fetch.  This is a real performance issues for anyone using message selectors.

> Deadlock or Performance Bottleneck when reading messages with Correlation
> -------------------------------------------------------------------------
>
>                 Key: AMQ-2745
>                 URL: https://issues.apache.org/jira/browse/AMQ-2745
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.3.1, 5.3.2, 5.4.0, 5.4.1
>         Environment: Java 64-bit, Windows 2008 Server, Centos 5 64bit,  Ubuntu 110 64-bit, OS X 10.5, 10.6
>            Reporter: Brad Willard
>             Fix For: NEEDS_REVIEWED
>
>         Attachments: activemq.xml, 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.