You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Dave Revell (JIRA)" <ji...@apache.org> on 2010/07/29 00:45:16 UTC
[jira] Created: (CASSANDRA-1332) Scan results out of order
Scan results out of order
-------------------------
Key: CASSANDRA-1332
URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7 beta 1
Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
Reporter: Dave Revell
After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1332) Scan results out of order
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895795#action_12895795 ]
Jonathan Ellis commented on CASSANDRA-1332:
-------------------------------------------
I believe this is fixed by the changes to StorageProxy made in CASSANDRA-1156. Can you re-test?
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Fix For: 0.7.0
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1332) Scan results out of order
Posted by "Dave Revell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895865#action_12895865 ]
Dave Revell commented on CASSANDRA-1332:
----------------------------------------
jbellis: I can't retest, scan() no longer exists (in cassandra.thrift).
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Fix For: 0.7.0
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1332) Scan results out of order
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895796#action_12895796 ]
Jonathan Ellis commented on CASSANDRA-1332:
-------------------------------------------
I note that scan wasn't supposed to really work at all across multiple nodes, prior to 1156. :)
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Fix For: 0.7.0
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1332) Scan results out of order
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-1332:
----------------------------------------
Fix Version/s: 0.7.0
FWIW, Dave also told me that increasing the CL doesn't help, so it's not a consistency issue.
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Fix For: 0.7.0
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1332) Scan results out of order
Posted by "Dave Revell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895886#action_12895886 ]
Dave Revell commented on CASSANDRA-1332:
----------------------------------------
It seems fixed. After updating to r982821 and running the same test, it now passes (with scan switched to get_range_slices).
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Fix For: 0.7.0
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1332) Scan results out of order
Posted by "Dave Revell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Revell updated CASSANDRA-1332:
-----------------------------------
Comment: was deleted
(was: System test. This test will pass on a one-node cluster but should fail on a four-node cluster.)
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1332) Scan results out of order
Posted by "Dave Revell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893725#action_12893725 ]
Dave Revell commented on CASSANDRA-1332:
----------------------------------------
Bisecting the SVN history shows that this worked in r966733 but became broken in r966742. Both of those revisions are dated July 22.
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Fix For: 0.7.0
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1332) Scan results out of order
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-1332.
---------------------------------------
Assignee: Jonathan Ellis
Fix Version/s: 0.7 beta 1
(was: 0.7.0)
Resolution: Fixed
Great, thanks for the help!
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Assignee: Jonathan Ellis
> Fix For: 0.7 beta 1
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1332) Scan results out of order
Posted by "Dave Revell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Revell updated CASSANDRA-1332:
-----------------------------------
Attachment: scan_test.patch
System test that reproduces the problem on a 4-node cluster
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1332) Scan results out of order
Posted by "Dave Revell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893472#action_12893472 ]
Dave Revell commented on CASSANDRA-1332:
----------------------------------------
It isn't present in exactly the same form in 0.6.4 because scan() is new in 0.7. Would it be worth testing 0.6.4 get_range_slices and looking for similar behavior?
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Fix For: 0.7.0
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1332) Scan results out of order
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893470#action_12893470 ]
Jonathan Ellis commented on CASSANDRA-1332:
-------------------------------------------
is this also present in 0.6.4?
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Fix For: 0.7.0
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1332) Scan results out of order
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895877#action_12895877 ]
Jonathan Ellis commented on CASSANDRA-1332:
-------------------------------------------
get_range_slices is un-deprecated instead
> Scan results out of order
> -------------------------
>
> Key: CASSANDRA-1332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1332
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7 beta 1
> Environment: CentOS 5, Java 1.6.0, Cassandra trunk as of 28 July 2010
> Reporter: Dave Revell
> Fix For: 0.7.0
>
> Attachments: scan_test.patch
>
>
> After inserting 10 keys ('0', '1', ... '9') and running scan() with start_key='' and count=7, scan() returns the keys ['7', '3', '6', '5', '0', '8', '2']. When I scan() again with start_key='2' and count=7, I get the keys ['2', '1', '9', '4', '7']. Notice that key "7" appears in both result sets, and the relative order of keys "7" and "2" is inconsistent between the two scan results.
> I see the problem when running on a 4-node cluster. When I run on a 1-node cluster, the problem does not occur. So the attached system test always passes, since system tests use a 1-node cluster, so the test doesn't actually demonstrate the problem.
> A standalone Python program that reproduces the problem is at: http://pastebin.com/FwitG4wf
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.