[
https://issues.apache.org/jira/browse/ARTEMIS-5573?focusedWorklogId=1013856&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1013856
]
ASF GitHub Bot logged work on ARTEMIS-5573:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 07/Apr/26 19:52
Start Date: 07/Apr/26 19:52
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #6323:
URL: https://github.com/apache/artemis/pull/6323#discussion_r3047510945
##########
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:
@tabish121 this is being called right after the readConstructor was read.
the only thing that would be decoded would be either this, or the skipValue()
which is doing pretty much the same as this code is doing now.
I'm confused on what are you asking
Issue Time Tracking
-------------------
Worklog Id: (was: 1013856)
Time Spent: 3h 20m (was: 3h 10m)
> 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 20m
> 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]
