activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [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)
Date Wed, 19 May 2010 12:08:23 GMT

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


Mime
View raw message