cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Zhou (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13555) Thread leak during repair
Date Thu, 01 Jun 2017 03:52:04 GMT


Simon Zhou commented on CASSANDRA-13555:

Thanks [~tjake] for the comment. I'll be working on the patch but I'm not sure whether that
is the best fix. Reasons:
1. The "executor" is created in RepairRunnable and runs all RepairJob's for a given keyspace.
It's not a single RepairSession instance's responsibility to stop the "executor", nor it has
a reference to it.
2. The bigger problem is that, why do we handle "node down" in RepairSession? IMHO it should
be handled at a higher level. That means, once an endpoint is down, we should stop all RepairRunnable's.
Sure there could be improvement, e.g., only stop those affected RepairSession's (token ranges).
But anyway we are not doing this today and it deserves a separate change.

What do you think? I know there is bigger change in upcoming 4.0 but I don't want a band-aid
fix that just makes things messy.

> Thread leak during repair
> -------------------------
>                 Key: CASSANDRA-13555
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Simon Zhou
>            Assignee: Simon Zhou
> The symptom is similar to what happened in [CASSANDRA-13204 |]
that the thread waiting forever doing nothing. This one happened during "nodetool repair -pr
-seq -j 1" in production but I can easily simulate the problem with just "nodetool repair"
in dev environment (CCM). I'm trying to explain what happened with 3.0.13 code base.
> 1. One node is down while doing repair. This is the error I saw in production:
> {code}
> ERROR [GossipTasks:1] 2017-05-19 15:00:10,545 - [repair #bc9a3cd1-3ca3-11e7-a44a-e30923ac9336]
session completed with the following error
> Endpoint / died
>     at ~[apache-cassandra-3.0.11.jar:3.0.11]
>     at org.apache.cassandra.gms.FailureDetector.interpret( [apache-cassandra-3.0.11.jar:3.0.11]
>     at org.apache.cassandra.gms.Gossiper.doStatusCheck( [apache-cassandra-3.0.11.jar:3.0.11]
>     at org.apache.cassandra.gms.Gossiper.access$800( [apache-cassandra-3.0.11.jar:3.0.11]
>     at org.apache.cassandra.gms.Gossiper$ [apache-cassandra-3.0.11.jar:3.0.11]
>     at org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$
>     at java.util.concurrent.Executors$ [na:1.8.0_121]
>     at java.util.concurrent.FutureTask.runAndReset( [na:1.8.0_121]
>     at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(
>     at java.util.concurrent.ScheduledThreadPoolExecutor$
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(
>     at java.util.concurrent.ThreadPoolExecutor$
>     at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(
>     at ~[na:1.8.0_121]
> {code}
> 2. At this moment the repair coordinator hasn't received the response (MerkleTrees) for
the node that was marked down. This means, RepairJob#run will never return because it waits
for validations to finish:
> {code}
>         // Wait for validation to complete
>         Futures.getUnchecked(validations);
> {code}
> Be noted that all RepairJob's (as Runnable) run on a shared executor created in RepairRunnable#runMayThrow,
while all snapshot, validation and sync'ing happen on a per-RepairSession "taskExecutor".
The RepairJob#run will only return when it receives MerkleTrees (or null) from all endpoints
for a given column family and token range.
> As evidence of the thread leak, below is from the thread dump. I can also get the same
stack trace when simulating the same issue in dev environment.
> {code}
> "Repair#129:56" #406373 daemon prio=5 os_prio=0 tid=0x00007fc495028400 nid=0x1a77d waiting
on condition [0x00007fc021530000]
>    java.lang.Thread.State: WAITING (parking)
>     at sun.misc.Unsafe.park(Native Method)
>     - parking to wait for  <0x00000002d7c00198> (a$Sync)
>     at java.util.concurrent.locks.LockSupport.park(
>     at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(
>     at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(
>     at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(
>     at$Sync.get(
>     at
>     at
>     at
>     at
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(
>     at java.util.concurrent.ThreadPoolExecutor$
>     at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(
>     at org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$4/
>     at
>    Locked ownable synchronizers:
>     - <0x00000002d7c00230> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> So here are two things:
> 1. For the thread leak itself, either we do something like below in RepairSession#terminate,
or we use timed wait at the end of RepairJob#run.
> {code}
>         for (ValidationTask validationTask : validating.values()) {
>             validationTask.treesReceived(null);
>         }
>         validating.clear();
> {code}
> 2. Another question is, instead of waiting for synchronization (SyncTask) to finish,
why we just wait for validation? Is it because we want to speed things up and anyway we have
throttling on streaming?
> [~yukim] I'd love to get your comment. I'll check if this issue exists in other versions.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message