[ https://issues.apache.org/jira/browse/CASSANDRA-13033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742214#comment-15742214 ]
Jason Brown edited comment on CASSANDRA-13033 at 12/12/16 3:02 PM: ------------------------------------------------------------------- on the whole lgtm, assuming tests all pass. As a minor nit it would be great to add a javadoc comment to {{NamedThreadFactory#threadLocalDeallocator}} to explain why it's there. was (Author: jasobrown): on the whole lgtm. As a minor nit it would be great to add a javadoc comment to {{NamedThreadFactory#threadLocalDeallocator}} to explain why it's there. > Thread local pools never cleaned up > ----------------------------------- > > Key: CASSANDRA-13033 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13033 > Project: Cassandra > Issue Type: Bug > Reporter: Robert Stupp > Assignee: Robert Stupp > Fix For: 3.0.x > > > Netty 4.x uses {{(Fast)ThreadLocal}} instances to provide a pool of (direct) > buffers per thread > ({{io.netty.buffer.PooledByteBufAllocator.PoolThreadLocalCache}}. However, > these per-thread pools need to be cleaned up when a thread terminates > ({{FastThreadLocal.removeAll()}}) - which is missing. > Although the possibility that such per-thread pools ever _need_ to be cleaned > up, since we rarely terminate threads, it still may actually happen and > manifest in a late and hard to detect out-of-memory situation. One > possibility to raise such a scenario is to regularly stop and restart the > native protocol service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)