[
https://issues.apache.org/jira/browse/AMQ-8412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487239#comment-17487239
]
Christopher L. Shannon commented on AMQ-8412:
---------------------------------------------
[~mattrpav] - I misread the commit initially, I see that the error is thrown on
the client side before the client even tries the send so it's using the
estimated size in the sync send to compare to the maxFrameSize. So in this case
keeping open the connection is probably fine if the client wants to handle it.
Preventing the client from even sending the message at all if too large in the
first place is an interesting idea but I see a couple potential issues.
1) The getSize() method estimates the true size and is not exact so there could
be slightly different results depending on the message type and isn't going to
exactly match the true frame size when marshaled. So this could cause
inconsistent behavior and would need to be tested.
2) The other issue is this only applies to sync send so now async send is
different. We get into a scenario where sync fails fast but async doesn't which
could lead to a little bit of confusion.
In terms of the test failure from AMQ-8183, that is because the test just uses
maxFrameSize to create the error condition (connection closing causing the
infinite loop). So if we make this change the test would need to be re-written
to try and cause the same error using a different method (I can look into it
more) or maybe I can override the send method in the client just for that test
to send the message anyways to trigger the broker error. I'll take a look.
> 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)
