[
https://issues.apache.org/jira/browse/ARTEMIS-2706?focusedWorklogId=422297&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-422297
]
ASF GitHub Bot logged work on ARTEMIS-2706:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 14/Apr/20 20:39
Start Date: 14/Apr/20 20:39
Worklog Time Spent: 10m
Work Description: gemmellr commented on issue #3079: ARTEMIS-2706 Use
FrameSize to decide when to flush large messages
URL: https://github.com/apache/activemq-artemis/pull/3079#issuecomment-613669789
There isnt a constant, as the encoded size of the transfer performative
varies depending on what fields are populated in it, their precise values
(since types can vary in size depending on specific value being encoded), etc.
For a different-but-related case, rhea simply deducts 50 bytes and the
length of the delivery tag when calculating a max transfer payload size
(https://github.com/amqp/rhea/blob/1.0.20/lib/session.js#L137), you could do
something similar.
As I noted before, you are just looking at the brokers configured outgoing
limit (which is just set the same as its local max frame size). The receivers
max frame size may be lower. That mattered with the earlier changes as it could
have stopped it flushing, but here the engine will just frame the content
however it needs to.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 422297)
Time Spent: 2h (was: 1h 50m)
> 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
> 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)
