[
https://issues.apache.org/jira/browse/ARTEMIS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16881557#comment-16881557
]
Justin Bertram commented on ARTEMIS-2417:
-----------------------------------------
I'm looking into the behavior here, but I'm not totally certain what's going on
yet. However, I can say that if you set {{consumerWindowSize=0}} on the
client's URL the behavior changes. Here's the output I'm seeing now:
{noformat}
Sent message to exampleQueue: ROLLBACK
Sent message to exampleQueue: Text message no.1
Sent message to exampleQueue: Text message no.2
Sent message to exampleQueue: Text message no.3
Sent message to exampleQueue: Text message no.4
Sent message to exampleQueue: Text message no.5
Sent message to exampleQueue: Text message no.6
Sent message to exampleQueue: Text message no.7
Sent message to exampleQueue: Text message no.8
Sent message to exampleQueue: Text message no.9
Sent message to exampleQueue: Text message no.10
1st delivery from exampleQueue: ROLLBACK
Message rolled back
Received message # 1: Text message no.1
Received message # 2: Text message no.2
Received message # 3: Text message no.3
Received message # 4: Text message no.4
Received message # 5: Text message no.5
Received message # 6: Text message no.6
Received message # 7: Text message no.7
Received message # 8: Text message no.8
Received message # 9: Text message no.9
Received message # 10: Text message no.10
Received message # 11: ROLLBACK
{noformat}
This appears to yield the expected behavior.
I'm continuing to investigate.
> 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
(v7.6.3#76005)
