[
https://issues.apache.org/jira/browse/ARTEMIS-2984?focusedWorklogId=511238&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-511238
]
ASF GitHub Bot logged work on ARTEMIS-2984:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 13/Nov/20 07:01
Start Date: 13/Nov/20 07:01
Worklog Time Spent: 10m
Work Description: franz1981 edited a comment on pull request #3334:
URL: https://github.com/apache/activemq-artemis/pull/3334#issuecomment-726563545
@clebertsuconic I'm reworking on this to save users to break their
expectations but I see some interesting things that could improve large message
streaming, see:
```java
private byte getByte(final long index) {
checkForPacket(index);
if (fileCache != null && index < packetPosition) {
return fileCache.getByteFromCache(index);
} else {
return currentPacket.getChunk()[(int) (index - packetPosition)];
}
}
```
This method is the only one using `FileCache` to read data as part of the
`ActiveMQBuffer` API on large messages, that's internal.
Large message streaming is slowed down (and get some additional memory
footprint increase too) by the `FileCache` presence, because it needs to save
each incoming chunk into it as well, but if users won't read it it's just
useless work...
----------------------------------------------------------------
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: 511238)
Time Spent: 1h 40m (was: 1.5h)
> 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: 1h 40m
> 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)
