[
https://issues.apache.org/activemq/browse/AMQ-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-378.
----------------------------
Resolution: Fixed
r946138 adds support for a destination policy slowConsumerStrategy with a
default impl AbortSlowConsumerStrategy that will abort a consumer when either
its slowCount exceeds the maxSlowCount or it has been deemed slow for the
maxSlowDuration. the check period is configured by the checkPeriod.
To abort, by default a close ConsumerConnand is dispatched to the remote
consumer. This requires an active consumer session to react. When
abortConnection=true, the entire connection associated with that consumer is
closed. Closing the entire connection is more deterministic as it will work
independent of the state of the connection or remote session. But it will be
draconian if the connection is shared.
Some background:
*The first issue is determination of slowness*
In activemq, slowness is based on the broker exceeding the prefetch value of a
consumer.
The broker will always try to dispatch up to prefetch messages to a consumer.
If it has messages to dispatch but there is no prefetch buffer available, then
that consumer is deemed to be slow.
The prefetch value is set through configuration, decremented on every message
dispatch (which is typically async) and incremented again on every ack. A
regular flow of acks will keep the prefetch value high.
With bursty message production and a small prefetch value, consumers can easily
become slow but will quickly recover. With low levels of message production and
a very large prefetch, it may take some time for a slow consumer to be
considered slow!
it is important to understand the inherent variability in slowness determination
*Slowness is transient*
Give that there is some variance in slowness determination and that it can
change from one minute to the next, depending on the message production rate,
determining whether a consumer should be disconnected needs to take account of
the duration or quantity of slowness.
A consumer that is repeatedly slow for X checks of Y duration is a good
candidate. Or a consumer that has been deemed slow 100 times, should at least
have its prefetch value recalculated. The former seems a better approach, but
the latter could be more immediate in the case that the prefetch should always
be adequate.
_Note: it is always the quantity of messages that is considered by the pref
etch value. It may make some sense to evaluate a size based prefetch at a
future date which would still be compatible with this approach._
> add pluggable Policy which is fired in a background Timer to detect slow
> consumers for non-durable topics and kill them (maybe with a pre-warning of
> being slow a little before being killed)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-378
> URL: https://issues.apache.org/activemq/browse/AMQ-378
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Broker
> Reporter: James Strachan
> Assignee: Gary Tully
> Fix For: 5.4.0
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
