[
https://issues.apache.org/jira/browse/CASSANDRA-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15880:
---------------------------------------
Fix Version/s: (was: 4.0-triage)
(was: 3.11.x)
(was: 4.0)
4.0-beta3
3.11.9
Source Control Link:
https://github.com/apache/cassandra/commit/3f73c16d50a80c574dd004c59bfaa6042dcd5781
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
The patch was committed into cassandra-3.11 at
3f73c16d50a80c574dd004c59bfaa6042dcd5781 and merged into trunk
> Memory leak in CompressedChunkReader
> ------------------------------------
>
> Key: CASSANDRA-15880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15880
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Compression
> Reporter: Jaroslaw Grabowski
> Assignee: Berenguer Blasi
> Priority: Normal
> Fix For: 3.11.9, 4.0-beta3
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> CompressedChunkReader uses java.lang.ThreadLocal to reuse ByteBuffer for
> compressed data. ByteBuffers leak due to peculiar ThreadLocal quality.
> ThreadLocals are stored in a map, where the key is a weak reference to a
> ThreadLocal and the value is the user's object (ByteBuffer in this case).
> When a last strong reference to a ThreadLocal is lost, weak reference to
> ThreadLocal (key) is removed but the value (ByteBuffer) is kept until cleaned
> by ThreadLocal heuristic expunge mechanism. See ThreadLocal's "stale entries"
> for details.
> When a number of long-living threads is high enough this results in thousands
> of ByteBuffers stored as stale entries in ThreadLocals. In a not-so-lucky
> scenario we get OutOfMemoryException.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
