[jira] [Resolved] (ARTEMIS-3264) Core to AMQP conversion error causes client disconnect

["Justin Bertram (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARTEMIS-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Bertram resolved ARTEMIS-3264.
-------------------------------------
    Fix Version/s: 2.27.0
       Resolution: Fixed

> Core to AMQP conversion error causes client disconnect
> ------------------------------------------------------
>
>                 Key: ARTEMIS-3264
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-3264
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: AMQP, Broker
>    Affects Versions: 2.17.0
>         Environment: Embedded Apache Artemis 2.17.0
> Windows Server 2016 Standard (10.0.14393)
> Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
>            Reporter: Christian Danner
>            Assignee: Justin Bertram
>            Priority: Critical
>             Fix For: 2.27.0
>
>         Attachments: activemq_artemis.log
>
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> We are deploying a mesh of embedded brokers and per default use core bridges to replicate data between different broker instances / topics.
> The clients that actually consume messages are connected using AMQP (QPID, AMQP .Net Lite)
> Recently we encountered a situation where the broker could not deliver a message to a (Java QPID) client because the internal conversion from Core to AMQP failed (see attached log file).
> This had the effect that the client got disconnected and did not receive any messages anymore at all (it was stuck in a JMS receive call and obviously was not informed about disconnect - not sure if this is a QPID/Proton issue, but even after restart the client was not able to connect anymore to the server! We had to restart the server to be able to connect again!)
> We are currently working around this issue by using AMQP (i.e. JMS) as the only client side protocol to avoid that Core-AMQP conversion happens in the first place.
> However, I'm wondering if the way the broker deals with such errors is a good idea - it disconnects the client and keeps the message in the queue, so even after reconnect the delivery fails again with the same Exception!
> Looking at the call stack (ending up in QueueImpl:3800) this kind of error is handled in a very generic way - the handler method does not distinguish between different types of Exceptions and knows nothing about the reason why delivery failed, however it still defaults to disconnecting the corresponding client.
> I think in the situation described above it would be necessary to forward the erroneous message to a DLQ instead and continue with the next message. Currently the message clogs the queue and needs to be deleted / moved manually in order for processing to continue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)