[
https://issues.apache.org/jira/browse/ARTEMIS-2420?focusedWorklogId=274323&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-274323
]
ASF GitHub Bot logged work on ARTEMIS-2420:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 09/Jul/19 19:56
Start Date: 09/Jul/19 19:56
Worklog Time Spent: 10m
Work Description: jbertram commented on issue #2747: ARTEMIS-2420
implementation
URL: https://github.com/apache/activemq-artemis/pull/2747#issuecomment-509784687
Couple of things:
- The commits should be squashed and rebased on the head of `master`.
- You don't need to re-create PRs to trigger another Travis run. Just do
something like `git commit --amend` and then `git push -f origin <branch>`.
- The commit message should be more specific than just "implementation".
You'll find commit message recommendations in the [Hacking
Guide](https://github.com/apache/activemq-artemis/blob/master/docs/hacking-guide/en/maintainers.md#commit-messages).
That said, I have some broader reservations about this PR. It takes care of
the configuration side of things (i.e. it allows you to configure a DLA
prefix). However, the prefixed dead-letter addresses will still need to be
*manually* created which kind of defeats the purpose of this feature which is
to automate this process for auto-created addresses and queues.
In order to behave more like 5.x the broker would need to auto-create the
dead-letter address with the same name as the original address with the proper
prefix. However, an address alone is not enough to store messages so a queue
will need to be created as well. This is where, in my opinion, things start to
break down due to fundamental differences in the message routing configuration
and semantics between 5.x and Artemis. The 5.x broker deals with JMS-centric
resources (i.e. queues & topics) whereas Artemis deals with more general and
granular resources (i.e. addresses, queues, & routing-types). If you're only
thinking about the JMS use-case then it would be fine for the broker to create
the properly named dead-letter address with a single anycast queue of the same
name. However, in order to be appropriately flexible it will need to support
multicast as well and it's plausible that the queue (if one is created) should
not, in fact, have the same name as the address. You can see how the
configuration options and the test scenarios start to expand to something much
larger than what you've included in this PR.
At this point I think the best solution is the one which is already
available. That is, statically creating one or more dead-letter addresses and
corresponding queues and using those to aggregate the undeliverable messages
from auto-created queues. When the broker sends a message to a dead-letter
address it adds properties for the original address, queue, and message ID.
These properties can be used by consumers to filter the messages and find what
they need.
----------------------------------------------------------------
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: 274323)
Time Spent: 40m (was: 0.5h)
Remaining Estimate: 11h 20m (was: 11.5h)
> 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
> Fix For: 2.10.0
>
> Original Estimate: 12h
> Time Spent: 40m
> Remaining Estimate: 11h 20m
>
> ActiveMQ Classic supports DLQ prefixes for dynamically created destinations.
> This causes regression when switching from AMQ5 to AMQ Artemis, therefore it
> should be reimplemented.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
