[
https://issues.apache.org/jira/browse/ARTEMIS-2649?focusedWorklogId=407560&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-407560
]
ASF GitHub Bot logged work on ARTEMIS-2649:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 22/Mar/20 10:02
Start Date: 22/Mar/20 10:02
Worklog Time Spent: 10m
Work Description: PiotrKlimczak commented on pull request #3017:
ARTEMIS-2649 refactor ORIG message props
URL: https://github.com/apache/activemq-artemis/pull/3017#discussion_r396075152
##########
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:
Just to be sure we are on the same page.
My only concern is that with fully correct config, Artemis can still lose a
message.
We both agreed we can't see such scenario (bug) for now, however potential
is there- hence your warning.
Or putting the question the other way round, why do you think we need this
warning at all, considering the user has configured
auto-create-dead-letter-resources? And I think the answer is- because we both
know there is such potential and I am saying we could be more defensive in such
scenario.
And I don't care about situation when user misconfigures something, as I
fully agree they need to test their config.
The other question should be then:
Is there a scenario where auto-create-dead-letter-resources is configured
and the user doesn't want some of the messages to land in any auto-created DLQ-
like can we specify additional filter, which will be applied to auto-crated
DLQs or this is not possible/planned?
If ability to configure additional filters on auto-created DLQs is there (I
am not aware of it by code analysis), then "defensive" approach is indeed in
conflict with this feature.
That would be technically the only thing which would justify not having
defensive code.
@jbertram WDYT?
----------------------------------------------------------------
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: 407560)
Time Spent: 1h 50m (was: 1h 40m)
> 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: 1h 50m
> 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)
