[
https://issues.apache.org/jira/browse/ARTEMIS-3021?focusedWorklogId=540910&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-540910
]
ASF GitHub Bot logged work on ARTEMIS-3021:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 25/Jan/21 07:37
Start Date: 25/Jan/21 07:37
Worklog Time Spent: 10m
Work Description: franz1981 commented on pull request #3370:
URL: https://github.com/apache/activemq-artemis/pull/3370#issuecomment-766613506
Seems that writing a proper reproducer for this is hard: I can reproduce it
by hand by using a 2 nodes cluster. (upstream and downstream), a disconnected
durable subscriber on the downstream broker, 40K messages and a producer that
keep running vs the upstream one until getting the downstream broker to go OOM.
On this scenario a dump on the upstream broker shows 64KiB buffer sized core
messages ie the next available power of 2 sized one.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 540910)
Time Spent: 3h (was: 2h 50m)
> OOM due to wrong CORE clustered message memory estimation
> ---------------------------------------------------------
>
> Key: ARTEMIS-3021
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3021
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
> Time Spent: 3h
> Remaining Estimate: 0h
>
> This is affecting clustered Core messages (persistent or not).
> The process that cause the wrong estimation is:
> # add route information to the message
> # get memory estimation for paging (ie address size estimation) without
> accounting the new route information
> # get message persist size for durable append on journal/to update queue
> statistics, triggering a re-encoding
> # re-encoding (can) enlarge the message buffer to be the next power of 2
> available capacity
> The 2 fixes are:
> * getting a correct memory estimation of the message (including the added
> route information)
> * save an excessive buffer growth caused by the default Netty's
> ByteBuf::ensureWritable strategy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
