[
https://issues.apache.org/jira/browse/ARTEMIS-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-4681:
------------------------------------
Description:
I noticed while running a consumer on a retroactive topic and slow consumer
kicking with ActiveMQ Classic 5.16.5 (which has duplicate message detection)
that the broker gets into a vicious kicking loop:
# I connect to Retoractive.Addr, which as retroactive message count set to 100.
# I receive the last 100 messages and continue to listen for new messages.
Everything is fine at this point.
# I disconnect or get killed due to being a slow consumer.
# I automatically reconnect to Retoractive.Addr and, since it's retroactive, I
receive the last 100 messages immediately.
# I discard all of them due to having already seen them (after all, I just
reconnected, I myself did not restart)
# Artemis sees this as a consumer that has not acked any messages (since they
were discarded) and immediately kills it.
# The cycle continues…
It seems retroactive consumers are doing what it should, message de-duplication
client-side also working as expected, but not sure if slow consumer kicking
should be disabled for retroactive topics due to this. I have not verified this
against an Artemis client, just against a Classic client where I've observed
this behavior.
was:
I noticed while running a consumer on a retroactive topic and slow consumer
kicking with ActiveMQ Classic 5.16.5 (which has duplicate message detection)
that the broker gets into a vicious kicking loop:
1) I connect to Retoractive.Addr, which as retroactive message
count set to 100.
2) I receive the last 100 messages and continue to listen for new
messages. Everything is fine at this point.
3) I disconnect or get killed due to being a slow consumer.
4) I automatically reconnect to Retoractive.Addr and, since it's
retroactive, I receive the last 100 messages immediately.
5) I discard all of them due to having already seen them (after all, I
just reconnected, I myself did not restart)
6) Artemis sees this as a consumer that has not acked any messages
(since they were discarded) and immediately kills it.
7) The cycle continues…
It seems retroactive consumers are doing what it should, message de-duplication
client-side also working as expected, but not sure if slow consumer kicking
should be disabled for retroactive topics due to this. I have not verified this
against an Artemis client, just against a Classic client where I've observed
this behavior.
> Retroactive consumers get continuously kicked as a slow consumer if consumers
> dedupe messages
> ---------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-4681
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4681
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.32.0
> Reporter: Josh Byster
> Priority: Minor
>
> I noticed while running a consumer on a retroactive topic and slow consumer
> kicking with ActiveMQ Classic 5.16.5 (which has duplicate message detection)
> that the broker gets into a vicious kicking loop:
> # I connect to Retoractive.Addr, which as retroactive message count set to
> 100.
> # I receive the last 100 messages and continue to listen for new messages.
> Everything is fine at this point.
> # I disconnect or get killed due to being a slow consumer.
> # I automatically reconnect to Retoractive.Addr and, since it's retroactive,
> I receive the last 100 messages immediately.
> # I discard all of them due to having already seen them (after all, I just
> reconnected, I myself did not restart)
> # Artemis sees this as a consumer that has not acked any messages (since they
> were discarded) and immediately kills it.
> # The cycle continues…
> It seems retroactive consumers are doing what it should, message
> de-duplication client-side also working as expected, but not sure if slow
> consumer kicking should be disabled for retroactive topics due to this. I
> have not verified this against an Artemis client, just against a Classic
> client where I've observed this behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
