[jira] [Commented] (CASSANDRA-14742) Race Condition in batchlog replica collection
[
https://issues.apache.org/jira/browse/CASSANDRA-14742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16630666#comment-16630666
]
Alex Petrov commented on CASSANDRA-14742:
-
Thank you,
Committed to trunk as
[29f83b88821c4792087df19d829ac87b5c06e9e6|https://github.com/apache/cassandra/commit/29f83b88821c4792087df19d829ac87b5c06e9e6]
> Race Condition in batchlog replica collection
> -
>
> Key: CASSANDRA-14742
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14742
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we collect nodes for it in {{StorageProxy#getBatchlogReplicas}}, we
> already filter out down replicas; subsequently they get picked up and taken
> for liveAndDown.
> There's a possible race condition due to picking tokens from token metadata
> twice (once in {{StorageProxy#getBatchlogReplicas}} and second one in
> {{ReplicaPlan#forBatchlogWrite}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14742) Race Condition in batchlog replica collection
[
https://issues.apache.org/jira/browse/CASSANDRA-14742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629970#comment-16629970
]
Benedict commented on CASSANDRA-14742:
--
Thanks.
I'm a little concerned about the inconsistency of our
{{DatabaseDescriptor.getLocalDataCenter}} and this
{{IEndpointSnitch.getLocalDataCenter}}. I had intended to simply refer to the
former (although, debatably, only the latter should exist - since the former is
not consistently updated, although it should for correctness never change).
I'm honestly not clear what the best clean up of this mess is, particularly
with the distinction between the per-replication strategy snitch and the global
snitch (the former of which seem to simply cache the latter), and perhaps it
can be deferred to a later dedicated cleanup ticket anyway.
> Race Condition in batchlog replica collection
> -
>
> Key: CASSANDRA-14742
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14742
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we collect nodes for it in {{StorageProxy#getBatchlogReplicas}}, we
> already filter out down replicas; subsequently they get picked up and taken
> for liveAndDown.
> There's a possible race condition due to picking tokens from token metadata
> twice (once in {{StorageProxy#getBatchlogReplicas}} and second one in
> {{ReplicaPlan#forBatchlogWrite}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14742) Race Condition in batchlog replica collection
[
https://issues.apache.org/jira/browse/CASSANDRA-14742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16629957#comment-16629957
]
Alex Petrov commented on CASSANDRA-14742:
-
Thank you, have addressed all three comments and took a liberty to introduce
{{localDatacenter}} and {{localRack}} shortcuts.
> Race Condition in batchlog replica collection
> -
>
> Key: CASSANDRA-14742
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14742
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we collect nodes for it in {{StorageProxy#getBatchlogReplicas}}, we
> already filter out down replicas; subsequently they get picked up and taken
> for liveAndDown.
> There's a possible race condition due to picking tokens from token metadata
> twice (once in {{StorageProxy#getBatchlogReplicas}} and second one in
> {{ReplicaPlan#forBatchlogWrite}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14742) Race Condition in batchlog replica collection
[
https://issues.apache.org/jira/browse/CASSANDRA-14742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628602#comment-16628602
]
Benedict commented on CASSANDRA-14742:
--
Patch looks good overall, just a few nits:
# Right now, {{ReplicaPlans}} is organised into counter writes, regular writes,
regular write utilities, reads, reads utilities; I think it would be cleanest
to keep the batch write utilities similarly proximal to the batch writes
themselves, for consistency
# {{syncWriteBatchedMutations}} and {{forBatchlogWrite}} each accept a
{{localDc}} parameter - this seems a bit weird, since it's a global variable,
and only ever invoked with this (but also, we obtain it inconsistently, by
asking the snitch instead of the cached {{localDc}}. Perhaps they should each
just use the latter, without requiring it as a parameter?
# Unused imports in {{ReplicaPlans}}
> Race Condition in batchlog replica collection
> -
>
> Key: CASSANDRA-14742
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14742
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we collect nodes for it in {{StorageProxy#getBatchlogReplicas}}, we
> already filter out down replicas; subsequently they get picked up and taken
> for liveAndDown.
> There's a possible race condition due to picking tokens from token metadata
> twice (once in {{StorageProxy#getBatchlogReplicas}} and second one in
> {{ReplicaPlan#forBatchlogWrite}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14742) Race Condition in batchlog replica collection
[
https://issues.apache.org/jira/browse/CASSANDRA-14742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16617589#comment-16617589
]
Alex Petrov commented on CASSANDRA-14742:
-
We're picking batchlog CL of {{ONE}} or {{TWO}} since the logic in
{{BatchlogManager#EndpointFilter}} allows either one node (local, in case of
single-node data centers), or two replicas from different racks.
> Race Condition in batchlog replica collection
> -
>
> Key: CASSANDRA-14742
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14742
> Project: Cassandra
> Issue Type: Bug
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we collect nodes for it in {{StorageProxy#getBatchlogReplicas}}, we
> already filter out down replicas; subsequently they get picked up and taken
> for liveAndDown.
> There's a possible race condition due to picking tokens from token metadata
> twice (once in {{StorageProxy#getBatchlogReplicas}} and second one in
> {{ReplicaPlan#forBatchlogWrite}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
