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-5361) Allow for multiple slow consumer strategies to be used together
Date Tue, 16 Sep 2014 16:53:34 GMT

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

Tim Bain updated AMQ-5361:
--------------------------
    Description: 
AMQ-378 allowed a pluggable policy for aborting consumers that were slow, where a consumer
was slow if the broker was holding a number of messages for it equal to the consumer's prefetch
buffer size, in addition to the same number of messages already in the consumer's prefetch
buffer.  AMQ-4621 added the ability to use a different slow consumer strategy and provided
one other strategy, to consider a consumer slow if it hasn't acked a message in a certain
amount of time.

These strategies each has certain things it protects well against while not protecting against
others, but I want the ability to be protected from all of them, by being able to select multiple
SlowConsumerStrategy implementations for my needs.  This would also allow us to use future
SlowConsumerStrategy implementations (e.g. AMQ-5361) alongside the two that exist today.

In the short term, this might be as simple as turning PolicyEntry.slowConsumerStrategy into
a Set<SlowConsumerStrategy> and performing all actions on each entry in the set.

In the longer term, we should think about whether it would be better to break the SlowConsumerStrategy
interface apart to pull out a SlowConsumerIdentificationStrategy interface that would let
us pass a consumer to a method and have it tell us whether it considers the consumer to be
slow (calling each of those in turn, since that's really what we'd want to have a multiplicity
> 1), and a separate SlowConsumerHandlerStrategy interface that would let us choose what
action to take in response when we figure out that a consumer is slow (which could probably
have a multiplicity of 1).  If the implementer chooses not to do this longer-term refactoring
as part of resolving this issue, then please split it out into a separate JIRA to capture
it for the future.

  was:
AMQ-378 allowed a pluggable policy for aborting consumers that were slow, where a consumer
was slow if the broker was holding a number of messages for it equal to the consumer's prefetch
buffer size, in addition to the same number of messages already in the consumer's prefetch
buffer.  AMQ-4621 added the ability to use a different slow consumer strategy and provided
one other strategy, to consider a consumer slow if it hasn't acked a message in a certain
amount of time.

These strategies each has certain things it protects well against while not protecting against
others, but I want the ability to be protected from all of them, by being able to select multiple
SlowConsumerStrategy implementations for my needs.  This would also allow us to use future
SlowConsumerStrategy implementations alongside the two that exist today.

In the short term, this might be as simple as turning PolicyEntry.slowConsumerStrategy into
a Set<SlowConsumerStrategy> and performing all actions on each entry in the set.

In the longer term, we should think about whether it would be better to break the SlowConsumerStrategy
interface apart to pull out a SlowConsumerIdentificationStrategy interface that would let
us pass a consumer to a method and have it tell us whether it considers the consumer to be
slow (calling each of those in turn, since that's really what we'd want to have a multiplicity
> 1), and a separate SlowConsumerHandlerStrategy interface that would let us choose what
action to take in response when we figure out that a consumer is slow (which could probably
have a multiplicity of 1).  If the implementer chooses not to do this longer-term refactoring
as part of resolving this issue, then please split it out into a separate JIRA to capture
it for the future.


> Allow for multiple slow consumer strategies to be used together
> ---------------------------------------------------------------
>
>                 Key: AMQ-5361
>                 URL: https://issues.apache.org/jira/browse/AMQ-5361
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Broker
>    Affects Versions: 5.9.0
>            Reporter: Tim Bain
>
> AMQ-378 allowed a pluggable policy for aborting consumers that were slow, where a consumer
was slow if the broker was holding a number of messages for it equal to the consumer's prefetch
buffer size, in addition to the same number of messages already in the consumer's prefetch
buffer.  AMQ-4621 added the ability to use a different slow consumer strategy and provided
one other strategy, to consider a consumer slow if it hasn't acked a message in a certain
amount of time.
> These strategies each has certain things it protects well against while not protecting
against others, but I want the ability to be protected from all of them, by being able to
select multiple SlowConsumerStrategy implementations for my needs.  This would also allow
us to use future SlowConsumerStrategy implementations (e.g. AMQ-5361) alongside the two that
exist today.
> In the short term, this might be as simple as turning PolicyEntry.slowConsumerStrategy
into a Set<SlowConsumerStrategy> and performing all actions on each entry in the set.
> In the longer term, we should think about whether it would be better to break the SlowConsumerStrategy
interface apart to pull out a SlowConsumerIdentificationStrategy interface that would let
us pass a consumer to a method and have it tell us whether it considers the consumer to be
slow (calling each of those in turn, since that's really what we'd want to have a multiplicity
> 1), and a separate SlowConsumerHandlerStrategy interface that would let us choose what
action to take in response when we figure out that a consumer is slow (which could probably
have a multiplicity of 1).  If the implementer chooses not to do this longer-term refactoring
as part of resolving this issue, then please split it out into a separate JIRA to capture
it for the future.



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

Mime
View raw message