You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Marcus Olsson (JIRA)" <ji...@apache.org> on 2017/10/24 09:02:00 UTC
[jira] [Updated] (CASSANDRA-13969) InterruptedException while
running repair
[ https://issues.apache.org/jira/browse/CASSANDRA-13969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcus Olsson updated CASSANDRA-13969:
--------------------------------------
Attachment: executorexample.tar.gz
Attaching a small example project which has a simplified version of the described problem.
For mapping between the threadpools/tasks in the example and Apache Cassandra:
TP#1 - Outer threadpool executing RepairJob
SimpleTask - RepairJob
TP#2 - RepairSession.taskExecutor which is executing validation/sync requests
SubTask#1 - Validation request
SubTask#2 - Sync request
> InterruptedException while running repair
> -----------------------------------------
>
> Key: CASSANDRA-13969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13969
> Project: Cassandra
> Issue Type: Bug
> Components: Repair
> Environment: Cassandra 2.2.10, sub-range repairs
> Reporter: Marcus Olsson
> Priority: Minor
> Attachments: executorexample.tar.gz
>
>
> In one of our test clusters we observed the following error in system.log:
> {noformat}
> 2017-10-12T15:55:25.617+0200 ERROR [Repair#34:1] CassandraDaemon.java:195 Exception in thread Thread[Repair#34:1,5,RMI Runtime]
> java.lang.AssertionError: java.lang.InterruptedException
> at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:265) ~[apache-cassandra-2.2.10.jar:2.2.10]
> at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.logExceptionsAfterExecute(DebuggableThreadPoolExecutor.java:225) ~[apache-cassandra-2.2.10.jar:2.2.10]
> at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.afterExecute(DebuggableThreadPoolExecutor.java:196) ~[apache-cassandra-2.2.10.jar:2.2.10]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1150) ~[na:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_131]
> Caused by: java.lang.InterruptedException: null
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1302) ~[na:1.8.0_131]
> at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:285) ~[guava-16.0.jar:na]
> at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116) ~[guava-16.0.jar:na]
> at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:261) ~[apache-cassandra-2.2.10.jar:2.2.10]
> ... 5 common frames omitted
> {noformat}
> Except for the exception there is no other odd outputs in system.log.
> From the repair history there is no indication of failed repairs and our repair handler doesn't get any errors reported back through the progress reporting either. One thing to note is that we utilize sub-range repairs and repair one vnode at a time, which means that we effectively run several hundreds of repair sessions for each table.
> From our repair handler the following is written in the logs:
> {noformat}
> 2017-10-12T15:55:25.611+0200 | INFO | Repair of <keyspace>.<table> - [(8922822608060820611,8928269034264081622]] completed successfully
> 2017-10-12T15:55:25.678+0200 | INFO | Repair of <keyspace>.<table> - [(-5406027845309604779,-5405899934869332173]] completed successfully
> 2017-10-12T15:55:25.744+0200 | INFO | Repair of <keyspace>.<table> - [(1498725784389153529,1509146082320230540]] completed successfully
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org