ARTEMIS-5483: New option - jmsMaxTextMessageSize

[AlexejTimonin]

Adds a new configuration option for Jakarta client consumers. When this configuration is set, the consumer will throw a javax.jms.JMSException on receiving large text(type 3) message that would exceed the specified size (in bytes) when creating javax.jms.TextMessage

jmsMaxTextMessageSize is intended to prevent consumers of javax.jms.TextMessage from crashing due to out-of-memory when receiving messages that are larger than consumers memory.

The configuration is provided as a URL property when establishing a connection to the broker.

Example:
Throw on large text messages exceeding 10MB in size: tcp://localhost:61616?jmsMaxTextMessageSize=10000000

Note:
This option relies on how core client consumer works. When message is above certain size threshold (default 100KB) it will be considered as a large message and be delivered in parts with headers first. With the help of headers we're able to determine the size of the incoming body and reject if it is above jmsMaxTextMessageSize.

If the message is below large message threshold then this option has no real defensive effect since the message will be read into memory anyway.

[jbertram]

After thinking about this for awhile I believe this problem would be better solved with a new identifier that could be used in a consumer's filter. Currently we have AMQSize, but that works on the message's "encoded" size (see here) which doesn't include the body of a large message. Adding something like AMQFullSize that used org.apache.activemq.artemis.api.core.Message#getWholeMessageSize would solve this problem. Other benefits include:

• The message wouldn't even be sent across the wire. This would save bandwidth & time.
• It would work on all protocols & clients that support filtering instead of only on the Core JMS client.
• It would allow other consumers on the queue to get the message without having to wait for it to be rejected by another consumer.

Would you be interested in modifying your PR to implement this?

[AlexejTimonin]

Thanks for getting back to me. I will modify my PR according to your suggestions.

[AlexejTimonin]

@jbertram I've made changes according to your suggestions. I agree that his approach is much better 👍

[tabish121]

Having both AMQSize and AMQFullSize is likely going to be confusing to some users without a further elaboration in the docs about what makes them distinct and why you would use one over the other when using them to filter messages.

[jbertram]

I agree with @tabish121.

@AlexejTimonin, if you don't make the doc changes I'll do it myself in a few days.

[AlexejTimonin]

Yes, it's a good point. I will get to it tomorrow.