[
https://issues.apache.org/jira/browse/ARTEMIS-2649?focusedWorklogId=408015&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-408015
]
ASF GitHub Bot logged work on ARTEMIS-2649:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 23/Mar/20 16:10
Start Date: 23/Mar/20 16:10
Worklog Time Spent: 10m
Work Description: jbertram commented on pull request #3017: ARTEMIS-2649
refactor ORIG message props
URL: https://github.com/apache/activemq-artemis/pull/3017#discussion_r396570384
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
##########
@@ -3418,7 +3419,12 @@ private boolean sendToDeadLetterAddress(final
Transaction tx,
ref.acknowledge(tx, AckReason.KILLED, null);
} else {
ActiveMQServerLogger.LOGGER.messageExceededMaxDeliverySendtoDLA(ref,
deadLetterAddress, name);
- move(tx, deadLetterAddress, null, ref, false, AckReason.KILLED,
null);
+ RoutingStatus status = move(tx, deadLetterAddress, null, ref,
false, AckReason.KILLED, null);
+
+ // this shouldn't happen, but in case it does it's better to log a
message than just drop the message silently
+ if (status.equals(RoutingStatus.NO_BINDINGS) &&
server.getAddressSettingsRepository().getMatch(getAddress().toString()).isAutoCreateDeadLetterResources())
{
+
ActiveMQServerLogger.LOGGER.noMatchingBindingsOnDLAWithAutoCreateDLAResources(deadLetterAddress,
ref.toString());
Review comment:
Rather than get into a protracted discussion about coding philosophy I'll
refer to [my comment on the
Jira](https://issues.apache.org/jira/browse/ARTEMIS-2649?focusedCommentId=17058399&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17058399).
Simply put, adding complexity is likely to result in more bugs, not less.
Logging a message is extremely simple and follows precedence from other parts
of the code when we encounter things that "shouldn't happen." When you add
complexity to deal with these types of situations then you inevitably open
yourself up to more potential bugs which requires more testing and oftentimes
more user-configurable options (because not everybody wants to handle
everything the same way) which requires even more code, tests, and
documentation. Furthermore, if the original defensive code is sufficiently
complex then it will need its own defensive code and that code will need tests,
etc. Adding complexity is an untenable solution.
I think the best defense against bugs here is simply more testing (as noted
on the Jira). You tested the implementation and found a bug. I added a test for
your use-case and fixed the bug. Please continue testing to verify everything
works for your expected use-cases.
I have no plans to allow additional customization of the filters for
auto-created dead-letter-queues.
----------------------------------------------------------------
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: 408015)
Time Spent: 2h (was: 1h 50m)
> Auto-create DLQ message loss when moving messages between destinations
> ----------------------------------------------------------------------
>
> Key: ARTEMIS-2649
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2649
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.12.0
> Environment: Centos 7 container in OKD with Java 8.
> Reporter: Piotr Klimczak
> Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> [~jbertram], first of all thanks a lot for ARTEMIS-2587 implementation.
> This was a must for me to switch to Artemis.
> In past I have even tried to implement it in Artermis, but having no
> previous experience with it, only with your PR I understood how nicely and
> easily it can be implemented and how much I have overcomplicated it.
> So I am testing 2.12.0 snapshot as I am really interested in work done under
> ARTEMIS-2587.
> I am connecting using open wire protocol using camel-jms component, having
> replaced old AMQ5 with Artermis.
> On failed consumption, I can see queue being created under DLQ address with
> multicast and filter _AMQ_ORIG_ADDRESS = 'some.queue'.
> However it is empty and message is lost.
> Reproduction scenario:
> # Sending message to address A
> # Moving message from A queue to B using web console move function
> # Consuming from B and failing consumption
> Observed state:
> # Queue is being created
> # Message is lost and logs are not indicating anything
> As a result this message being moved from A to be B queue, the header
> "_AMQ_ORIG_ADDRESS" has value "A" instead of "B" and therefore it does not
> match the filter "B" and is getting lost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
