You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Nick Bailey (JIRA)" <ji...@apache.org> on 2011/01/05 03:06:45 UTC
[jira] Created: (CASSANDRA-1934) Update token metadata for NORMAL
state
Update token metadata for NORMAL state
--------------------------------------
Key: CASSANDRA-1934
URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.0 rc 3
Reporter: Nick Bailey
Priority: Minor
Fix For: 0.7.1
The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-1934) Update token metadata
for NORMAL state
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984385#action_12984385 ]
Brandon Williams edited comment on CASSANDRA-1934 at 1/20/11 3:36 PM:
----------------------------------------------------------------------
currentNode (which failed decom and then restarted) does have the correct view of itself (normal) but
{code}
else if (endpoint.equals(currentNode))
{
// nothing to do
}
{code}
Prevents the other nodes from updating the state from 'Leaving' back to 'normal'.
We almost update the state here:
{code}
else if (Gossiper.instance.compareEndpointStartup(endpoint, currentNode) > 0)
{
logger_.info(String.format("Nodes %s and %s have the same token %s. %s is the new owner",
endpoint, currentNode, token, endpoint));
tokenMetadata_.updateNormalToken(token, endpoint);
if (!isClientMode)
SystemTable.updateToken(endpoint, token);
}
{code}
But don't because the generations will always be equal (in other words, this code only handles a *different* node updating the state, not the same node returning)
was (Author: brandon.williams):
currentNode (which failed decom and then restarted) does have the correct view of itself (normal) but
{code}
else if (endpoint.equals(currentNode))
{
// nothing to do
}
{code}
Prevents the other nodes from updating the state from 'Leaving' back to 'normal'.
We almost update the state here:
{code}
else if (Gossiper.instance.compareEndpointStartup(endpoint, currentNode) > 0)
{
logger_.info(String.format("Nodes %s and %s have the same token %s. %s is the new owner",
endpoint, currentNode, token, endpoint));
tokenMetadata_.updateNormalToken(token, endpoint);
if (!isClientMode)
SystemTable.updateToken(endpoint, token);
}
{code}
But don't because the generations will always be equal (in other words, this code only handles a *different* node updated the state, not the same node returning)
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984411#action_12984411 ]
Jonathan Ellis commented on CASSANDRA-1934:
-------------------------------------------
I still don't get it -- endpoint.equals(currentNode) will never be true on the other nodes.
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984385#action_12984385 ]
Brandon Williams commented on CASSANDRA-1934:
---------------------------------------------
currentNode (which failed decom and then restarted) does have the correct view of itself (normal) but
{code}
else if (endpoint.equals(currentNode))
{
// nothing to do
}
{code}
Prevents the other nodes from updating the state from 'Leaving' back to 'normal'.
We almost update the state here:
{code}
else if (Gossiper.instance.compareEndpointStartup(endpoint, currentNode) > 0)
{
logger_.info(String.format("Nodes %s and %s have the same token %s. %s is the new owner",
endpoint, currentNode, token, endpoint));
tokenMetadata_.updateNormalToken(token, endpoint);
if (!isClientMode)
SystemTable.updateToken(endpoint, token);
}
{code}
But don't because the generations will always be equal (in other words, this code only handles a *different* node updated the state, not the same node returning)
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984417#action_12984417 ]
Jonathan Ellis commented on CASSANDRA-1934:
-------------------------------------------
(renamed currentNode to currentOwner so I can remember the difference in the future.)
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-1934:
----------------------------------------
Reviewer: nickmbailey
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984368#action_12984368 ]
Jonathan Ellis commented on CASSANDRA-1934:
-------------------------------------------
How does updating when endpoint.equals(currentNode) solve the problem?
It looks to me like the relevant path is
{code}
logger_.info(String.format("Nodes %s and %s have the same token %s. %s is the new owner",
endpoint, currentNode, token, endpoint));
tokenMetadata_.updateNormalToken(token, endpoint);
{code}
which is already doing The Right Thing.
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984428#action_12984428 ]
Hudson commented on CASSANDRA-1934:
-----------------------------------
Integrated in Cassandra-0.7 #186 (See [https://hudson.apache.org/hudson/job/Cassandra-0.7/186/])
Update token metadata for NORMAL state when endpoint has not changed.
Patch by brandonwilliams, reviewed by jbellis for CASSANDRA-1934
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984377#action_12984377 ]
Jonathan Ellis commented on CASSANDRA-1934:
-------------------------------------------
my point is that currentNode should always have the right view of itself anyway, it's the other nodes we are worried about (according to the issue description anyway).
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984414#action_12984414 ]
Jonathan Ellis commented on CASSANDRA-1934:
-------------------------------------------
bq. I still don't get it - endpoint.equals(currentNode) will never be true on the other nodes.
I was thinking that currentNode == localAddress but that is not the case. It makes more sense now! :)
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984415#action_12984415 ]
Jonathan Ellis commented on CASSANDRA-1934:
-------------------------------------------
+1
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984372#action_12984372 ]
Brandon Williams commented on CASSANDRA-1934:
---------------------------------------------
If you are comparing endpoint to currentNode and they are the same, the generation difference can never be > 0
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984416#action_12984416 ]
Brandon Williams commented on CASSANDRA-1934:
---------------------------------------------
Yes it will. endpoint is the node entering the ring, currentNode is the node that currently has the token passed in (which in this case will be endpoint's token also), but does not mean 'my address' to the node making the evaluation. Thus, if we see the same endpoint and token, we do nothing in the current code, causing the state to never get updated.
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reassigned CASSANDRA-1934:
-----------------------------------------
Assignee: Brandon Williams
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-1934:
--------------------------------------
Remaining Estimate: 4h
Original Estimate: 4h
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1934) Update token metadata for NORMAL
state
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-1934:
----------------------------------------
Attachment: 1934.txt
Patch to allow recovery to normal if we knew about the endpoint previously and its IP has not changed.
> Update token metadata for NORMAL state
> --------------------------------------
>
> Key: CASSANDRA-1934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1934
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0 rc 3
> Reporter: Nick Bailey
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.7.1
>
> Attachments: 1934.txt
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The handleStateNormal() method in StorageService.java doesn't update the tokenmetadata. This means if you try to decommission a node but for some reason it fails, and then you bring the node back up, all other nodes will see it in a 'Leaving' state. When the state jumps back to normal they should update the token metadata to reflect that.
> This also means you won't be able to call 'removetoken' on that node, unless you restart another node in the cluster in order to put it back in a 'normal' state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.