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 2015/07/08 03:27:04 UTC
[jira] [Comment Edited] (CASSANDRA-9102) Consistency levels such as
non-local quorum need better tests
[ https://issues.apache.org/jira/browse/CASSANDRA-9102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617799#comment-14617799 ]
Stefania edited comment on CASSANDRA-9102 at 7/8/15 1:26 AM:
-------------------------------------------------------------
bq. Do you happen to have a hash for the version you generated the coverage for?
Unfortunately not. Trunk on June 23 is all the information I have I am afraid.
bq. Slightly more flexible might be to be able to annotate the request to indicate that the request wants some specific kind of failure injection. We already have support for tacking stuff onto requests for tracing. Maybe that can be adapted?
It's worth considering. This is already the third case where I encounter the need to inject some failures in order to test a feature, the other cases are CASSANDRA-7392 and CASSANDRA-8592. Both are currently tested via a system property that injects some behavior, but this is not very flexible and impacting production code too. Attaching the information to the request could be better. There is also another need, and that is for dtests to inject some java code to a specific Cassandra process, for example to test CASSANDRA-9601 as discussed in the dtest pr [here|https://github.com/riptano/cassandra-dtest/pull/350]. Here we could have used an authenticator or authorizer implementation that takes a longer time to test the connection timeout. These two interfaces can be replaced with a yaml setting. So we could combine the two things and install some test hooks that get triggered all the time (via yaml or system property) or only when a request carries a specific id.
We should also verify if [byteman|http://byteman.jboss.org] can inject the code that we need rather than rely on yaml or system properties or message flags, see CASSANDRA-9165. Perhaps I (or someone else) should take this ticket (cc [~benedict] who already mentioned it to me) and extend it to provide a fault injection mechanism supporting both unit and dtests?
was (Author: stefania):
bq. Do you happen to have a hash for the version you generated the coverage for?
Unfortunately not. Trunk on June 23 is all the information I have I am afraid.
bq. Slightly more flexible might be to be able to annotate the request to indicate that the request wants some specific kind of failure injection. We already have support for tacking stuff onto requests for tracing. Maybe that can be adapted?
It's worth considering. This is already the third case where I encounter the need to inject some failures in order to test a feature, the other cases are CASSANDRA-7392 and CASSANDRA-8592. Both are currently tested via a system property that injects some behavior, but this is not very flexible and impacting production code too. Attaching the information to the request could be better. There is also another need, and that is for dtests to inject some java code to a specific Cassandra process, for example to test CASSANDRA-9601 as discussed in the dtest pr [here|https://github.com/riptano/cassandra-dtest/pull/350]. Here we could have used an authenticator or authorizer implementation that takes a longer time to test the connection timeout. These two interfaces can be replaced with a yaml setting. So we could combine the two things and install some test hooks that get triggered all the time (via yaml or system property) or only when a request carries a specific id.
We should also verify if [bytemap|http://byteman.jboss.org] can inject the code that we need rather than rely on yaml or system properties or message flags, see CASSANDRA-9165. Perhaps I (or someone else) should take this ticket (cc [~benedict] who already mentioned it to me) and extend it to provide a fault injection mechanism supporting both unit and dtests?
> Consistency levels such as non-local quorum need better tests
> -------------------------------------------------------------
>
> Key: CASSANDRA-9102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9102
> Project: Cassandra
> Issue Type: Test
> Reporter: Ariel Weisberg
> Assignee: Stefania
> Attachments: jacoco.diff, jacoco.tar.gz
>
>
> We didn't catch unit testing for this functionality. There is dtest consistency_test but it doesn't cover non-local functionality.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)