[
https://issues.apache.org/jira/browse/ARTEMIS-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17083629#comment-17083629
]
ASF subversion and git services commented on ARTEMIS-2706:
----------------------------------------------------------
Commit e7a437d9996464d29e63b82336d2d0eaf69e338c in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e7a437d ]
ARTEMIS-2706 Discounting Transfer payload size
> 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
> Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> 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 message, 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), 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)
