You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stefania (JIRA)" <ji...@apache.org> on 2016/08/18 08:24:20 UTC

[jira] [Comment Edited] (CASSANDRA-12092) dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters

    [ https://issues.apache.org/jira/browse/CASSANDRA-12092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425952#comment-15425952 ] 

Stefania edited comment on CASSANDRA-12092 at 8/18/16 8:23 AM:
---------------------------------------------------------------

Unfortunately there was still one [failure|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-dtest-multiplex/17/testReport/junit/node_3_iter_169.consistency_test/TestAccuracy/test_simple_strategy_counters/] out of 1000 attempts, and that was on trunk, not 2.1.

I've reduced the number of debug log messages to just one, which is essential to confirm that we are reading from the host we contacted. I've launched one more [multiplexed run|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-dtest-multiplex/20/] hoping that with one single debug log message we can reproduce the failure. This should tell us if the problem is with the test or in Cassandra. If we still cannot reproduce it, I propose to relax the test. I've already added one unit test to ensure that we can correctly read counter values that are updated by a different thread.


was (Author: stefania):
Unfortunately there was still one [failure|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-dtest-multiplex/17/testReport/junit/node_3_iter_169.consistency_test/TestAccuracy/test_simple_strategy_counters/] out of 1000 attempts.

I've reduced the number of debug log messages to just one, which is essential to confirm that we are reading from the host we contacted. I will perform one more multiplexed run hoping that with one single debug log message we can reproduce the failure. This would tell us if the problem is with the test or in Cassandra. If we still cannot reproduce it, I propose to relax the test for 2.1. I've already added one unit test to ensure that we can correctly read counter values that are updated by a different thread.

> dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
> ----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-12092
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12092
>             Project: Cassandra
>          Issue Type: Test
>            Reporter: Sean McCarthy
>            Assignee: Stefania
>              Labels: dtest
>         Attachments: node1.log, node2.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest/484/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters
> Failed on CassCI build cassandra-2.1_dtest #484
> {code}
> Standard Error
> Traceback (most recent call last):
>   File "/home/automaton/cassandra-dtest/consistency_test.py", line 514, in run
>     valid_fcn(v)
>   File "/home/automaton/cassandra-dtest/consistency_test.py", line 497, in validate_counters
>     check_all_sessions(s, n, c)
>   File "/home/automaton/cassandra-dtest/consistency_test.py", line 490, in check_all_sessions
>     "value of %s at key %d, instead got these values: %s" % (write_nodes, val, n, results)
> AssertionError: Failed to read value from sufficient number of nodes, required 2 nodes to have a counter value of 1 at key 200, instead got these values: [0, 0, 1]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)