Marcus Olsson created CASSANDRA-13969:
-----------------------------------------
Summary: 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
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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
