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