[
https://issues.apache.org/jira/browse/ARTEMIS-5573?focusedWorklogId=1012967&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1012967
]
ASF GitHub Bot logged work on ARTEMIS-5573:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 02/Apr/26 13:30
Start Date: 02/Apr/26 13:30
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #6323:
URL: https://github.com/apache/artemis/pull/6323#discussion_r3028066244
##########
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPStandardMessage.java:
##########
@@ -237,79 +240,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);
modified = false;
- messageDataScanned = MessageDataScanningStatus.RELOAD_PERSISTENCE.code;
Review Comment:
There was a case where the broker had a lot of data.. but it had a lot of
data because the estimate was under estimated in the first place..
And I don't think we are actually decoding messages.. just parsing the
locations of the application properties.
also I think at some point we were actually decoding application properties
during reload.
It would be great to not have to do this on reload, but the estimates
wouldn't match after reload what could affect further producing messages.
I would rather do it this new way.
Issue Time Tracking
-------------------
Worklog Id: (was: 1012967)
Time Spent: 1h (was: 50m)
> 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: 1h
> 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]
