[
https://issues.apache.org/jira/browse/ARTEMIS-5573?focusedWorklogId=1013861&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1013861
]
ASF GitHub Bot logged work on ARTEMIS-5573:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 07/Apr/26 20:06
Start Date: 07/Apr/26 20:06
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #6323:
URL: https://github.com/apache/artemis/pull/6323#discussion_r3047585459
##########
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPStandardMessage.java:
##########
@@ -237,79 +238,10 @@ public void reloadPersistence(ActiveMQBuffer record,
CoreMessageObjectPools pool
// Message state is now that the underlying buffer is loaded, but the
contents not yet scanned
resetMessageData();
- recoverHeaderDataFromEncoding();
+ scanMessageData(data);
Review Comment:
I'm pretty sure there is more options here than scanning and decoding the
nearly full message data to get at the value needed from application properties
(and the header as was done before) to initialize a message from storage that
would reap the same values to provide a memory estimate that was stable between
a simple pre-scan and a full read.
I know that we changed all this for the very sake of not requiring a full
re-scan of every message on start from a users very large data store so I can
see how adding that all back in is a great idea now.
Issue Time Tracking
-------------------
Worklog Id: (was: 1013861)
Time Spent: 3h 40m (was: 3.5h)
> 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 40m
> 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]
