cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13265) Epxiration in OutboundTcpConnection can block the reader Thread
Date Wed, 01 Mar 2017 19:27:46 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890865#comment-15890865
] 

Ariel Weisberg commented on CASSANDRA-13265:
--------------------------------------------

bq. This happens in the existing code already. 
That doesn't make it not a bad behavior that blocks the reader thread while it goes to do
some potentially large task that doesn't actually accomplish anything. Iterating a list with
262508 elements is not going to be very fast. The list can actually be longer now that threads
aren't going to be slowed down appending to the list by the need to iterate for expiration.

We have no way of knowing if this is actually fixed. How often does this issue occur? This
expiration code is ancient, but it hasn't been reported until now.

I don't think we should leave it to silently afflict people later on who may not know what's
going on or how to address it.

Expiration is based on time. There is no point in attempting expiration again immediately
because almost nothing will have expired. It allows one bad connection to consume resources
it shouldn't in the form of hijacking a thread to iterate a list.

I don't see the downside of switching from a boolean to a long and CASing that instead. If
we aren't confident in it we can set a small interval so that it still checks for expiration
often although I think that just generates useless work. We can't make timeouts pass faster.

> Epxiration in OutboundTcpConnection can block the reader Thread
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-13265
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13265
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra 3.0.9
> Java HotSpot(TM) 64-Bit Server VM version 25.112-b15 (Java version 1.8.0_112-b15)
> Linux 3.16
>            Reporter: Christian Esken
>            Assignee: Christian Esken
>         Attachments: cassandra.pb-cache4-dus.2017-02-17-19-36-26.chist.xz, cassandra.pb-cache4-dus.2017-02-17-19-36-26.td.xz
>
>
> I observed that sometimes a single node in a Cassandra cluster fails to communicate to
the other nodes. This can happen at any time, during peak load or low load. Restarting that
single node from the cluster fixes the issue.
> Before going in to details, I want to state that I have analyzed the situation and am
already developing a possible fix. Here is the analysis so far:
> - A Threaddump in this situation showed  324 Threads in the OutboundTcpConnection class
that want to lock the backlog queue for doing expiration.
> - A class histogram shows 262508 instances of OutboundTcpConnection$QueuedMessage.
> What is the effect of it? As soon as the Cassandra node has reached a certain amount
of queued messages, it starts thrashing itself to death. Each of the Thread fully locks the
Queue for reading and writing by calling iterator.next(), making the situation worse and worse.
> - Writing: Only after 262508 locking operation it can progress with actually writing
to the Queue.
> - Reading: Is also blocked, as 324 Threads try to do iterator.next(), and fully lock
the Queue
> This means: Writing blocks the Queue for reading, and readers might even be starved which
makes the situation even worse.
> -----
> The setup is:
>  - 3-node cluster
>  - replication factor 2
>  - Consistency LOCAL_ONE
>  - No remote DC's
>  - high write throughput (100000 INSERT statements per second and more during peak times).
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message