[
https://issues.apache.org/jira/browse/AMQ-8412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487295#comment-17487295
]
Christopher L. Shannon edited comment on AMQ-8412 at 2/4/22, 8:28 PM:
----------------------------------------------------------------------
I created a patch here
[https://github.com/cshannon/activemq/tree/verifyMaxFrameSizeEnabledFlag]
It does the following:
# Creates a new verifyMaxFrameSizeEnabled flag to disable the new behavior
# Fixes the broken test from AMQ-8183 using the flag
# Adds a new unit test class to run through different transports to verify the
flag works both on and off
Unfortunately I'm seeing behavior after testing that leads me to think this may
not be something we can enable, at least by default. There are a couple issues
I noticed which you will see if you run the test.
# Issue one is that the reported size when the client detects it is about
twice as large as the frame size the broker detects. This is what I mentioned
earlier about it being an estimate and this is a big problem as suddenly
working producers may break on messages close to the size limit. Part of this
is probably because Openwire can do some smart encoding and shrink the size a
bit.
# This gets even worse when compression is enabled. I enabled compression (the
test currently has it turned on) and the reported size goes to about 1/4 of the
size of the client. The client was reporting about 100kb vs 24kb when the
broker detected the error.
# Issue 3 isn't a problem with the patch itself but the fact that just a
general comment that asyncSend is still not going to be fail fast with this
patch so the behavior is inconsistent which is weird and makes me a bit un-easy
including this. (I mentioned this in my previous comment)
was (Author: christopher.l.shannon):
I created a patch here
[https://github.com/cshannon/activemq/tree/verifyMaxFrameSizeEnabledFlag]
It does the following:
# Creates a new verifyMaxFrameSizeEnabled flag to disable the new behavior
# Fixes the broken test from AMQ-8183 using the flag
# Adds a new unit test class to run through different transports to verify the
flag works both on and off
Unfortunately I'm seeing behavior after testing that leads me to think this may
not be something we can enable, at least by default. There are a couple issues
I noticed which you will see if you run the test.
# Issue one is that the reported size when the client detects it is about
twice as large as the frame size the broker detects. This is what I mentioned
earlier about it being an estimate and this is a big problem as suddenly
working producers may break on messages close to the size limit. Part of this
is probably because Openwire can do some smart encoding and shrink the size a
bit.
# This gets even worse when compression is enabled. I enabled compression (the
test currently has it turned on) and the reported size goes to about 1/4 of the
size of the client. The client was reporting about 100kb vs 24kb when the
broker detected the error.
> Return a well-formed response to clients when max message size is sent
> ----------------------------------------------------------------------
>
> Key: AMQ-8412
> URL: https://issues.apache.org/jira/browse/AMQ-8412
> Project: ActiveMQ
> Issue Type: New Feature
> Components: JMS client
> Reporter: Matt Pavlovich
> Assignee: Jean-Baptiste Onofré
> Priority: Major
> Fix For: 5.17.0, 5.16.4
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, clients get an inconclusive exception when a message that is too
> large is sent. We should send a well-formed message, and then close.
> Options:
> 1. Change the current IOException to something else to fall within existing
> exception flow
> 2. Update current exception handling to send ExceptionResponse w/ the max
> message size message to the client before closing
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
