[
https://issues.apache.org/activemq/browse/AMQ-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61771#action_61771
]
Brad Willard commented on AMQ-2745:
-----------------------------------
I wanted to confirm that this is still an issue in the 5.4 release. I can do
it with the default properties file it ship with as well. Increasing the
maxPageSize in the policyEntry seems to help the issue, but eventually the
consumer on a separate correlation will lock up.
Any ideas, this is has prevented up from upgrading since 5.3.0.
> 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
> Fix For: NEEDS_REVIEWED
>
> 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.
