activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Bain (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-5362) Consider a consumer slow if messages expire before it processes them
Date Tue, 16 Sep 2014 17:33:33 GMT

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

Tim Bain updated AMQ-5362:
--------------------------
    Description: 
If a consumer is consistently consuming messages slower than the producer is producing them
and the messages have an expiration date, messages will eventually expire before the producer
can consume them.  When this occurs, the consumer should be considered slow, but neither of
the two existing slow consumer strategies (AbortSlowConsumerStrategy, which requires undispatched
messages on the broker equal to the consumer's prefetch buffer size, and AbortSlowAckConsumerStrategy,
which requires the consumer to take longer than a certain amount of time to process any given
message) will identify this slowness and react to it.  There are scenarios where they will,
but it's easy to create one where they don't.

The implementation will need to consider that a consumer with a durable subscription might
have reconnected just before a message expires, which doesn't mean the consumer is slow. 
One approach might be to only consider the consumer slow when the message that expires was
accepted by the broker after the consumer connected.

This feature would be best implemented along with AMQ-5361, which would allow us to use more
than one slow consumer strategy at the same time, since it's unlikely that we'd want to use
this strategy *instead of* one of the other two.

  was:
If a consumer is consistently consuming messages slower than the producer is producing them
and the messages have an expiration date, messages will eventually expire before the producer
can consume them.  When this occurs, the consumer should be considered slow, but neither of
the two existing slow consumer strategies (AbortSlowConsumerStrategy, which requires undispatched
messages on the broker equal to the consumer's prefetch buffer size, and AbortSlowAckConsumerStrategy,
which requires the consumer to take longer than a certain amount of time to process any given
message) will identify this slowness and react to it.  There are scenarios where they will,
but it's easy to create one where they don't.

This feature would be best implemented along with AMQ-5361, which would allow us to use more
than one slow consumer strategy at the same time, since it's unlikely that we'd want to use
this strategy *instead of* one of the other two.


> Consider a consumer slow if messages expire before it processes them
> --------------------------------------------------------------------
>
>                 Key: AMQ-5362
>                 URL: https://issues.apache.org/jira/browse/AMQ-5362
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Broker
>    Affects Versions: 5.10.0
>            Reporter: Tim Bain
>
> If a consumer is consistently consuming messages slower than the producer is producing
them and the messages have an expiration date, messages will eventually expire before the
producer can consume them.  When this occurs, the consumer should be considered slow, but
neither of the two existing slow consumer strategies (AbortSlowConsumerStrategy, which requires
undispatched messages on the broker equal to the consumer's prefetch buffer size, and AbortSlowAckConsumerStrategy,
which requires the consumer to take longer than a certain amount of time to process any given
message) will identify this slowness and react to it.  There are scenarios where they will,
but it's easy to create one where they don't.
> The implementation will need to consider that a consumer with a durable subscription
might have reconnected just before a message expires, which doesn't mean the consumer is slow.
 One approach might be to only consider the consumer slow when the message that expires was
accepted by the broker after the consumer connected.
> This feature would be best implemented along with AMQ-5361, which would allow us to use
more than one slow consumer strategy at the same time, since it's unlikely that we'd want
to use this strategy *instead of* one of the other two.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message