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:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to