[
https://issues.apache.org/jira/browse/ARTEMIS-5573?focusedWorklogId=1013862&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1013862
]
ASF GitHub Bot logged work on ARTEMIS-5573:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 07/Apr/26 20:09
Start Date: 07/Apr/26 20:09
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #6323:
URL: https://github.com/apache/artemis/pull/6323#discussion_r3047599302
##########
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessage.java:
##########
@@ -759,6 +743,44 @@ protected synchronized void scanMessageData(ReadableBuffer
data) {
this.messageDataScanned = MessageDataScanningStatus.SCANNED.code;
}
+ public int getApplicationPropertiesCount() {
+ ensureScanning();
+ return applicationPropertiesCount;
+ }
+
+
+ // this is "borrowed" from:
+ //
https://github.com/apache/qpid-proton-j/blob/6dc5587f1d1b23969a8994f1755198e638e92bc4/proton-j/src/main/java/org/apache/qpid/proton/codec/messaging/FastPathApplicationPropertiesType.java#L93-L115
Review Comment:
I'm saying this does no validation on the data it reads, such as checking
that the size value is smaller than the data remaining or on enforcing that the
count is actually divisible by two which could indicate that the payload is
corrupt if it isn't. I know proton-j does check at least the size data or
maybe it checks that count isn't large than the data remaining in the buffer.
My point is that some validation might be sensible here to ensure valid data
is being used up front.
Issue Time Tracking
-------------------
Worklog Id: (was: 1013862)
Time Spent: 3h 50m (was: 3h 40m)
> 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: 3h 50m
> 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]
