cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Greaves (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14525) streaming failure during bootstrap makes new node into inconsistent state
Date Mon, 02 Jul 2018 08:23:00 GMT


Kurt Greaves commented on CASSANDRA-14525:

{quote}Also I've discovered another bug exists in current open source code in which if isSurveyMode
is true and streaming fails (i.e. isBootstrapMode is true) then also one can call nodetool
join without nodetool bootstrap resume and have that node join the ring.
Great catch. I found a couple more small issue w.r.t {{nodetool join}} as well while I was
testing this.
 # If in write_survey and you join the ring after bootstrap, transports won't be enabled.
can we call {{CassandraDaemon#start()}} here?
 # nodetool join fails silently if write_survey is true and we haven't completed bootstrapping,
but server log prints the following
WARN [RMI TCP Connection(5)-] 2018-06-29 12:39:49,735 -
Some data streaming failed. Use nodetool to check bootstrap state and resume. For more, see
`nodetool help bootstrap`. IN_PROGRESS
nodetool join should say something along the lines of "{{Can't join the ring because in write_survey
mode and bootstrap hasn't completed}}"

Also another minor nit w.r.t logging; you can get the following log message after successfully
bootstrapping if you were in write survey mode:
INFO [main] 2018-06-29 12:12:39,071 - Not starting client transports
as bootstrap has not completed
Probably better to split CassandraDaemon.start() if block so that we print "{{Not starting
client transports as write_survey mode is enabled.}}"

And finally, there's still 2 occurences of "bootstraped" in the exception messages in {{startNativeTransport}}
and {{startRPCServer}}.

> streaming failure during bootstrap makes new node into inconsistent state
> -------------------------------------------------------------------------
>                 Key: CASSANDRA-14525
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Jaydeepkumar Chovatia
>            Assignee: Jaydeepkumar Chovatia
>            Priority: Major
>             Fix For: 4.0, 2.2.x, 3.0.x
> If bootstrap fails for newly joining node (most common reason is due to streaming failure)
then Cassandra state remains in {{joining}} state which is fine but Cassandra also enables
Native transport which makes overall state inconsistent. This further creates NullPointer
exception if auth is enabled on the new node, please find reproducible steps here:
> For example if bootstrap fails due to streaming errors like
> {quote}java.util.concurrent.ExecutionException: org.apache.cassandra.streaming.StreamException:
Stream failed
>  at$Sync.getValue(
>  at$Sync.get(
>  at ~[guava-18.0.jar:na]
>  at org.apache.cassandra.service.StorageService.bootstrap( [apache-cassandra-3.0.16.jar:3.0.16]
>  at org.apache.cassandra.service.StorageService.joinTokenRing(
>  at org.apache.cassandra.service.StorageService.initServer( [apache-cassandra-3.0.16.jar:3.0.16]
>  at org.apache.cassandra.service.StorageService.initServer( [apache-cassandra-3.0.16.jar:3.0.16]
>  at org.apache.cassandra.service.CassandraDaemon.setup( [apache-cassandra-3.0.16.jar:3.0.16]
>  at org.apache.cassandra.service.CassandraDaemon.activate( [apache-cassandra-3.0.16.jar:3.0.16]
>  at org.apache.cassandra.service.CassandraDaemon.main( [apache-cassandra-3.0.16.jar:3.0.16]
>  Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
>  at
>  at$ ~[guava-18.0.jar:na]
>  at$DirectExecutor.execute(
>  at
>  at ~[guava-18.0.jar:na]
>  at
>  at org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(
>  at org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(
>  at org.apache.cassandra.streaming.StreamSession.closeSession(
>  at org.apache.cassandra.streaming.StreamSession.onError( ~[apache-cassandra-3.0.16.jar:3.0.16]
>  at org.apache.cassandra.streaming.ConnectionHandler$
>  at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(
>  at ~[na:1.8.0_121]
> {quote}
> then variable [ |]
will be {{false}}. Since {{dataAvailable}} is {{false}} hence it will not call [
and as a result [|]
will not be invoked.
> API [ |]
returns without any problem. After this [|]
is invoked which starts native transport at 
>  [ |]
> At this point daemon’s bootstrap is still not finished and transport is enabled. So
client will connect to the node and will encounter {{java.lang.NullPointerException}} as following:
> {quote}ERROR [SharedPool-Worker-2] - Unexpected exception during request;
channel = [id: 0x412a26b3, L:/a.b.c.d:9042 - R:/p.q.r.s:20121]
>  java.lang.NullPointerException: null
>  at org.apache.cassandra.auth.PasswordAuthenticator.doAuthenticate(
>  at org.apache.cassandra.auth.PasswordAuthenticator.authenticate(
>  at org.apache.cassandra.auth.PasswordAuthenticator.access$100(
>  at org.apache.cassandra.auth.PasswordAuthenticator$PlainTextSaslAuthenticator.getAuthenticatedUser(
>  at org.apache.cassandra.transport.messages.AuthResponse.execute(
>  at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(
>  at org.apache.cassandra.transport.Message$Dispatcher.channelRead0(
>  at
>  at
>  at$
>  at java.util.concurrent.Executors$ [na:1.8.0_121]
>  at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$
>  at [apache-cassandra-3.0.16.jar:3.0.16]
>  at [na:1.8.0_121]
> {quote}
> At this point if we run {{nodetool status}} then it will show this new node in {{UJ}}
state, however clients can connect to this node over {{CQL}} and will receive {{java.lang.NullPointerException}}

This message was sent by Atlassian JIRA

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

View raw message