[
https://issues.apache.org/jira/browse/AMQ-5774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14542480#comment-14542480
]
Timothy Bish commented on AMQ-5774:
-----------------------------------
The idea behind the maxFrameSize option is to abort the read of the incoming
protocol command prior to reading the full payload into memory which defeats
the purpose of the check as it allows for a single message to consume a large
portion of memory prior to checking and rejecting that message.
OpenWire does not do chunking and it encodes the size as a header on each
command so a single message is always encoded in one "frame" such that the
maximum value can be applied prior to any unmarshaling which is preferable in
this context to reading in the and unmarshaling the full message which would
have to be done before your patch can check message size.
The other transports can and should do something similar when possible.
STOMP: Since STOMP does not encode a frame size option in front of the STOMP
command it is a bit trickier to deal with, there is an options content-length
header but it is not required. I think there is currently some code in there
to check a maximum data length value but I'm not sure if checks the overall
command against a configured maxFrameSize, it probably should be if its not.
It could check the current number of read bytes from the wire against the
maxFrameSize and also check the content-length header to abort the command
unmarshal.
MQTT: The protocol itself has a built in max for each command of around 260MB
the maxFrameSize could be used here to enforce a lower boundary than that if we
wanted to as each MQTT Command has an encoded size value much like openwire
does and enforce it prior to reading the full message from the wire.
AMQP: The AMQP transport currently does enforce maxFrameSize in a manner
similar to openwire for the NIO and NIO+SSL transports at least, would need to
confirm the other cases. There is a second option there maxAmqpFrameSize that
control how large a single frame is and messages are chunked if that value
would be exceeded so some more checks might be needed to enforce the overall
maximum.
The fix you've attempted here actually can miss and allow a larger than
expected message through the transport because the getSize value in the
OpenWire Message class only uses the marshalled properties size and the content
length size but for instances that are created from other protocols such as
STOMP or AMQP there would be no marshalled properties, they would have been
populated in the unmarshaled map during the conversion so you could sneak in a
ton of message properties to bloat message size and circumvent that check.
So I think the right solution here is to implement and test the maxFrameSize
across the protocols instead of introducing yet another configuration option.
> Add maximum message size per transport
> --------------------------------------
>
> Key: AMQ-5774
> URL: https://issues.apache.org/jira/browse/AMQ-5774
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Broker
> Affects Versions: 5.11.1
> Reporter: Christopher L. Shannon
> Priority: Minor
>
> It would be useful to be able to configure a limit for the maximum size per
> message that can be sent by a client per transport. This will help prevent
> bad behaving clients from affecting the performance of the broker.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
