[
https://issues.apache.org/jira/browse/ARTEMIS-2649?focusedWorklogId=414074&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-414074
]
ASF GitHub Bot logged work on ARTEMIS-2649:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 01/Apr/20 14:54
Start Date: 01/Apr/20 14:54
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_r401678967
##########
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:
@jbertram thanks for the answer.
In general I accept the fact that different companies/projects has different
practices/approaches etc and there is no single good standard fitting all of
them as it all really depends on many factors.
Definitely it is better to have this fix as it is now, rather than not
having it at all and keep discussing it for next year or so.
So I am happy with above as long as this is according to Artemis project
standards, which I suppose other Artemis commiters should approve.
@jbertram thanks again for your time on this.
----------------------------------------------------------------
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: 414074)
Time Spent: 2h 10m (was: 2h)
> 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 10m
> 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)
