[
https://issues.apache.org/jira/browse/ARTEMIS-5573?focusedWorklogId=1015284&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1015284
]
ASF GitHub Bot logged work on ARTEMIS-5573:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 13/Apr/26 22:24
Start Date: 13/Apr/26 22:24
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #6323:
URL: https://github.com/apache/artemis/pull/6323#discussion_r3076152952
##########
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPStandardMessage.java:
##########
@@ -191,20 +187,25 @@ protected ReadableBuffer getData() {
@Override
public synchronized int getMemoryEstimate() {
- if (memoryEstimate == -1) {
- if (isPaged) {
- // When the message is paged, we don't take the unmarshalled
application properties because it could be
- // updated at different places. We just keep the estimate simple
when paging.
- memoryEstimate = memoryOffset + (data != null ? data.capacity() :
0);
- } else {
- memoryEstimate = memoryOffset + (data != null ? data.capacity() +
unmarshalledApplicationPropertiesMemoryEstimateFromData(data) : 0);
- }
- originalEstimate = memoryEstimate;
+ if (memoryEstimate == VALUE_NOT_PRESENT) {
+ // This estimation was tested and validated through AMQPGlobalMaxTest
on soak-tests
+ memoryEstimate = MINIMUM_ESTIMATE + (data != null ? data.capacity() +
getApplicationPropertiesEncodingSize(data) * 2 +
getApplicationPropertiesCount() * DataConstants.SIZE_INT : 0);
}
return memoryEstimate;
}
+ private int getApplicationPropertiesEncodingSize(ReadableBuffer data) {
+ ensureScanning();
+
+ // ensureScanning will make sure we know the positions, and we will
return the encoding used based on those positions
+ if (remainingBodyPosition != VALUE_NOT_PRESENT) {
Review Comment:
This method still seems wrong, consider a Message that has sections for
Header, DeliveryAnnotations and MessageAnnotations but no ApplicationProperties
or a Body section, then it would return the buffer capacity - (-1) which is not
the encoding size of ApplicationProperties as there are none. The
getMemoryEstimate() method then adds that value to the base estimate plug the
buffer capacity again leaving with a likely overly large estimate of the
message size.
Add the following test to AMQPMessageTest to see what I mean
```
diff --git
a/artemis-protocols/artemis-amqp-protocol/src/test/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessageTest.java
b/artemis-protocols/artemis-amqp-protocol/src/test/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessageTest.java
index 8a10f33ce0..4a5c1d9c01 100644
-
Issue Time Tracking
-------------------
Worklog Id: (was: 1015284)
Time Spent: 9h 10m (was: 9h)
> Make AMQP Size immutable
> ------------------------
>
> Key: ARTEMIS-5573
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5573
> Project: Artemis
> Issue Type: Improvement
> Components: AMQP
> Affects Versions: 2.41.0
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Labels: pull-request-available
> Time Spent: 9h 10m
> Remaining Estimate: 0h
>
> I have had a lot of issues, even recently on races between re-evaluating a
> message size in AMQP.
> Say a lazy decode happens at the wrong time and the memory estimates can be
> wrong.
> We have fixed issues along the years, but this is still a fragile process
> that is bound to fail. If an user for instance add a plugin breaking the
> chain of events.
> For that reason the memory estimate should already include enough estimation
> for any properties decoded and the process should be simplified.
> Less moving parts would mean less possibilities for bugs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
