[
https://issues.apache.org/activemq/browse/AMQ-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Willard updated AMQ-2745:
------------------------------
Fix Version/s: (was: 5.4.1)
Affects Version/s: 5.3.2
Environment: Java 64-bit, Windows 2008 Server, Centos 5 64bit,
Ubuntu 110 64-bit (was: Java 64-bit, Windows 2008 Server)
Priority: Major (was: Minor)
Description:
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.
was:
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. 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.
I updated the issue because it's a major performance issue that also exists in
5.3.2 when using messages selectors.
> 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
>
>
> 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.
