[ 
https://issues.apache.org/jira/browse/ARTEMIS-2649?focusedWorklogId=407559&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-407559
 ]

ASF GitHub Bot logged work on ARTEMIS-2649:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 22/Mar/20 09:44
            Start Date: 22/Mar/20 09:44
    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_r396073463
 
 

 ##########
 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:
   Thanks for your answer.
   I couldn't agree more with above in regards to manual configuration of 
queues and dlqs.
   However the same problem falls into much different category when 
auto-create-dead-letter-resources is used, as then it is Brokers responsibility 
to take care of everything it and not lose a message in any case- this is my 
only concern. 
   However obviously there is potential for loss to happen, as per your warning 
message.
   
 
----------------------------------------------------------------
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: 407559)
    Time Spent: 1h 40m  (was: 1.5h)

> 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 40m
>  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)

Reply via email to