You are viewing a plain text version of this content. The canonical link for it is here.
Posted to gitbox@activemq.apache.org by GitBox <gi...@apache.org> on 2019/07/09 19:56:34 UTC

[GitHub] [activemq-artemis] jbertram commented on issue #2747: ARTEMIS-2420 implementation

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


With regards,
Apache Git Services