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

["Ievgen Popovych (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554027#comment-17554027 ] 

Ievgen Popovych commented on ARTEMIS-3264:
------------------------------------------

In my case, with python client (QPid Proton), I did not experience disconnections, but instead message payload was somehow mangled.
So with python client, I am sending a message over AMQP, it contains something of {{Described}} type. If I receive this message directly from the broker over AMQP - it's fine and I can decode the payload as an instance of {{Described}}.
If I use federation and receive this message from another broker - client library (Qpid Proton) cannot decode message body as {{Described}}, but {{bytes}} instead.
This is probably a different bug (maybe not), but I do not have the capacity to open another issue...

> 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
>            Priority: Critical
>         Attachments: activemq_artemis.log
>
>
> 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.7#820007)