Re: OutOfMemory encountered in Artemis CoreAmqpConverter

[Dirkjan Ochtman <di...@ochtman.nl>]

On Fri, Mar 27, 2020 at 8:45 PM Timothy Bish <ta...@gmail.com> wrote:

> I'd suggest trying with Artemis 2.11.0 as the version you are on is
> quite old and there have been many AMQP bug fixes since then that could
> account for some issues you are seeing.
>

That's fair. :) I forked the product that includes the server to upgrade
Artemis to 2.11.0 and was able to get a proper response now.

However, this took some time to debug because of a particular change that I
hadn't expected: it appears that the JMSReplyTo property now gets prefixed
with "queue://" for AMQP messages (but not for Core messages). This seems
fairly surprising -- the server product I'm working with failed to work
correctly because this reply to address doesn't match the BINDING_ADDED
notification's `name`. Is this intended behavior?

Kind regards,

Dirkjan

Re: OutOfMemory encountered in Artemis CoreAmqpConverter

[Dirkjan Ochtman <di...@ochtman.nl>]

On Fri, Apr 3, 2020 at 1:49 PM Dirkjan Ochtman <di...@ochtman.nl> wrote:

> On Thu, Apr 2, 2020 at 1:27 PM Dirkjan Ochtman <di...@ochtman.nl> wrote:
>
>> However, this took some time to debug because of a particular change that
>> I hadn't expected: it appears that the JMSReplyTo property now gets
>> prefixed with "queue://" for AMQP messages (but not for Core messages).
>> This seems fairly surprising -- the server product I'm working with failed
>> to work correctly because this reply to address doesn't match the
>> BINDING_ADDED notification's `name`. Is this intended behavior?
>>
>
> Actually, I spoke too soon. After stripping the weird "queue://" prefix
> and decoding the returned message, it turns out to contain the message
> "Conversion to AMQP error!". The ignored exception that triggers this is an
> IndexOutOfBoundsException with detailMessage "Error reading in
> simpleString, length=1869767777 is greater than readableBytes=9200", so it
> seems that there is still a similar problem
>

It seems the issue here is that the CoreAmqpConverter wants to encode
messages as a string value body by default. This seems like a surprising
default to me, but it was easily worked around by setting the ClientMessage
type to BYTES_TYPE.


> (also, it might be nice to splice the exception message in the AMQP
> response directly).
>

Created https://github.com/apache/activemq-artemis/pull/3060 for this.

Kind regards,

Dirkjan

Re: OutOfMemory encountered in Artemis CoreAmqpConverter

[Dirkjan Ochtman <di...@ochtman.nl>]

On Thu, Apr 2, 2020 at 1:27 PM Dirkjan Ochtman <di...@ochtman.nl> wrote:

> On Fri, Mar 27, 2020 at 8:45 PM Timothy Bish <ta...@gmail.com> wrote:
>
>> I'd suggest trying with Artemis 2.11.0 as the version you are on is
>> quite old and there have been many AMQP bug fixes since then that could
>> account for some issues you are seeing.
>>
>
> That's fair. :) I forked the product that includes the server to upgrade
> Artemis to 2.11.0 and was able to get a proper response now.
>
> However, this took some time to debug because of a particular change that
> I hadn't expected: it appears that the JMSReplyTo property now gets
> prefixed with "queue://" for AMQP messages (but not for Core messages).
> This seems fairly surprising -- the server product I'm working with failed
> to work correctly because this reply to address doesn't match the
> BINDING_ADDED notification's `name`. Is this intended behavior?
>

Actually, I spoke too soon. After stripping the weird "queue://" prefix and
decoding the returned message, it turns out to contain the message
"Conversion to AMQP error!". The ignored exception that triggers this is an
IndexOutOfBoundsException with detailMessage "Error reading in
simpleString, length=1869767777 is greater than readableBytes=9200", so it
seems that there is still a similar problem (also, it might be nice to
splice the exception message in the AMQP response directly).

Kind regards,

Dirkjan