[jira] [Commented] (AMQ-5114) AbortSlowAckConsumerStrategy with abortConnection=false; ensure consumers are always removed from the broker

["Tim Bain (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138001#comment-14138001 ] 

Tim Bain commented on AMQ-5114:
-------------------------------

The title of this JIRA refers to AbortSlowAckConsumerStrategy, whereas the commit was in AbortSlowConsumerStrategy, so it affects both classes.  When I first read the title, I assumed that the bug didn't apply to my 5.8.0 broker, since AbortSlowAckConsumerStrategy wasn't added until 5.9.0 and the Affects Version is 5.9.0.  Looking at the commit, it looks like this would affect both slow consumer strategies and pre-5.9.0 versions; can we update the title and Affects Version to clarify its scope, to avoid misleading future readers?

> AbortSlowAckConsumerStrategy with abortConnection=false; ensure consumers are always removed from the broker 
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-5114
>                 URL: https://issues.apache.org/jira/browse/AMQ-5114
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Broker
>    Affects Versions: 5.9.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>             Fix For: 5.10.0
>
>
> If a consumer is slow and a candidate to abort, the broker sends a control command to the consumer. However there is no guarantee that the consumer will respond to the command and close. As a result the consumer can remain longer than necessary and possibly indefinitely.,
> The broker needs to follow up with a local removeInfo  that will force the removal from the broker so that inflight messages can get eagerly redispatched.
> The client can eventually shut down the client view of the consumer but the broker will be able to continue regardless.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)