[
https://issues.apache.org/activemq/browse/AMQ-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60765#action_60765
]
Brad Willard commented on AMQ-2745:
-----------------------------------
Has anyone had a chance to verify this is a real problem or if there is
something wrong with my config? I am unable to upgrade past broker 5.3.0
because of it, and really want to be able to upgrade to resolve other issues
I've been seeing. I also want to make sure this isn't also an issue in the 5.4
broker due out.
> 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
> 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.
