cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Olefir (JIRA)" <>
Subject [jira] [Created] (CASSANDRA-5218) Log explosion when another cluster node is down and remaining node is overloaded.
Date Mon, 04 Feb 2013 13:22:12 GMT
Sergey Olefir created CASSANDRA-5218:

             Summary: Log explosion when another cluster node is down and remaining node is
                 Key: CASSANDRA-5218
             Project: Cassandra
          Issue Type: Bug
    Affects Versions: 1.1.7
            Reporter: Sergey Olefir

I have Cassandra 1.1.7 cluster with 4 nodes in 2 datacenters (2+2). Replication is configured
as DC1:2,DC2:2 (i.e. every node holds the entire data). 

I am load-testing counter increments at the rate of about 10k per second. All writes are directed
to two nodes in DC1 (DC2 nodes are basically backup). In total there's 100 separate clients
executing 1-2 batch updates per second. 

We wanted to test what happens if one node goes down, so we brought one node down in DC1 (i.e.
the node that was handling half of the incoming writes). 

This led to a complete explosion of logs on the remaining alive node in DC1. 

There are hundreds of megabytes of logs within an hour all basically saying the same thing:

ERROR [ReplicateOnWriteStage:5653390] 2013-01-22 12:44:33,611
(line 135) Exception in thread Thread[ReplicateOnWriteStage:5653390,5,main] 
java.lang.RuntimeException: java.util.concurrent.TimeoutException 
        at org.apache.cassandra.service.StorageProxy$

        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(

        at java.util.concurrent.ThreadPoolExecutor$

Caused by: java.util.concurrent.TimeoutException 
        at org.apache.cassandra.service.StorageProxy.sendToHintedEndpoints(

        at org.apache.cassandra.service.StorageProxy$7$1.runMayThrow(

        at org.apache.cassandra.service.StorageProxy$

        ... 3 more 

The logs are completely swamped with this and are thus unusable. It may also negatively impact
the node performance.

According to Aaron Morton:
{quote}The error is the coordinator node protecting it's self. 

Basically it cannot handle the volume of local writes + the writes for HH.  The number of
in flight hints is greater than…

    private static volatile int maxHintsInProgress = 1024 * Runtime.getRuntime().availableProcessors();{quote}

I think there are two issues here:
(a) the same exception occurring for the same reason doesn't need to be spammed into log many
times per second;
(b) exception message ought to be more clear about cause -- i.e. in this case some message
about "overload" or "load shedding" might be appropriate.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message