[
https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16765356#comment-16765356
]
Sumanth Pasupuleti edited comment on CASSANDRA-15013 at 2/11/19 8:18 PM:
-------------------------------------------------------------------------
[~benedict] By making the flusher queue bounded, my intention is *not* to make
the request executor blocked on enqueuing if the queue is full, rather it would
_drop_ the response if the flusher queue is full. This should avoid the
deadlock situation you are referring to, I believe.
was (Author: sumanth.pasupuleti):
[~benedict] By making the flusher queue bounded, my intention is *not* to make
the request executor blocked on enqueuing if the queue is full, rather it would
drop the response if the flusher queue is full. This should avoid the deadlock
situation you are referring to, I believe.
> 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: Major
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: 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: [email protected]
For additional commands, e-mail: [email protected]
