You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Greg Hinkle (JIRA)" <ji...@apache.org> on 2011/05/27 18:43:47 UTC
[jira] [Created] (CASSANDRA-2719) Super Column Counters Increment
on Read
Super Column Counters Increment on Read
---------------------------------------
Key: CASSANDRA-2719
URL: https://issues.apache.org/jira/browse/CASSANDRA-2719
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.8 beta 1
Environment: Tested on 0.8.0-rc1 on both a 3 node cluster and single instance.
Reporter: Greg Hinkle
Running a large number of batch increments on a set of counters in a super CF seems to put some of the counters into a strange state where they increment every time you read from them. Including just doing a list or get from the cli. Will attach test that reproduces problem.
For example, after running the test (and it completing and the process stopping).
[default@Chires] get CountTest[01];
=> (super_column=1306512590369,
(counter=n, value=25625))
Returned 1 results.
[default@Chires] get CountTest[01];
=> (super_column=1306512590369,
(counter=n, value=26610))
Returned 1 results.
>From debug logs at the same time:
DEBUG 12:42:13,899 get_slice
DEBUG 12:42:13,899 Command/ConsistencyLevel is SliceFromReadCommand(table='Chires', key='01', column_parent='QueryPath(columnFamilyName='CountTest', superColumnName='null', columnName='null')', start='', finish='', reversed=false, count=1000000)/ONE
DEBUG 12:42:13,899 Blockfor/repair is 1/true; setting up requests to /127.0.0.2
DEBUG 12:42:13,899 reading data from /127.0.0.2
DEBUG 12:42:13,900 Processing response on a callback from 210570@/127.0.0.2
DEBUG 12:42:13,900 Preprocessed data response
DEBUG 12:42:13,900 Read: 1 ms.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2719) Super Column Counters Increment
on Read
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne resolved CASSANDRA-2719.
-----------------------------------------
Resolution: Duplicate
Fix Version/s: 0.8.0
This turns out to be a duplicate of CASSANDRA-2675. I've thus committed it to 0.8.0 too (it was already committed on the 0.7 and 0.8 branches).
> Super Column Counters Increment on Read
> ---------------------------------------
>
> Key: CASSANDRA-2719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2719
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8 beta 1
> Environment: Tested on 0.8.0-rc1 on both a 3 node cluster and single instance.
> Reporter: Greg Hinkle
> Fix For: 0.8.0
>
> Attachments: SuperCountTest.java
>
>
> Running a large number of batch increments on a set of counters in a super CF seems to put some of the counters into a strange state where they increment every time you read from them. Including just doing a list or get from the cli. Will attach test that reproduces problem.
> For example, after running the test (and it completing and the process stopping).
> [default@Chires] get CountTest[01];
> => (super_column=1306512590369,
> (counter=n, value=25625))
> Returned 1 results.
> [default@Chires] get CountTest[01];
> => (super_column=1306512590369,
> (counter=n, value=26610))
> Returned 1 results.
> From debug logs at the same time:
> DEBUG 12:42:13,899 get_slice
> DEBUG 12:42:13,899 Command/ConsistencyLevel is SliceFromReadCommand(table='Chires', key='01', column_parent='QueryPath(columnFamilyName='CountTest', superColumnName='null', columnName='null')', start='', finish='', reversed=false, count=1000000)/ONE
> DEBUG 12:42:13,899 Blockfor/repair is 1/true; setting up requests to /127.0.0.2
> DEBUG 12:42:13,899 reading data from /127.0.0.2
> DEBUG 12:42:13,900 Processing response on a callback from 210570@/127.0.0.2
> DEBUG 12:42:13,900 Preprocessed data response
> DEBUG 12:42:13,900 Read: 1 ms.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2719) Super Column Counters Increment
on Read
Posted by "Patricio Echague (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040394#comment-13040394 ]
Patricio Echague commented on CASSANDRA-2719:
---------------------------------------------
Greg, what is different in your version of Hector respect the main branch ?
> Super Column Counters Increment on Read
> ---------------------------------------
>
> Key: CASSANDRA-2719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2719
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8 beta 1
> Environment: Tested on 0.8.0-rc1 on both a 3 node cluster and single instance.
> Reporter: Greg Hinkle
> Attachments: SuperCountTest.java
>
>
> Running a large number of batch increments on a set of counters in a super CF seems to put some of the counters into a strange state where they increment every time you read from them. Including just doing a list or get from the cli. Will attach test that reproduces problem.
> For example, after running the test (and it completing and the process stopping).
> [default@Chires] get CountTest[01];
> => (super_column=1306512590369,
> (counter=n, value=25625))
> Returned 1 results.
> [default@Chires] get CountTest[01];
> => (super_column=1306512590369,
> (counter=n, value=26610))
> Returned 1 results.
> From debug logs at the same time:
> DEBUG 12:42:13,899 get_slice
> DEBUG 12:42:13,899 Command/ConsistencyLevel is SliceFromReadCommand(table='Chires', key='01', column_parent='QueryPath(columnFamilyName='CountTest', superColumnName='null', columnName='null')', start='', finish='', reversed=false, count=1000000)/ONE
> DEBUG 12:42:13,899 Blockfor/repair is 1/true; setting up requests to /127.0.0.2
> DEBUG 12:42:13,899 reading data from /127.0.0.2
> DEBUG 12:42:13,900 Processing response on a callback from 210570@/127.0.0.2
> DEBUG 12:42:13,900 Preprocessed data response
> DEBUG 12:42:13,900 Read: 1 ms.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2719) Super Column Counters Increment
on Read
Posted by "Greg Hinkle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Hinkle updated CASSANDRA-2719:
-----------------------------------
Attachment: SuperCountTest.java
Test case of problem. Uses super counter slice feature of hector from https://github.com/ghinkle/hector
However, you can take out the slices from the test and just use the CLI to witness the problem.
> Super Column Counters Increment on Read
> ---------------------------------------
>
> Key: CASSANDRA-2719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2719
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8 beta 1
> Environment: Tested on 0.8.0-rc1 on both a 3 node cluster and single instance.
> Reporter: Greg Hinkle
> Attachments: SuperCountTest.java
>
>
> Running a large number of batch increments on a set of counters in a super CF seems to put some of the counters into a strange state where they increment every time you read from them. Including just doing a list or get from the cli. Will attach test that reproduces problem.
> For example, after running the test (and it completing and the process stopping).
> [default@Chires] get CountTest[01];
> => (super_column=1306512590369,
> (counter=n, value=25625))
> Returned 1 results.
> [default@Chires] get CountTest[01];
> => (super_column=1306512590369,
> (counter=n, value=26610))
> Returned 1 results.
> From debug logs at the same time:
> DEBUG 12:42:13,899 get_slice
> DEBUG 12:42:13,899 Command/ConsistencyLevel is SliceFromReadCommand(table='Chires', key='01', column_parent='QueryPath(columnFamilyName='CountTest', superColumnName='null', columnName='null')', start='', finish='', reversed=false, count=1000000)/ONE
> DEBUG 12:42:13,899 Blockfor/repair is 1/true; setting up requests to /127.0.0.2
> DEBUG 12:42:13,899 reading data from /127.0.0.2
> DEBUG 12:42:13,900 Processing response on a callback from 210570@/127.0.0.2
> DEBUG 12:42:13,900 Preprocessed data response
> DEBUG 12:42:13,900 Read: 1 ms.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2719) Super Column Counters Increment
on Read
Posted by "Greg Hinkle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040403#comment-13040403 ]
Greg Hinkle commented on CASSANDRA-2719:
----------------------------------------
The only differences are that I exposed the replicate on write CF setting and added Super Counter Slice query and some counter range scan support to the api. Just wrappers around the thrift calls.
> Super Column Counters Increment on Read
> ---------------------------------------
>
> Key: CASSANDRA-2719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2719
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.8 beta 1
> Environment: Tested on 0.8.0-rc1 on both a 3 node cluster and single instance.
> Reporter: Greg Hinkle
> Attachments: SuperCountTest.java
>
>
> Running a large number of batch increments on a set of counters in a super CF seems to put some of the counters into a strange state where they increment every time you read from them. Including just doing a list or get from the cli. Will attach test that reproduces problem.
> For example, after running the test (and it completing and the process stopping).
> [default@Chires] get CountTest[01];
> => (super_column=1306512590369,
> (counter=n, value=25625))
> Returned 1 results.
> [default@Chires] get CountTest[01];
> => (super_column=1306512590369,
> (counter=n, value=26610))
> Returned 1 results.
> From debug logs at the same time:
> DEBUG 12:42:13,899 get_slice
> DEBUG 12:42:13,899 Command/ConsistencyLevel is SliceFromReadCommand(table='Chires', key='01', column_parent='QueryPath(columnFamilyName='CountTest', superColumnName='null', columnName='null')', start='', finish='', reversed=false, count=1000000)/ONE
> DEBUG 12:42:13,899 Blockfor/repair is 1/true; setting up requests to /127.0.0.2
> DEBUG 12:42:13,899 reading data from /127.0.0.2
> DEBUG 12:42:13,900 Processing response on a callback from 210570@/127.0.0.2
> DEBUG 12:42:13,900 Preprocessed data response
> DEBUG 12:42:13,900 Read: 1 ms.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira