Return-Path: X-Original-To: apmail-activemq-dev-archive@www.apache.org Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5D7AB10179 for ; Fri, 5 Jul 2013 20:17:48 +0000 (UTC) Received: (qmail 74957 invoked by uid 500); 5 Jul 2013 20:17:48 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 74922 invoked by uid 500); 5 Jul 2013 20:17:48 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 74913 invoked by uid 99); 5 Jul 2013 20:17:48 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jul 2013 20:17:48 +0000 Date: Fri, 5 Jul 2013 20:17:47 +0000 (UTC) From: "Gary Tully (JIRA)" To: dev@activemq.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (AMQ-4621) Provide a polling SlowConsumerPolicy that uses LastAck time on a sub MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Gary Tully created AMQ-4621: ------------------------------- Summary: Provide a polling SlowConsumerPolicy that uses LastAck time on a sub Key: AMQ-4621 URL: https://issues.apache.org/jira/browse/AMQ-4621 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.8.0 Reporter: Gary Tully Fix For: 5.9.0 The existing AbortSlowConsumer policy is event driven. It depends on a consumer slow event that is triggered when the prefetch is reached and there are subsequent dispatches. With prefetch=0|1 there still needs to be throughput to determine that the consumer is slow so one message can be pending if there are no new messages to sent to the destination. Providing an alternative implementation that will periodically poll consumers for their last ack time will be more deterministic. The slow advisory may never fire, but the consumer will get aborted if it does not ack in a timely manner. if lastAckTime exceeds the max and there are dispatched messages it can be a candidate for removal. Optionally lastAckTime exceeding and no dispatched messages can be a way to remove idle consumers. Not sure if that is necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira