[jira] [Created] (ARTEMIS-2706) outgoing AMQP messages split into an unexpectedly large number of transfer frames

["Robbie Gemmell (Jira)" <ji...@apache.org>]

Robbie Gemmell created ARTEMIS-2706:
---------------------------------------

             Summary: outgoing AMQP messages split into an unexpectedly large number of transfer frames
                 Key: ARTEMIS-2706
                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2706
             Project: ActiveMQ Artemis
          Issue Type: Bug
          Components: AMQP
    Affects Versions: 2.12.0
            Reporter: Robbie Gemmell


The broker is splitting larger messages into an unexpectedly large number of transfer frames when sending to consuming clients.

For example, on a test of sending a 1MB messsage, with the broker having advertised its own max frame size of 131072 (a limit which it also uses to govern its max outgoing frame sizes, thus not reaching the clients advertised purely-coincidental 1MB max frame size) and, the broker is seen to send transfer frames including only up to 1024 bytes of message payload at a time.

It can be seen that the message being sent by the original producer used frames with up to 131050 bytes of payload within the transfer frames, in keeping with the brokers 131072 max frame size (which includes the frame heading and performative itself):
{noformat}
[417713843:1] -> Transfer{handle=0, deliveryId=0, deliveryTag=\x00, messageFormat=0, settled=false, more=true, rcvSettleMode=null, state=null, resume=false, aborted=false, batchable=false} (131050) "\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x03\x00Ss\xd0\x00\x00\x00r\x00\x00\x00\x0a\xa1/ID:947e3b66-0d17-4492-8d34-de9050aa1533:1:1:1-1@\xa1\x12testSend1MBMessage@@@\xa3\x18application/octet-stream@@\x83\x00\x00\x01qt\x0b\xe2\x86\x00Su\xb0\x00\x10\x00\x00\x98"\xeb\xfd\x84\xe0\xf8\xb0m9S\x97\xb4\x85iZ_\xa2~\x0e\x00B\x87\x9f\xa46\xe2\xfc\xd0\x9c\xf25[H\x82\x1f3x'\xcf\x0f\xab\x0fq0U^b\x1b\xd2d\x1c\xdcG\xcdLj\xf8!-\xef\xb0nP\x04y\xf7\xb8\xaa\x0d\x09\x83\xba\xd57\xef.\xb1\x1aM\xb9#\xdc\x09\xa5\xa1\xacC\xe1\x18\x14Bln\xcfSu \xc3\x1b\xd73\xad\xe1A\x81\x17\x13V\xaf\xa9\xa6G\xe1\x82Y{\xcd\x07\xfd\xdb\x11\xf2\xbe\xe6\xbd\xf4\xe9Xr\x18\x00\x12:\x88\xa1\xd0\xe5\xe3\xc1\xe5l\x9c\x8c\x99\xb6&\x01'p\xdb\xb8*\xa3\x87\xb2*on\x8f\x82\xa5j\xfc\xa8\xbd<\x06E\xe9\x888\x1d\x8e1\x17\xc3\x0cH1\x14]\x9f.ZU\xc2\x0eiG\x12T\x16\x99z\xab\xee5=r\xe6\x08\x9cZ\xde\xee\xe9\x93\x86#Y\xef$\xd8\xc9,\x04\xcf\xad\xed\xdeh<\xac\xe4\x82n\xf1k\x16\xcb3\xf0E\xf6 \xf5\xf0 \x04=g;#\xc1\xaf\xdb\xaa=\x93Bi^\xb0N\xd2\x83\x05`"...(truncated)
{noformat}

The same message going back out to the consumer, only uses 1024 bytes of payload despite the brokers 131072 max frame size (which it applis to outgoing frames too) being the governing limit in the scenario:
{noformat}
[1933829960:1] -> Transfer{handle=1, deliveryId=0, deliveryTag=\x00, messageFormat=0, settled=false, more=true, rcvSettleMode=null, state=null, resume=false, aborted=false, batchable=false} (1024) "\x00Sr\xc1)\x04\xa3\x0ex-opt-jms-destQ\x00\xa3\x12x-opt-jms-msg-typeQ\x03\x00Ss\xd0\x00\x00\x00r\x00\x00\x00\x0a\xa1/ID:947e3b66-0d17-4492-8d34-de9050aa1533:1:1:1-1@\xa1\x12testSend1MBMessage@@@\xa3\x18application/octet-stream@@\x83\x00\x00\x01qt\x0b\xe2\x86\x00Su\xb0\x00\x10\x00\x00\x98"\xeb\xfd\x84\xe0\xf8\xb0m9S\x97\xb4\x85iZ_\xa2~\x0e\x00B\x87\x9f\xa46\xe2\xfc\xd0\x9c\xf25[H\x82\x1f3x'\xcf\x0f\xab\x0fq0U^b\x1b\xd2d\x1c\xdcG\xcdLj\xf8!-\xef\xb0nP\x04y\xf7\xb8\xaa\x0d\x09\x83\xba\xd57\xef.\xb1\x1aM\xb9#\xdc\x09\xa5\xa1\xacC\xe1\x18\x14Bln\xcfSu \xc3\x1b\xd73\xad\xe1A\x81\x17\x13V\xaf\xa9\xa6G\xe1\x82Y{\xcd\x07\xfd\xdb\x11\xf2\xbe\xe6\xbd\xf4\xe9Xr\x18\x00\x12:\x88\xa1\xd0\xe5\xe3\xc1\xe5l\x9c\x8c\x99\xb6&\x01'p\xdb\xb8*\xa3\x87\xb2*on\x8f\x82\xa5j\xfc\xa8\xbd<\x06E\xe9\x888\x1d\x8e1\x17\xc3\x0cH1\x14]\x9f.ZU\xc2\x0eiG\x12T\x16\x99z\xab\xee5=r\xe6\x08\x9cZ\xde\xee\xe9\x93\x86#Y\xef$\xd8\xc9,\x04\xcf\xad\xed\xdeh<\xac\xe4\x82n\xf1k\x16\xcb3\xf0E\xf6 \xf5\xf0 \x04=g;#\xc1\xaf\xdb\xaa=\x93Bi^\xb0N\xd2\x83\x05`"...(truncated)
{noformat}

Whilst this is legal protocol behaviour it is fairly unexpected, and could be rather inefficient depending on the size of the message and a receiving clients behaviour reconstituting the completed message.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)