[ 
https://issues.apache.org/jira/browse/ARTEMIS-3021?focusedWorklogId=520695&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-520695
 ]

ASF GitHub Bot logged work on ARTEMIS-3021:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 06/Dec/20 10:03
            Start Date: 06/Dec/20 10:03
    Worklog Time Spent: 10m 
      Work Description: franz1981 commented on pull request #3370:
URL: https://github.com/apache/activemq-artemis/pull/3370#issuecomment-739480817


   @gemmellr I suppose that the Netty ByteBuf behaviour in case the buffer is 
enlarged can (and should) be fixed for AMQP as well:
   TLDR if you got a 32K msg and write a single byte into it, Netty will 
enlarge it to be the next power of 2 capacity ie 64K, wasting ~50% of its space 
in case the message will sit on the queue awaiting it to be sent.
   
   I've "solved" this by forcing Netty to know upfront the desired required 
capacity and use 
https://netty.io/4.0/api/io/netty/buffer/ByteBuf.html#capacity-int- to size it 
upfront.


----------------------------------------------------------------
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: 520695)
    Time Spent: 0.5h  (was: 20m)

> OOM due to wrong CORE 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: 0.5h
>  Remaining Estimate: 0h
>
> Durable CORE messages can get their internal buffer enlarged by 
> encodeHeadersAndProperties while being persisted on the journal, but the 
> address size memory estimation using the estimated memory of a message is 
> performed before that, making it less precise. 
> This bad timing estimation, together with Netty ByteBuf auto-sizing mechanism 
> can cause the broker to underestimate the message footprint, causing it to go 
> OOM. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to