Hi, I have cassandra 2.0.14 deployed and after following the method described in Apache Cassandra™ 2.0 to clear the gossip state of the node in one of the dc of my cluster | | | | | | | | | Apache Cassandra™ 2.0Correcting a problem in the gossip state. | Version 2.0 | | | | View on docs.datastax.com | Preview by Yahoo | | | | |
I see wierd exception on the nodes not many but a few in an hour for nodes that have already successfully decommissioned from the cluster, you can see from below exception that 10.0.0.1 has been already decommissioned. Below is the exception snippet. Has anyone observed a similar behaviour? e.g. 10.0.0.1 is decommissioned Is this a bug in cassandra 2.0.x? 2015-09-15 02:35:14,056 [GossipStage:9] INFO Gossiper InetAddress /10.0.0.1 is now DOWN2015-09-15 02:35:14,058 [GossipStage:9] INFO StorageService Removing tokens [15950735949418990474845684723364134913] for /10.0.0.1 2015-09-15 02:35:14,061 [GossipStage:9] ERROR CassandraDaemon Exception in thread Thread[GossipStage:9,5,main]java.lang.NullPointerException at org.apache.cassandra.service.StorageService.getRpcaddress(StorageService.java:1067) at org.apache.cassandra.transport.Server$EventNotifier.getRpcAddress(Server.java:345) at org.apache.cassandra.transport.Server$EventNotifier.onLeaveCluster(Server.java:366) at org.apache.cassandra.service.StorageService.excise(StorageService.java:1790) at org.apache.cassandra.service.StorageService.excise(StorageService.java:1798) at org.apache.cassandra.service.StorageService.handleStateLeft(StorageService.java:1701) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1361) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1995) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1003) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:1102) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:49) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)