activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-2745) Deadlock or Performance Bottleneck when reading messages with Correlation
Date Fri, 21 May 2010 16:15:51 GMT

    [ https://issues.apache.org/activemq/browse/AMQ-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59513#action_59513
] 

Gary Tully commented on AMQ-2745:
---------------------------------

it would be great if you could provide a tests case for this so we can see your configuration
and setup. Of interest is the maxPageSize for the queue and the distribution of messages across
the two 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
>         Environment: Java 64-bit, Windows 2008 Server
>            Reporter: Brad Willard
>            Priority: Minor
>
> 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.

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


Mime
View raw message