cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kishan Karunaratne (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9584) Decommissioning a node on Windows sends the wrong schema change event
Date Thu, 11 Jun 2015 18:08:01 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582302#comment-14582302
] 

Kishan Karunaratne edited comment on CASSANDRA-9584 at 6/11/15 6:07 PM:
------------------------------------------------------------------------

After changing the default connect port (7199) to the Windows listen port (7100), I was able
to use nodetool from the CLI directly to decommission the first node, 127.0.0.1. While CCM's
node status was not updated, I was able to verify via nodetool status that the node no longer
exists in the ring. However, the Java process still exists for the decommissioned node.  

Furthermore, I'm still able to query the decommissioned node through both CCM:
{noformat}
PS C:\Users\Administrator> ccm node1 nodetool status

Starting NodeTool
Datacenter: datacenter1
========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns    Host ID                               Rack
UN  127.0.0.2  62.48 KB   1            ?       4cb1b80e-a83e-4754-9d1c-80afcfe1cc4a  rack1
UN  127.0.0.3  62.48 KB   1            ?       d8dd050d-cf88-4c45-97c4-f785db3a1c56  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information
is meaningless

PS C:\Users\Administrator> ccm node1 ring

Starting NodeTool

Datacenter: datacenter1
==========
Address    Rack        Status State   Load            Owns                Token
                                                                          3074457345618258602
127.0.0.2  rack1       Up     Normal  62.48 KB        ?                   -3074457345618258603
127.0.0.3  rack1       Up     Normal  62.48 KB        ?                   3074457345618258602


  Note: Non-system keyspaces don't have the same replication settings, effective ownership
information is meaningless
{noformat}

and through nodetool directly:
{noformat}
PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.1 status
Starting NodeTool
Datacenter: datacenter1
========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns    Host ID                               Rack
UN  127.0.0.2  62.48 KB   1            ?       4cb1b80e-a83e-4754-9d1c-80afcfe1cc4a  rack1
UN  127.0.0.3  62.48 KB   1            ?       d8dd050d-cf88-4c45-97c4-f785db3a1c56  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information
is meaningless

PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.1 ring
Starting NodeTool

Datacenter: datacenter1
==========
Address    Rack        Status State   Load            Owns                Token
                                                                          3074457345618258602
127.0.0.2  rack1       Up     Normal  62.48 KB        ?                   -3074457345618258603
127.0.0.3  rack1       Up     Normal  62.48 KB        ?                   3074457345618258602


  Note: Non-system keyspaces don't have the same replication settings, effective ownership
information is meaningless
{noformat}

I wasn't able to decommssion other nodes as I get a:
{noformat}
PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.2 decommission
nodetool: Failed to connect to '127.0.0.2:7100' - ConnectException: 'Connection refused: connect'.
{noformat}


was (Author: kishkaru):
After changing the default connect port (7199) to the Windows listen port (7100), I was able
to use nodetool from the CLI directly to decommission the first node, 127.0.0.1. While CCM's
node status was not updated, I was able to verify via nodetool status that the node no longer
exists in the ring. However, the Java process still exists for the decommissioned node.  

Furthermore, I'm still able to query the decommissioned node through both CCM:
{noformat}
PS C:\Users\Administrator> ccm node1 nodetool status

Starting NodeTool
Datacenter: datacenter1
========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns    Host ID                               Rack
UN  127.0.0.2  62.48 KB   1            ?       4cb1b80e-a83e-4754-9d1c-80afcfe1cc4a  rack1
UN  127.0.0.3  62.48 KB   1            ?       d8dd050d-cf88-4c45-97c4-f785db3a1c56  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information
is meaningless

PS C:\Users\Administrator> ccm node1 ring

Starting NodeTool

Datacenter: datacenter1
==========
Address    Rack        Status State   Load            Owns                Token
                                                                          3074457345618258602
127.0.0.2  rack1       Up     Normal  62.48 KB        ?                   -3074457345618258603
127.0.0.3  rack1       Up     Normal  62.48 KB        ?                   3074457345618258602


  Note: Non-system keyspaces don't have the same replication settings, effective ownership
information is meaningless
{noformat}

and through nodetool directly:
{noformat}
PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.1 status
Starting NodeTool
Datacenter: datacenter1
========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns    Host ID                               Rack
UN  127.0.0.2  62.48 KB   1            ?       4cb1b80e-a83e-4754-9d1c-80afcfe1cc4a  rack1
UN  127.0.0.3  62.48 KB   1            ?       d8dd050d-cf88-4c45-97c4-f785db3a1c56  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information
is meaningless

PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.1 ring
Starting NodeTool

Datacenter: datacenter1
==========
Address    Rack        Status State   Load            Owns                Token
                                                                          3074457345618258602
127.0.0.2  rack1       Up     Normal  62.48 KB        ?                   -3074457345618258603
127.0.0.3  rack1       Up     Normal  62.48 KB        ?                   3074457345618258602


  Note: Non-system keyspaces don't have the same replication settings, effective ownership
information is meaningless
{noformat}

I wasn't able to decommssion other nodes as I get a:
{noformat}
nodetool: Failed to connect to '127.0.0.2:7100' - ConnectException: 'Connection refused: connect'.
{noformat}

> 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)

Mime
View raw message