[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5902: - Fix Version/s: 3.0.x > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Sub-task > Components: Coordination >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Fix For: 3.0.x, 3.x > > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-5902: --- Component/s: Coordination > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Sub-task > Components: Coordination >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Fix For: 3.x > > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5902: - Issue Type: Sub-task (was: Bug) Parent: CASSANDRA-9427 > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Fix For: 3.x > > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5902: - Fix Version/s: (was: 2.1.x) 3.x > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Fix For: 3.x > > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-5902: -- Fix Version/s: (was: 2.1.2) 2.1.3 > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Fix For: 2.1.3 > > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5902: -- Reviewer: Jonathan Ellis (was: Aleksey Yeschenko) > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Fix For: 2.1.1 > > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-5902: - Reviewer: Aleksey Yeschenko > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Fix For: 2.1.1 > > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5902: Fix Version/s: (was: 2.1.0) 2.1.1 > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > Fix For: 2.1.1 > > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-5902: Assignee: Branimir Lambov > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Assignee: Branimir Lambov >Priority: Minor > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5902: -- Assignee: (was: Ala' Alkhaldi) > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Priority: Minor > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-5902) Dealing with hints after a topology change
[ https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5902: -- Assignee: (was: Jonathan Ellis) Does this qualify as LHF [~brandon.williams]? If we have a hook for the topology change I think that's the only hard part. > Dealing with hints after a topology change > -- > > Key: CASSANDRA-5902 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5902 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Priority: Minor > > Hints are stored and delivered by destination node id. This allows them to > survive IP changes in the target, while making "scan all the hints for a > given destination" an efficient operation. However, we do not detect and > handle new node assuming responsibility for the hinted row via bootstrap > before it can be delivered. > I think we have to take a performance hit in this case -- we need to deliver > such a hint to *all* replicas, since we don't know which is the "new" one. > This happens infrequently enough, however -- requiring first the target node > to be down to create the hint, then the hint owner to be down long enough for > the target to both recover and stream to a new node -- that this should be > okay. -- This message was sent by Atlassian JIRA (v6.1#6144)