[jira] [Updated] (AMQ-5362) Consider a consumer slow if messages expire before it processes them

["Tim Bain (JIRA)" <ji...@apache.org>]

     [ 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)