[jira] Resolved: (AMQ-378) 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)

["Gary Tully (JIRA)" <ji...@apache.org>]

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