[
https://issues.apache.org/jira/browse/ARTEMIS-2984?focusedWorklogId=514980&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-514980
]
ASF GitHub Bot logged work on ARTEMIS-2984:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 21/Nov/20 07:25
Start Date: 21/Nov/20 07:25
Worklog Time Spent: 10m
Work Description: franz1981 commented on pull request #3334:
URL: https://github.com/apache/activemq-artemis/pull/3334#issuecomment-731522286
@michaelandrepearce @clebertsuconic If we take the step to remove it I'm
sure large message streaming can just drop any file cache and both code and
perf will benefit there
> what about the previous propose? to make the usage separate? we break the
API but allow an alternative?
If the usage wasn't exposed to remove the whole code paths that makes large
msg streaming complex, saving both perf and leaky methods to exists as a whole.
If removing isn't an option I can just prepare the code for a future removal,
when we decide to do that, but we won't get any perf and stability benefits
from removing it.
Adding a separate class to perform the read still won't allow me to remove
the FileCache, so no perf benefits...
----------------------------------------------------------------
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: 514980)
Time Spent: 3h 20m (was: 3h 10m)
> Compressed large messages can leak native resources
> ---------------------------------------------------
>
> Key: ARTEMIS-2984
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2984
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Compressed large messages use native resources in the form of Inflater and
> Deflater and should release them in a timely manner (instead of relying on
> finalization) to save OOM to happen (of direct memory, to be precise).
> This issue has the chance to simplify large message controllers, because much
> of the existing code on controllers (including compressed one) isn't needed
> at runtime, but just for testing purposes and a proper fix can move dead code
> there too, saving leaky behavior to be maintained.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
