[
https://issues.apache.org/jira/browse/CASSANDRA-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147795#comment-13147795
]
Sylvain Lebresne commented on CASSANDRA-3465:
---------------------------------------------
{quote}
But I don't know why you think it comes from the CL, because I thought the CL
shoudn't change the way that data are written but just the number of node we
need to request before returning the information. After performing a repair on
all nodes, shouldn't I have the same results with CL.ONE, CL.QUORUM or CL.ALL ?
"And getting the results you get at CL.ONE is not surprising." --> Why not ?
{quote}
The code you've pasted is not guaranteed to show a value of 10 for each counter
at the end of the test with CL.ONE. That's the way CL.ONE works. The last reads
at CL.ONE will only hit one node X before returning, but if the writes were at
CL.ONE, they also wait for only one node Y and so there is no guarantee that X
== Y every time. So in a test like the one you've pasted where you do inserts
and reads in rapid succession, you have a very good change of not getting 10
for each counters at the end. Yes, eventually all node should get 10, and yes,
if you run some repair you should be guaranteed to see 10 everywhere, but I
guess what I'm saying is that QUORUM (or ALL) gives the guarantee that at the
end of the test all counters should be 10, so let's not bother with CL.ONE and
all the 'but' that comes with it if we don't have to.
Now the thing is, I tried your exact code with phpcassa and was still not able
to reproduce. Which makes it kind of hard to debug. And I looked at the logs,
but there is not enough info to really help. So the best I can offer is the
attached patch with added debug messages. If you are willing to apply this
patch (you will likely need to use the current 1.0 branch, from svn or
https://github.com/apache/cassandra), and redo the test at QUORUM or ALL with
debug enabled and send the logs. There should be enough info to help to at
least get a fair idea of what is wrong. But if you could stop opscenter when
doing so, that would be awesome, because it generates lots of garbage in the
log that makes it harder to look at.
> Wrong counters values when RF > 1
> ---------------------------------
>
> Key: CASSANDRA-3465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3465
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0
> Environment: Amazon EC2 (cluster of 5 t1.micro), phpCassa 0.8.a.2
> Reporter: Alain RODRIGUEZ
> Assignee: Sylvain Lebresne
> Priority: Critical
> Attachments: 0001-add-debug-infos.patch, logServer0.log,
> logServer0_cl_all.log, logServer1.log, logServer1_cl_all.log, logServer2.log,
> logServer2_cl_all.log
>
>
> I have got a CF that contains many counters of some events. When I'm at RF =
> 1 and simulate 10 events, they are well counted.
> However, when I switch to a RF = 3, my counter show a wrong value that
> sometimes change when requested twice (it can return 7, then 5 instead of 10
> all the time).
> I first thought that it was a problem of CL because I seem to remember that I
> read once that I had to use CL.One for reads and writes with counters. So I
> tried with CL.One, without success...
> /*-------------------------------------------------- CODE
> -------------------------------------------------------*/
> $servers = array("ec2-xxx-xxx-xxx-xxx.eu-west-1.compute.amazonaws.com",
> "ec2-yyy-yyy-yyy-yyy.eu-west-1.compute.amazonaws.com",
> "ec2-zzz-zzz-zzz-zzz.eu-west-1.compute.amazonaws.com",
> "ec2-aaa-aaa-aaa-aaa.eu-west-1.compute.amazonaws.com",
> "ec2-bbb-bbb-bbb-bbb.eu-west-1.compute.amazonaws.com");
> $pool = new ConnectionPool("mykeyspace", $servers);
> $stats_test = new ColumnFamily($pool, 'stats_test',
> $read_consistency_level=cassandra_ConsistencyLevel::ONE,
> $write_consistency_level=cassandra_ConsistencyLevel::ONE);
>
> $time = date( 'YmdH', time());
>
> for($i=0; $i<10; $i++){
> for($c=1; $c<=3; $c++){
> $stats_test->add($c, $time.':test');
> }
> $counts = $stats_test->multiget(array(1,2,3));
> echo('Counter1: '.$counts[1][$time.':test']."\n");
> echo('Counter2: '.$counts[2][$time.':test']."\n");
> echo('Counter3: '.$counts[3][$time.':test']."\n\n");
> }
> /*-------------------------------- END OF CODE
> -------------------------------------------------------------------------*/
> /*-------------------------------------------------- OUTPUT
> ------------------------------------------------------------*/
> Counter1: 1
> Counter2: 1
> Counter3: 1
> Counter1: 2
> Counter2: 2
> Counter3: 2
> Counter1: 3
> Counter2: 3
> Counter3: 3
> Counter1: 3
> Counter2: 4
> Counter3: 4
> Counter1: 4
> Counter2: 5
> Counter3: 3
> Counter1: 5
> Counter2: 6
> Counter3: 3
> Counter1: 6
> Counter2: 7
> Counter3: 4
> Counter1: 4
> Counter2: 8
> Counter3: 7
> Counter1: 5
> Counter2: 9
> Counter3: 8
> Counter1: 8
> Counter2: 4
> Counter3: 9
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
