[
https://issues.apache.org/jira/browse/ARTEMIS-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057393#comment-17057393
]
Piotr Klimczak commented on ARTEMIS-2649:
-----------------------------------------
{quote}In case you missed this in my last comment, I provided a mitigation
measure (i.e. "you can statically create a queue on the dead-letter address to
ensure messages are not lost").
I think the best that could be done here would be to log a WARN message. This
is similar to what is already done in other situations like this.
{quote}
TBH I would accept this as a official workaround to newly discovered bug in
already live system.
But for newly implemented solution, it doesn't sound good enough to support the
idea of not loosing message under no circumstances.
The reason for that is because:
# It requires the user to do something extra and upfront, just in case
assuming they are aware of such limitation
# It would produce duplicate of each message in two different DLQs assuming
taking two times the space
# If you have a massive failure, having thousands or tens of thousands of
messages in DLQ, it will be impossible to verify which ones are missing across
all auto-created DLQ versus one "statical" - it happens
# Statical DLQ will require manual cleanup, as otherwise we implement auto
expiration- arrr getting too complex.
Unless I am missing something, which I can as I am unfamiliar with Artemis.
So I would rather opt in for some more "defensive" implementation.
Just to clarify- I am not coming from position of an expert, but from position
of Red Hat customer.
Simply I am considering replacing our old AMQ 6 with 7 where I work. But
"supportability" and "resilience" will be one of the key factors we will be
considering when making decision if to use AMQ 7 or different commercial
solution with our customers (we are software vendor too).
Might be worth asking for another independent opinion if in doubt- always a
good practice to consult with your team when problem is tricky.
Hope you don't mind me pointing above.
Thanks for your time.
> 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
>
> [~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)
