You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Yongle Zhang (Jira)" <ji...@apache.org> on 2020/11/13 02:02:00 UTC
[jira] [Commented] (CASSANDRA-16267) Adding a C* 1.2.0 node to a C*
1.1.0 cluster fails with connection failure
[ https://issues.apache.org/jira/browse/CASSANDRA-16267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231091#comment-17231091 ]
Yongle Zhang commented on CASSANDRA-16267:
------------------------------------------
Thanks!
> Adding a C* 1.2.0 node to a C* 1.1.0 cluster fails with connection failure
> --------------------------------------------------------------------------
>
> Key: CASSANDRA-16267
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16267
> Project: Cassandra
> Issue Type: Bug
> Reporter: Yongle Zhang
> Priority: Normal
>
> Steps to reproduce:
> # start a 2-node C* 1.1.0 cluster
> # add a new C* 1.2.0 node
> Error:
> {code:java}
> ERROR [main] 2020-06-18 01:12:12,894 CassandraDaemon.java (line 414) Exception encountered during startup
> java.lang.RuntimeException: No other nodes seen! Unable to bootstrap.If you intended to start a single-node cluster, you should make sure your broadcast_address (or listen_address) is listed as a seed. Otherwise, you need to determine why the seed being contacted has no knowledge of the rest of the cluster. Usually, this can be solved by giving all nodes the same seed list.
> at org.apache.cassandra.dht.BootStrapper.getBootstrapSource(BootStrapper.java:154)
> at org.apache.cassandra.dht.BootStrapper.getBalancedToken(BootStrapper.java:135)
> at org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:115)
> at org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:611)
> at org.apache.cassandra.service.StorageService.initServer(StorageService.java:499)
> at org.apache.cassandra.service.StorageService.initServer(StorageService.java:397)
> at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:309)
> at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:397)
> at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:440)
> ERROR [StorageServiceShutdownHook] 2020-06-18 01:12:12,898 CassandraDaemon.java (line 133) Exception in thread Thread[StorageServiceShutdownHook,5,main]
> java.lang.NullPointerException
> at org.apache.cassandra.service.StorageService.stopRPCServer(StorageService.java:307)
> at org.apache.cassandra.service.StorageService$1.runMayThrow(StorageService.java:464)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Root cause:
> In 1.2.0, when a node wants to connect another node, it will expect to read a int from it. See https://github.com/apache/cassandra/blob/cassandra-1.2.0/src/java/org/apache/cassandra/net/OutboundTcpConnection.java#L276 .
> There *seems* to exist a check (line 269 in the same file) about the target version before trying to read int. It is based on variable `targetVersion`, which is from `MessagingService.instance().getVersion(poolReference.endPoint())`. This function, however, returns the version of itself when the end point is unknown.
> Also the target node will send this int if it is also running 1.2.0. See https://github.com/apache/cassandra/blob/cassandra-1.2.0/src/java/org/apache/cassandra/net/IncomingTcpConnection.java#L90 .
> However, in 1.1.0, there is no such mechanism, the 1.1.0 node won't send this int. So when a 1.2.0 node tries to connect to a 1.1.0 node, it will stuck at "readInt".
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org