[ https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874183#comment-16874183 ]
Sumanth Pasupuleti commented on CASSANDRA-15013: ------------------------------------------------ Thanks for catching the {{channelInactive}} case. lgtm. One thing remaining I suppose, is to revisit the defaults [https://github.com/apache/cassandra/commit/98126f5d887228f5e88eca66f007873b52a0aacf#diff-b66584c9ce7b64019b5db5a531deeda1R173] {code:java} // TODO: Revisit limit public volatile long native_transport_max_concurrent_requests_in_bytes_per_ip = 3000000000L; public volatile long native_transport_max_concurrent_requests_in_bytes = 5000000000L;{code} > Message Flusher queue can grow unbounded, potentially running JVM out of > memory > ------------------------------------------------------------------------------- > > Key: CASSANDRA-15013 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15013 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client > Reporter: Sumanth Pasupuleti > Assignee: Sumanth Pasupuleti > Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 3.0.x, 3.11.x > > Attachments: BlockedEpollEventLoopFromHeapDump.png, > BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap > dump showing each ImmediateFlusher taking upto 600MB.png > > > This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue > bounded, since, in the current state, items get added to the queue without > any checks on queue size, nor with any checks on netty outbound buffer to > check the isWritable state. > We are seeing this issue hit our production 3.0 clusters quite often. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org