[
https://issues.apache.org/jira/browse/ARTEMIS-2420?focusedWorklogId=280073&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-280073
]
ASF GitHub Bot logged work on ARTEMIS-2420:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 20/Jul/19 08:28
Start Date: 20/Jul/19 08:28
Worklog Time Spent: 10m
Work Description: PiotrKlimczak commented on issue #2760: ARTEMIS-2420
Adding support for DLA/DLQ prefix for wildcard addresses
URL: https://github.com/apache/activemq-artemis/pull/2760#issuecomment-513448481
I have summarised all questions and answers from this PR on
https://jira.apache.org/jira/browse/ARTEMIS-2420.
I think this can be closed now to avoid missing comments.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 280073)
Time Spent: 9h 50m (was: 9h 40m)
Remaining Estimate: 2h 10m (was: 2h 20m)
> Reimplementation of AMQ5 dead letter strategy queuePrefix
> ---------------------------------------------------------
>
> Key: ARTEMIS-2420
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2420
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 2.9.0
> Reporter: Piotr Klimczak
> Priority: Major
> Original Estimate: 12h
> Time Spent: 9h 50m
> Remaining Estimate: 2h 10m
>
> ActiveMQ Classic supports DLQ prefixes for dynamically created destinations.
> This causes regression when switching from AMQ5 to AMQ Artemis, therefore it
> should be reimplemented.
> *Detailed requirements*
> *Configuration*
> # Prefix is mandatory
> # Routing type for DLQ can be null, in which case it will be taken from the
> origin queue
> # DLA settings can be defined with address-settings with wildcard match
> # Configuration error should throw if both DLA and auto create DLA are
> defined - *TODO*
> # [michaelpearce-gain|https://github.com/michaelpearce-gain]: The same
> should be made for expiryQueues with all the same rules and logic - *TODO*
> Example
> {code:xml}
> <address-setting match="#">
> <dead-letter-address-auto-create prefix="DLA.">
> <routing-type>MULTICAST</routing-type>
> <durable>true</durable>
> <temporary>false</temporary>
> </dead-letter-address-auto-create>
> </address-setting>
> <address-setting match="DLA.#">
> <!-- DLA config goes here, as for standard addresses -->
> </address-setting>
> {code}
> Questions:
> # [michaelpearce-gain|https://github.com/michaelpearce-gain]: What occurs if
> both dead letter address is set and prefix?
> # [michaelpearce-gain|https://github.com/michaelpearce-gain]: Is there auto
> clean up, so the auto created dead letter addresses are removed when the
> original address is removed, in cases of auto creation.
> # [michaelpearce-gain|https://github.com/michaelpearce-gain]: Also would it
> be possible to configure a spefiic queue to goto a specific address, taking
> precedence over the default prefix when set.
> ** This is how it should work now- *TODO* test coverage
> *Message delivery to DLQ*
> # Delivery to dynamic DLQ only happens for messages failed by a consumer.
> # Delivery to dynamic addresses should happen using FQQN address, regardless
> of routing.
> Questions:
> # Should dynamic DLQ creation also work for messages delivered to an address
> with no queues?
> *Security*
> Questions:
> # [michaelpearce-gain|https://github.com/michaelpearce-gain]: What occurs if
> queue/address is allowed to be created due security settings, but the user
> able to do that is unable to create the dead letter address? Do both fail?
> Does one part succeed but the dla fails? And then what occurs?
> # [michaelpearce-gain|https://github.com/michaelpearce-gain]: What occurs
> when security settings come into play? How does it fail if you have ability
> to create address but not dla? Do both fail?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
