You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Devriendt, Erik" <er...@siemens.com.INVALID> on 2024/06/17 09:16:23 UTC
Issue with TTL of received AMQP messages
We stumbled on an issue in Artemis with the handling of the TTL field of received AMQP.
Our Artemis instance has a AMQP broker connection to a IBM MQ broker and receives messages forwarded by that IBM MQ broker.
If the IBM client does not provide a specific TTL for a message, IBM MQ by default sets the TTL of the AMQP message to the maximum value.
Given that AMQP standard TTL is defined as an ‘uint’, that max value is 0xFFFFFFFF.
However, Artemis considers these messages as expired.
This is probably caused by the line
expiration = System.currentTimeMillis() + header.getTtl().intValue();
in /protocol/amqp/broker/AMQPMessage.java
The intValue() method returns int value and probably converts 0xFFFFFFFF to decimal -1, leading to a expiration value 1 millisecond in the past.
I guess that using the method longValue() instead of intValue() would solve the issue.
Kind regards
Erik Devriendt
Re: Issue with TTL of received AMQP messages
Posted by Timothy Bish <ta...@gmail.com>.
On 6/17/24 05:16, Devriendt, Erik wrote:
> We stumbled on an issue in Artemis with the handling of the TTL field of received AMQP.
> Our Artemis instance has a AMQP broker connection to a IBM MQ broker and receives messages forwarded by that IBM MQ broker.
> If the IBM client does not provide a specific TTL for a message, IBM MQ by default sets the TTL of the AMQP message to the maximum value.
> Given that AMQP standard TTL is defined as an ‘uint’, that max value is 0xFFFFFFFF.
> However, Artemis considers these messages as expired.
> This is probably caused by the line
> expiration = System.currentTimeMillis() + header.getTtl().intValue();
> in /protocol/amqp/broker/AMQPMessage.java
>
> The intValue() method returns int value and probably converts 0xFFFFFFFF to decimal -1, leading to a expiration value 1 millisecond in the past.
>
> I guess that using the method longValue() instead of intValue() would solve the issue.
>
> Kind regards
>
> Erik Devriendt
This was addressed as part of
https://issues.apache.org/jira/browse/ARTEMIS-4820 and will be included
in the next release.
--
Tim Bish
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
Re: Issue with TTL of received AMQP messages
Posted by Justin Bertram <jb...@apache.org>.
ARTEMIS-4820 [1] has been opened for this issue.
Justin
[1] https://issues.apache.org/jira/browse/ARTEMIS-4820
On Mon, Jun 17, 2024 at 4:18 AM Devriendt, Erik
<er...@siemens.com.invalid> wrote:
> We stumbled on an issue in Artemis with the handling of the TTL field of
> received AMQP.
> Our Artemis instance has a AMQP broker connection to a IBM MQ broker and
> receives messages forwarded by that IBM MQ broker.
> If the IBM client does not provide a specific TTL for a message, IBM MQ by
> default sets the TTL of the AMQP message to the maximum value.
> Given that AMQP standard TTL is defined as an ‘uint’, that max value is
> 0xFFFFFFFF.
> However, Artemis considers these messages as expired.
> This is probably caused by the line
> expiration = System.currentTimeMillis() + header.getTtl().intValue();
> in /protocol/amqp/broker/AMQPMessage.java
>
> The intValue() method returns int value and probably converts 0xFFFFFFFF
> to decimal -1, leading to a expiration value 1 millisecond in the past.
>
> I guess that using the method longValue() instead of intValue() would
> solve the issue.
>
> Kind regards
>
> Erik Devriendt
>