[
https://issues.apache.org/jira/browse/ARTEMIS-3021?focusedWorklogId=538624&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-538624
]
ASF GitHub Bot logged work on ARTEMIS-3021:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 20/Jan/21 19:16
Start Date: 20/Jan/21 19:16
Worklog Time Spent: 10m
Work Description: franz1981 commented on pull request #3370:
URL: https://github.com/apache/activemq-artemis/pull/3370#issuecomment-763872471
@clebertsuconic @jbertram
I see that we've some concurrency issue on `TypedProperties`:
```
org.apache.activemq.artemis.core.protocol.hornetq.PropertiesConversionTest.testMultiThreadChanges
org.apache.activemq.artemis.tests.compatibility.HornetQSoakTest.testSoakHornetQ
on
testSoakHornetQ(org.apache.activemq.artemis.tests.compatibility.HornetQSoakTest)
org.apache.activemq.artemis.tests.integration.cluster.failover.ReplicatedMultipleServerFailoverExtraBackupsTest.testStartLiveFirst
```
These tests were failing with my first version of PR that was enabling some
strict assertion to check for concurrent modification of `TypedProperty` during
`CoreMessage::encode` calls.
I believe the change I've made here to replaced the assert with a debug log
is masking a real (rare) issue. wdyt?
----------------------------------------------------------------
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: 538624)
Time Spent: 1h 50m (was: 1h 40m)
> 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: 1h 50m
> 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
> * save the buffer growth using the default Netty's ByteBuf::ensureWritable
> strategy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
