[ARTEMIS-5134] Incorrect address size calculated due to a race condition in AMQP application properties decode process

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 2.36.0, 2.37.0, 2.38.0
• Component/s: AMQP
• Assignee: Unassigned
• Reporter: Jean-Pascal Briquet
• Created: 28/Oct/24 16:25
• Updated: 28/Oct/24 16:25

Description

Configuration:

• Artemis cluster with queue paging enabled, CORE and AMQP protocols enabled and mirroring.
• Artemis plugin that retrieves a message's application property in the afterSend() method for logging purpose.

 

When the problem occurs:

• The address size has still a residual value even when empty.
• The address size gradually increases and can exceed the max-size-bytes limit, causing Artemis to start paging.
• Initially, the issue was detected on the $ACTIVEMQ_ARTEMIS_MIRROR_ address but appears to occur in standard produce/consume scenario as well.
• When a message arrives in the queue, paging is enabled, then stops immediately after the message is consumed.

 

Reproduction:
I didn't find a way to slow down the "lazyDecodeApplicationProperties" method.
However, adding a Thread.sleep as follow in the AMQPMessage class help to replicate the issue:

   protected ApplicationProperties lazyDecodeApplicationProperties(ReadableBuffer data) {
      if (applicationProperties == null && applicationPropertiesPosition != VALUE_NOT_PRESENT) {
          try {
              Thread.sleep(10);
          } catch (InterruptedException e) {
              throw new RuntimeException(e);
          }
          applicationProperties = scanForMessageSection(data, applicationPropertiesPosition, ApplicationProperties.class);
    ... 

Finally, run the provided test case from "tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/plugin".