You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Timothy A. Bish (Jira)" <ji...@apache.org> on 2023/04/04 18:30:00 UTC

[jira] [Comment Edited] (ARTEMIS-4235) Losing bridge connection when sending map message.

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

Timothy A. Bish edited comment on ARTEMIS-4235 at 4/4/23 6:29 PM:
------------------------------------------------------------------

This happens because in openwire if the Map portion of the MapMessage is empty nothing is sent for that section of the message which is fine as it is the trailing section so the decoder for openwire simply checks if the content section is null which it will be as the marshalling code will just stop at the end of the encoded byte stream.  

Since this occurs post conversion to core then I'd guess one of two things could fix it, either the convert from Openwire to core can write the DataConstants.NULL as the payload which should stop the TypeProperties from reading further then that, or the TypeProperties could be update to handle nothing in the body at all which is probably a less desirable behavioral change.


was (Author: tabish121):
This happens because in openwire if the Map portion of the MapMessage is empty nothing is sent for that section of the message which is fine as it is the trailing section so the decoder for openwire simply checks if the content section is null which it will be as the marshalling code will just stop at the end of the encoded byte stream.  The Artemis code needs to check the buffer to see if it is readable and if not then just stop.

> Losing bridge connection when sending map message.
> --------------------------------------------------
>
>                 Key: ARTEMIS-4235
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-4235
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 2.27.0
>         Environment: Windows 10
>            Reporter: Peter Sunnerdahl
>            Priority: Critical
>         Attachments: TestMQ.java, broker.xml, testMQMap.xml
>
>
> Artemis 2.27.0 installations with a bridge configured. When sending a map message with an empty map the message is sent to DLQ and the connection is lost. It will not recover unless I delete the message and restarts the service. Same testcase works on old ActiveMQ. Found this when upgrading.
> {noformat}
> 2023-04-03 14:17:59,339 WARN  [org.apache.activemq.artemis.protocol.amqp.logger] AMQ111005: Failed to convert message. Sending it to Dead Letter Address.
> org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.ConversionException: readerIndex(0) + length(1) exceeds writerIndex(0): ReadOnlyByteBuf(ridx: 0, widx: 0, cap: 0/0, unwrapped: UnpooledSlicedByteBuf(ridx: 0, widx: 0, cap: 0/0, unwrapped: UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx: 1096, cap: 1096)))
>     at org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:319) ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
>     at org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:80) ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
>     at org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.executeDelivery(ProtonServerSenderContext.java:541) ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
>     at org.apache.activemq.artemis.core.server.impl.MessageReferenceImpl.run(MessageReferenceImpl.java:134) ~[artemis-server-2.27.0.jar:2.27.0]
>     at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
>     at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
>     at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
>     at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569) ~[netty-transport-4.1.82.Final.jar:4.1.82.Final]
>     at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
>     at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.82.Final.jar:4.1.82.Final]
>     at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) ~[artemis-commons-2.27.0.jar:?]
> Caused by: java.lang.IndexOutOfBoundsException: readerIndex(0) + length(1) exceeds writerIndex(0): ReadOnlyByteBuf(ridx: 0, widx: 0, cap: 0/0, unwrapped: UnpooledSlicedByteBuf(ridx: 0, widx: 0, cap: 0/0, unwrapped: UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx: 1096, cap: 1096)))
>     at io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442) ~[netty-buffer-4.1.82.Final.jar:4.1.82.Final]
>     at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:730) ~[netty-buffer-4.1.82.Final.jar:4.1.82.Final]
>     at io.netty.buffer.WrappedByteBuf.readByte(WrappedByteBuf.java:529) ~[netty-buffer-4.1.82.Final.jar:4.1.82.Final]
>     at org.apache.activemq.artemis.utils.collections.TypedProperties.decode(TypedProperties.java:464) ~[artemis-commons-2.27.0.jar:?]
>     at org.apache.activemq.artemis.utils.collections.TypedProperties.decode(TypedProperties.java:547) ~[artemis-commons-2.27.0.jar:?]
>     at org.apache.activemq.artemis.reader.MapMessageUtil.readBodyMap(MapMessageUtil.java:46) ~[artemis-core-client-2.27.0.jar:2.27.0]
>     at org.apache.activemq.artemis.protocol.amqp.converter.coreWrapper.CoreMapMessageWrapper.decode(CoreMapMessageWrapper.java:222) ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]
>     at org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:98) ~[artemis-amqp-protocol-2.27.0.jar:2.27.0]{noformat}



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