cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip Thompson (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8741) Running a drain before a decommission apparently the wrong thing to do
Date Wed, 26 Aug 2015 18:10:46 GMT


Philip Thompson commented on CASSANDRA-8741:

Bump. [~brandon.williams], do you want to review this, or have a suggestion of who should?

> Running a drain before a decommission apparently the wrong thing to do
> ----------------------------------------------------------------------
>                 Key: CASSANDRA-8741
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Ubuntu 14.04; Cassandra (Datastax Enterprise 4.5.3)
>            Reporter: Casey Marshall
>            Assignee: Jan Karlsson
>            Priority: Trivial
>              Labels: lhf
>             Fix For: 2.1.x, 2.0.x
>         Attachments: 8741.txt
> This might simply be a documentation issue. It appears that running "nodetool drain"
is a very wrong thing to do before running a "nodetool decommission".
> The idea was that I was going to safely shut off writes and flush everything to disk
before beginning the decommission. What happens is the "decommission" call appears to fail
very early on after starting, and afterwards, the node in question is stuck in state LEAVING,
but all other nodes in the ring see that node as NORMAL, but down. No streams are ever sent
from the node being decommissioned to other nodes.
> The drain command does indeed shut down the "BatchlogTasks" executor (org/apache/cassandra/service/,
line 3445 in git tag "cassandra-2.0.11") but the decommission process tries using that executor
when calling the "startBatchlogReplay" function (org/apache/cassandra/db/,
line 123) called through org.apache.cassandra.service.StorageService.unbootstrap (see the
stack trace pasted below).
> This also failed in a similar way on Cassandra 1.2.13-ish (DSE 3.2.4).
> So, either something is wrong with the drain/decommission commands, or it's very wrong
to run a drain before a decommission. What's worse, there seems to be no way to recover this
node once it is in this state; you need to shut it down and run "removenode".
> My terminal output:
> {code}
> ubuntu@x:~$ nodetool drain
> ubuntu@x:~$ tail /var/log/^C
> ubuntu@x:~$ nodetool decommission
> Exception in thread "main" java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3008fa33
rejected from org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor@1d6242e8[Terminated,
pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 52]
>         at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(
>         at java.util.concurrent.ThreadPoolExecutor.reject(
>         at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(
>         at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(
>         at java.util.concurrent.ScheduledThreadPoolExecutor.submit(
>         at org.apache.cassandra.db.BatchlogManager.startBatchlogReplay(
>         at org.apache.cassandra.service.StorageService.unbootstrap(
>         at org.apache.cassandra.service.StorageService.decommission(
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at sun.reflect.misc.Trampoline.invoke(
>         at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at sun.reflect.misc.MethodUtil.invoke(
>         at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(
>         at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(
>         at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(
>         at com.sun.jmx.mbeanserver.PerInterface.invoke(
>         at com.sun.jmx.mbeanserver.MBeanSupport.invoke(
>         at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(
>         at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(
>         at
>         at$300(
>         at$
>         at
>         at
>         at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>         at java.lang.reflect.Method.invoke(
>         at sun.rmi.server.UnicastServerRef.dispatch(
>         at sun.rmi.transport.Transport$
>         at sun.rmi.transport.Transport$
>         at Method)
>         at sun.rmi.transport.Transport.serviceCall(
>         at sun.rmi.transport.tcp.TCPTransport.handleMessages(
>         at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(
>         at sun.rmi.transport.tcp.TCPTransport$
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at{code}

This message was sent by Atlassian JIRA

View raw message