[
https://issues.apache.org/jira/browse/CASSANDRA-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14586540#comment-14586540
]
Joshua McKenzie commented on CASSANDRA-9584:
--------------------------------------------
Can further confirm that the failing long test that prompted this ticket also
passes for me locally:
{noformat}
test_token_aware
(tests.integration.long.test_loadbalancingpolicies.LoadBalancingPolicyTests)
... Started: node1 with pid: 6340
Started: node3 with pid: 3536
Started: node2 with pid: 5396
SUCCESS: The process with PID 5396 has been terminated.
Creating session
Started: node2 with pid: 6396
SUCCESS: The process with PID 6396 has been terminated.
Started: node2 with pid: 4140
SUCCESS: The process with PID 4140 has been terminated.
SUCCESS: The process with PID 6340 has been terminated.
SUCCESS: The process with PID 3536 has been terminated.
ok
----------------------------------------------------------------------
Ran 1 test in 211.360s
OK
{noformat}
I did have to make some modifications to the test as it's hard-coded expecting
the tokens to be assigned to node 2 and mine were going to node 3, but after
inverting the node2/node3 checks the test passes. Will try it on the Server2012
perf machine as well to confirm. This is with ccm master and
cassandra-2.2.0-rc1.
If it passes on the server as well I'm going to close this as cannot reproduce
as it looks like something's up with the testing environment.
> Decommissioning a node on Windows sends the wrong schema change event
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-9584
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9584
> Project: Cassandra
> Issue Type: Bug
> Environment: C* 2.2.0-rc1 | python-driver 2.6.0-rc1 | Windows Server
> 2012 R2 64-bit
> Reporter: Kishan Karunaratne
> Assignee: Joshua McKenzie
> Fix For: 2.2.x
>
>
> Decommissioning a node on Windows sends the wrong schema change event:
> {noformat}
> cassandra.connection: DEBUG: Message pushed from server:
> <EventMessage(event_type=u'STATUS_CHANGE', trace_id=None, event
> _args={'change_type': u'DOWN', 'address': ('127.0.0.2', 9042)}, stream_id=-1)>
> {noformat}
> On Linux I get the correct event:
> {noformat}
> cassandra.connection: DEBUG: Message pushed from server:
> <EventMessage(event_type=u'TOPOLOGY_CHANGE', trace_id=None,
> event_args={'change_type': u'REMOVED_NODE', 'address': ('127.0.0.2', 9042)},
> stream_id=-1)>
> {noformat}
> We are using ccmlib node.py.decommission() which calls nodetool decommission:
> {noformat}
> def decommission(self):
> self.nodetool("decommission")
> self.status = Status.DECOMMISIONNED
> self._update_config()
> {noformat}
> Interestingly, it does seem to work (correctly?) on CCM CLI:
> {noformat}
> PS C:\Users\Administrator> ccm status
> Cluster: '2.2'
> --------------
> node1: UP
> node3: UP
> node2: UP
> PS C:\Users\Administrator> ccm node1 ring
> Starting NodeTool
> Datacenter: datacenter1
> ==========
> Address Rack Status State Load Owns
> Token
>
> 3074457345618258602
> 127.0.0.1 rack1 Up Normal 62.43 KB ?
> -9223372036854775808
> 127.0.0.2 rack1 Up Normal 104.87 KB ?
> -3074457345618258603
> 127.0.0.3 rack1 Up Normal 83.67 KB ?
> 3074457345618258602
> Note: Non-system keyspaces don't have the same replication settings,
> effective ownership information is meaningless
> PS C:\Users\Administrator> ccm node2 decommission
> PS C:\Users\Administrator> ccm status
> Cluster: '2.2'
> --------------
> node1: UP
> node3: UP
> node2: DECOMMISIONNED
> PS C:\Users\Administrator> ccm node1 ring
> Starting NodeTool
> Datacenter: datacenter1
> ==========
> Address Rack Status State Load Owns
> Token
>
> 3074457345618258602
> 127.0.0.1 rack1 Up Normal 67.11 KB ?
> -9223372036854775808
> 127.0.0.3 rack1 Up Normal 88.35 KB ?
> 3074457345618258602
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
