You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2012/10/11 16:55:04 UTC
[jira] [Created] (CASSANDRA-4792) Digest mismatch doesn't wait for
writes as intended
Jonathan Ellis created CASSANDRA-4792:
-----------------------------------------
Summary: Digest mismatch doesn't wait for writes as intended
Key: CASSANDRA-4792
URL: https://issues.apache.org/jira/browse/CASSANDRA-4792
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 1.1.6
As reported by Niklas Ekström on the dev list:
I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766 seems odd to me.
FBUtilities.waitOnFutures() is called with the repairResults from the RowRepairResolver resolver.
The problem though is that repairResults is only assigned when the object is created at line 737 in StorageProxy.java, and there it is assigned to Collections.emptyList(), and in the resolve() method in RowRepairResolver, which is indirectly called from line 771 in StorageProxy.java, that is, after the call to FBUtilities.waitOnFutures().
So the effect is that line 766 in StorageProxy.java is essentially a no-op.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4792) Digest mismatch doesn't wait
for writes as intended
Posted by "Vijay (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474361#comment-13474361 ]
Vijay commented on CASSANDRA-4792:
----------------------------------
+1
> Digest mismatch doesn't wait for writes as intended
> ---------------------------------------------------
>
> Key: CASSANDRA-4792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4792
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 1.1.6
>
> Attachments: 4792.txt
>
>
> As reported by Niklas Ekström on the dev list:
> I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766 seems odd to me.
> FBUtilities.waitOnFutures() is called with the repairResults from the RowRepairResolver resolver.
> The problem though is that repairResults is only assigned when the object is created at line 737 in StorageProxy.java, and there it is assigned to Collections.emptyList(), and in the resolve() method in RowRepairResolver, which is indirectly called from line 771 in StorageProxy.java, that is, after the call to FBUtilities.waitOnFutures().
> So the effect is that line 766 in StorageProxy.java is essentially a no-op.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4792) Digest mismatch doesn't wait for
writes as intended
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-4792:
--------------------------------------
Attachment: 4792.txt
> Digest mismatch doesn't wait for writes as intended
> ---------------------------------------------------
>
> Key: CASSANDRA-4792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4792
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 1.1.6
>
> Attachments: 4792.txt
>
>
> As reported by Niklas Ekström on the dev list:
> I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766 seems odd to me.
> FBUtilities.waitOnFutures() is called with the repairResults from the RowRepairResolver resolver.
> The problem though is that repairResults is only assigned when the object is created at line 737 in StorageProxy.java, and there it is assigned to Collections.emptyList(), and in the resolve() method in RowRepairResolver, which is indirectly called from line 771 in StorageProxy.java, that is, after the call to FBUtilities.waitOnFutures().
> So the effect is that line 766 in StorageProxy.java is essentially a no-op.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4792) Digest mismatch doesn't wait
for writes as intended
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479316#comment-13479316 ]
Jonathan Ellis commented on CASSANDRA-4792:
-------------------------------------------
That, and "it was possible for a quorum read to return an old value, even after a quorum read had returned a newer value [but the newer value had not yet been sent to the other replicas]."
> Digest mismatch doesn't wait for writes as intended
> ---------------------------------------------------
>
> Key: CASSANDRA-4792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4792
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 1.1.6, 1.2.0 beta 2
>
> Attachments: 4792.txt
>
>
> As reported by Niklas Ekström on the dev list:
> I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766 seems odd to me.
> FBUtilities.waitOnFutures() is called with the repairResults from the RowRepairResolver resolver.
> The problem though is that repairResults is only assigned when the object is created at line 737 in StorageProxy.java, and there it is assigned to Collections.emptyList(), and in the resolve() method in RowRepairResolver, which is indirectly called from line 771 in StorageProxy.java, that is, after the call to FBUtilities.waitOnFutures().
> So the effect is that line 766 in StorageProxy.java is essentially a no-op.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4792) Digest mismatch doesn't wait
for writes as intended
Posted by "Robert Coli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478510#comment-13478510 ]
Robert Coli commented on CASSANDRA-4792:
----------------------------------------
Is this bug's practical effect summarizable as :
"Because read repair didn't actually wait around for repair writes to ack, there was a non-zero chance of multiple concurrent read requests to a needing-repair key triggering multiple repair writes?"
> Digest mismatch doesn't wait for writes as intended
> ---------------------------------------------------
>
> Key: CASSANDRA-4792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4792
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 1.1.6, 1.2.0 beta 2
>
> Attachments: 4792.txt
>
>
> As reported by Niklas Ekström on the dev list:
> I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766 seems odd to me.
> FBUtilities.waitOnFutures() is called with the repairResults from the RowRepairResolver resolver.
> The problem though is that repairResults is only assigned when the object is created at line 737 in StorageProxy.java, and there it is assigned to Collections.emptyList(), and in the resolve() method in RowRepairResolver, which is indirectly called from line 771 in StorageProxy.java, that is, after the call to FBUtilities.waitOnFutures().
> So the effect is that line 766 in StorageProxy.java is essentially a no-op.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira