[
https://issues.apache.org/jira/browse/ARTEMIS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544267#comment-17544267
]
Raffaele Calandrella commented on ARTEMIS-2417:
-----------------------------------------------
Is there any news on that? I'm trying to understand how to handle that kind of
scenario even though I would like to better understand when consumer Window
Size=0 can affect performance
> Broker redelivery policy delays all messages currently on queue
> ---------------------------------------------------------------
>
> Key: ARTEMIS-2417
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2417
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.9.0
> Environment: I have been running Artemis on a docker container based
> on:
> FROM openjdk:8-jre-alpine
> Reporter: Ben Thurley
> Priority: Major
>
> *Steps to recreate:*
> # Create a queue with the following settings in {{broker.xml}}:
> {code:xml}
> <address-settings>
> <address-setting match="jms.queue.TestQueue">
> <dead-letter-address>DLQ</dead-letter-address>
> <redelivery-delay>10000</redelivery-delay>
> <max-delivery-attempts>3</max-delivery-attempts>
> </address-setting>
> </address-settings>
> <addresses>
> <address name="DLQ">
> <anycast>
> <queue name="DLQ" />
> </anycast>
> </address>
> <address name="jms.queue.TestQueue">
> <anycast>
> <queue name="jms.queue.TestQueue" />
> </anycast>
> </address>
> </addresses>{code}
> # Publish several messages to the queue without a delay between messages
> (I'm using JmsTemplate in Spring and CORE)
> # Have a consumer consume the messages and throw an exception to allow the
> redelivery policy to take affect
> *Expected behaviour:*
> The documentation says the following:
> bq. Other subsequent messages will be delivery regularly, only the cancelled
> message will be sent asynchronously back to the queue after the delay.
> So I was expecting the failed message to go back as a scheduled message with
> a delay and the remaining messages to be attempted to be delivered as normal.
> This was also how things worked on ActiveMQ 5.x.
> *Actual behaviour:*
> In reality all of the messages arrive back on the queue as scheduled messages
> with whatever {{redelivery-delay}} is configured.
> If the messages are sent to the queue with a bit of a delay between them then
> it can work out that only the failed message is rescheduled with the delay.
> It's only the messages that happen to be on the queue when one fails that all
> get sent back and rescheduled.
> The first message that causes the failure (and redelivery) has it's delivery
> count incremented, the other messages weren't actually delivered and their
> delivery count is not incremented.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
