[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597549#comment-16597549 ] Michael Kjellman commented on CASSANDRA-14298: -- [~krummas] i’m donating the cassandra-test repository along with the Dockerfile to the ASF. test away ;) > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13304) Add checksumming to the native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16572177#comment-16572177
]
Michael Kjellman commented on CASSANDRA-13304:
--
we’ve got almost a year of testing on the current code with hundreds of
billions of requests and we even caught (and protected against) a host flipping
bits in the process..
> Add checksumming to the native protocol
> ---
>
> Key: CASSANDRA-13304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13304
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Michael Kjellman
>Assignee: Sam Tunnicliffe
>Priority: Blocker
> Labels: client-impacting
> Fix For: 4.x
>
> Attachments: 13304_v1.diff, boxplot-read-throughput.png,
> boxplot-write-throughput.png
>
>
> The native binary transport implementation doesn't include checksums. This
> makes it highly susceptible to silently inserting corrupted data either due
> to hardware issues causing bit flips on the sender/client side, C*/receiver
> side, or network in between.
> Attaching an implementation that makes checksum'ing mandatory (assuming both
> client and server know about a protocol version that supports checksums) --
> and also adds checksumming to clients that request compression.
> The serialized format looks something like this:
> {noformat}
> * 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
> * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Number of Compressed Chunks | Compressed Length (e1)/
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * / Compressed Length cont. (e1) |Uncompressed Length (e1) /
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Uncompressed Length cont. (e1)| CRC32 Checksum of Lengths (e1)|
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Checksum of Lengths cont. (e1)|Compressed Bytes (e1)+//
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | CRC32 Checksum (e1) ||
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |Compressed Length (e2) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Uncompressed Length (e2)|
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |CRC32 Checksum of Lengths (e2) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Compressed Bytes (e2) +//
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | CRC32 Checksum (e2) ||
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |Compressed Length (en) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Uncompressed Length (en)|
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |CRC32 Checksum of Lengths (en) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Compressed Bytes (en) +//
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | CRC32 Checksum (en) ||
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> {noformat}
> The first pass here adds checksums only to the actual contents of the frame
> body itself (and doesn't actually checksum lengths and headers). While it
> would be great to fully add checksuming across the entire protocol, the
> proposed implementation will ensure we at least catch corrupted data and
> likely protect ourselves pretty well anyways.
> I didn't go to the trouble of implementing a Snappy Checksum'ed Compressor
> implementation as it's been deprecated for a while -- is really slow and
> crappy compared to LZ4 -- and we should do everything in our power to make
> sure no one in the community is still using it. I left it in (for obvious
> backwards compatibility aspects) old for clients that don't know about the
> new protocol.
> The current protocol has a 256MB (max) frame body -- where the serialized
> contents are simply written in to the frame body.
> If the client sends a compression option in the startup, we will install a
> FrameCompressor inline. Unfortunately, we went with a decision to treat the
> frame body separately
[jira] [Commented] (CASSANDRA-13304) Add checksumming to the native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16572174#comment-16572174
]
Michael Kjellman commented on CASSANDRA-13304:
--
and the last patch i did already made it possible to opt out...
> Add checksumming to the native protocol
> ---
>
> Key: CASSANDRA-13304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13304
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Michael Kjellman
>Assignee: Sam Tunnicliffe
>Priority: Blocker
> Labels: client-impacting
> Fix For: 4.x
>
> Attachments: 13304_v1.diff, boxplot-read-throughput.png,
> boxplot-write-throughput.png
>
>
> The native binary transport implementation doesn't include checksums. This
> makes it highly susceptible to silently inserting corrupted data either due
> to hardware issues causing bit flips on the sender/client side, C*/receiver
> side, or network in between.
> Attaching an implementation that makes checksum'ing mandatory (assuming both
> client and server know about a protocol version that supports checksums) --
> and also adds checksumming to clients that request compression.
> The serialized format looks something like this:
> {noformat}
> * 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
> * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Number of Compressed Chunks | Compressed Length (e1)/
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * / Compressed Length cont. (e1) |Uncompressed Length (e1) /
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Uncompressed Length cont. (e1)| CRC32 Checksum of Lengths (e1)|
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Checksum of Lengths cont. (e1)|Compressed Bytes (e1)+//
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | CRC32 Checksum (e1) ||
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |Compressed Length (e2) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Uncompressed Length (e2)|
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |CRC32 Checksum of Lengths (e2) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Compressed Bytes (e2) +//
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | CRC32 Checksum (e2) ||
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |Compressed Length (en) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Uncompressed Length (en)|
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |CRC32 Checksum of Lengths (en) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Compressed Bytes (en) +//
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | CRC32 Checksum (en) ||
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> {noformat}
> The first pass here adds checksums only to the actual contents of the frame
> body itself (and doesn't actually checksum lengths and headers). While it
> would be great to fully add checksuming across the entire protocol, the
> proposed implementation will ensure we at least catch corrupted data and
> likely protect ourselves pretty well anyways.
> I didn't go to the trouble of implementing a Snappy Checksum'ed Compressor
> implementation as it's been deprecated for a while -- is really slow and
> crappy compared to LZ4 -- and we should do everything in our power to make
> sure no one in the community is still using it. I left it in (for obvious
> backwards compatibility aspects) old for clients that don't know about the
> new protocol.
> The current protocol has a 256MB (max) frame body -- where the serialized
> contents are simply written in to the frame body.
> If the client sends a compression option in the startup, we will install a
> FrameCompressor inline. Unfortunately, we went with a decision to treat the
> frame body separately from the header bits etc in a given message. So,
> instead we put a compressor implementation in the options and
[jira] [Commented] (CASSANDRA-13304) Add checksumming to the native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16572170#comment-16572170
]
Michael Kjellman commented on CASSANDRA-13304:
--
given we really should be looking to move to zstandard i’m not sure why we’d
double down on something specific to lz4. i’m not sure i agree this is that
much of a burden... it’s not like the logic is that complicated.
> Add checksumming to the native protocol
> ---
>
> Key: CASSANDRA-13304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13304
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Michael Kjellman
>Assignee: Sam Tunnicliffe
>Priority: Blocker
> Labels: client-impacting
> Fix For: 4.x
>
> Attachments: 13304_v1.diff, boxplot-read-throughput.png,
> boxplot-write-throughput.png
>
>
> The native binary transport implementation doesn't include checksums. This
> makes it highly susceptible to silently inserting corrupted data either due
> to hardware issues causing bit flips on the sender/client side, C*/receiver
> side, or network in between.
> Attaching an implementation that makes checksum'ing mandatory (assuming both
> client and server know about a protocol version that supports checksums) --
> and also adds checksumming to clients that request compression.
> The serialized format looks something like this:
> {noformat}
> * 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
> * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Number of Compressed Chunks | Compressed Length (e1)/
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * / Compressed Length cont. (e1) |Uncompressed Length (e1) /
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Uncompressed Length cont. (e1)| CRC32 Checksum of Lengths (e1)|
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Checksum of Lengths cont. (e1)|Compressed Bytes (e1)+//
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | CRC32 Checksum (e1) ||
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |Compressed Length (e2) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Uncompressed Length (e2)|
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |CRC32 Checksum of Lengths (e2) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Compressed Bytes (e2) +//
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | CRC32 Checksum (e2) ||
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |Compressed Length (en) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Uncompressed Length (en)|
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * |CRC32 Checksum of Lengths (en) |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Compressed Bytes (en) +//
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | CRC32 Checksum (en) ||
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> {noformat}
> The first pass here adds checksums only to the actual contents of the frame
> body itself (and doesn't actually checksum lengths and headers). While it
> would be great to fully add checksuming across the entire protocol, the
> proposed implementation will ensure we at least catch corrupted data and
> likely protect ourselves pretty well anyways.
> I didn't go to the trouble of implementing a Snappy Checksum'ed Compressor
> implementation as it's been deprecated for a while -- is really slow and
> crappy compared to LZ4 -- and we should do everything in our power to make
> sure no one in the community is still using it. I left it in (for obvious
> backwards compatibility aspects) old for clients that don't know about the
> new protocol.
> The current protocol has a 256MB (max) frame body -- where the serialized
> contents are simply written in to the frame body.
> If the client sends a compression option in the startup, we will install a
> FrameCompressor inline. Unfortunately, we went with a
[jira] [Commented] (CASSANDRA-14293) Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE and FIXED Policies
[ https://issues.apache.org/jira/browse/CASSANDRA-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16410167#comment-16410167 ] Michael Kjellman commented on CASSANDRA-14293: -- changes look fine to me. let's get this committed on to trunk to start with so we can start working on a 3.0 version... > Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE > and FIXED Policies > - > > Key: CASSANDRA-14293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14293 > Project: Cassandra > Issue Type: Improvement >Reporter: Michael Kjellman >Assignee: Michael Kjellman >Priority: Major > Fix For: 4.x > > > Currently the Speculative Retry Policy takes a single string as a parameter, > this can be NONE, ALWAYS, 99PERCENTILE (PERCENTILE), 50MS (CUSTOM). > The problem we have is when a single host goes into a bad state this drags up > the percentiles. This means if we are set to use p99 alone, we might not > speculate when we intended to to because the value at the specified > percentile has gone so high. > As a fix we need to have support for something like min(99percentile,50ms) > this means if the normal p99 for the table is <50ms, we will still speculate > at this value and not drag the happy path tail latencies up... but if the > p99th goes above what we know we should never exceed we use that instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14247) SASI tokenizer for simple delimiter based entries
[
https://issues.apache.org/jira/browse/CASSANDRA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399968#comment-16399968
]
Michael Kjellman commented on CASSANDRA-14247:
--
docs look awesome!! ship it!
> SASI tokenizer for simple delimiter based entries
> -
>
> Key: CASSANDRA-14247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14247
> Project: Cassandra
> Issue Type: Improvement
> Components: sasi
>Reporter: mck
>Assignee: mck
>Priority: Major
> Labels: sasi
> Fix For: 4.0, 3.11.x
>
>
> Currently SASI offers only two tokenizer options:
> - NonTokenizerAnalyser
> - StandardAnalyzer
> The latter is built upon Snowball, powerful for human languages but overkill
> for simple tokenization.
> A simple tokenizer is proposed here. The need for this arose as a workaround
> of CASSANDRA-11182, and to avoid the disk usage explosion when having to
> resort to {{CONTAINS}}. See https://github.com/openzipkin/zipkin/issues/1861
> Example use of this would be:
> {code}
> CREATE CUSTOM INDEX span_annotation_query_idx
> ON zipkin2.span (annotation_query) USING
> 'org.apache.cassandra.index.sasi.SASIIndex'
> WITH OPTIONS = {
> 'analyzer_class':
> 'org.apache.cassandra.index.sasi.analyzer.DelimiterAnalyzer',
> 'delimiter': '░',
> 'case_sensitive': 'true',
> 'mode': 'prefix',
> 'analyzed': 'true'};
> {code}
> Original credit for this work goes to https://github.com/zuochangan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14247) SASI tokenizer for simple delimiter based entries
[
https://issues.apache.org/jira/browse/CASSANDRA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399887#comment-16399887
]
Michael Kjellman commented on CASSANDRA-14247:
--
latest commit looks good so +1 on the latest commits! the only other thought i
have is if the in-tree documentation needs to be updated give this is something
people interact with via CQL and schema updates.
> SASI tokenizer for simple delimiter based entries
> -
>
> Key: CASSANDRA-14247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14247
> Project: Cassandra
> Issue Type: Improvement
> Components: sasi
>Reporter: mck
>Assignee: mck
>Priority: Major
> Labels: sasi
> Fix For: 4.0, 3.11.x
>
>
> Currently SASI offers only two tokenizer options:
> - NonTokenizerAnalyser
> - StandardAnalyzer
> The latter is built upon Snowball, powerful for human languages but overkill
> for simple tokenization.
> A simple tokenizer is proposed here. The need for this arose as a workaround
> of CASSANDRA-11182, and to avoid the disk usage explosion when having to
> resort to {{CONTAINS}}. See https://github.com/openzipkin/zipkin/issues/1861
> Example use of this would be:
> {code}
> CREATE CUSTOM INDEX span_annotation_query_idx
> ON zipkin2.span (annotation_query) USING
> 'org.apache.cassandra.index.sasi.SASIIndex'
> WITH OPTIONS = {
> 'analyzer_class':
> 'org.apache.cassandra.index.sasi.analyzer.DelimiterAnalyzer',
> 'delimiter': '░',
> 'case_sensitive': 'true',
> 'mode': 'prefix',
> 'analyzed': 'true'};
> {code}
> Original credit for this work goes to https://github.com/zuochangan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14293) Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE and FIXED Policies
[ https://issues.apache.org/jira/browse/CASSANDRA-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kjellman updated CASSANDRA-14293: - Reviewer: Aleksey Yeschenko > Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE > and FIXED Policies > - > > Key: CASSANDRA-14293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14293 > Project: Cassandra > Issue Type: Improvement >Reporter: Michael Kjellman >Assignee: Michael Kjellman >Priority: Major > > Currently the Speculative Retry Policy takes a single string as a parameter, > this can be NONE, ALWAYS, 99PERCENTILE (PERCENTILE), 50MS (CUSTOM). > The problem we have is when a single host goes into a bad state this drags up > the percentiles. This means if we are set to use p99 alone, we might not > speculate when we intended to to because the value at the specified > percentile has gone so high. > As a fix we need to have support for something like min(99percentile,50ms) > this means if the normal p99 for the table is <50ms, we will still speculate > at this value and not drag the happy path tail latencies up... but if the > p99th goes above what we know we should never exceed we use that instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14293) Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE and FIXED Policies
[ https://issues.apache.org/jira/browse/CASSANDRA-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16389070#comment-16389070 ] Michael Kjellman commented on CASSANDRA-14293: -- trunk based branch with a commit for this: [https://github.com/mkjellman/cassandra/tree/37818459_trunk] > Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE > and FIXED Policies > - > > Key: CASSANDRA-14293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14293 > Project: Cassandra > Issue Type: Improvement >Reporter: Michael Kjellman >Assignee: Michael Kjellman >Priority: Major > > Currently the Speculative Retry Policy takes a single string as a parameter, > this can be NONE, ALWAYS, 99PERCENTILE (PERCENTILE), 50MS (CUSTOM). > The problem we have is when a single host goes into a bad state this drags up > the percentiles. This means if we are set to use p99 alone, we might not > speculate when we intended to to because the value at the specified > percentile has gone so high. > As a fix we need to have support for something like min(99percentile,50ms) > this means if the normal p99 for the table is <50ms, we will still speculate > at this value and not drag the happy path tail latencies up... but if the > p99th goes above what we know we should never exceed we use that instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14293) Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE and FIXED Policies
[ https://issues.apache.org/jira/browse/CASSANDRA-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kjellman updated CASSANDRA-14293: - Status: Patch Available (was: Open) > Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE > and FIXED Policies > - > > Key: CASSANDRA-14293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14293 > Project: Cassandra > Issue Type: Improvement >Reporter: Michael Kjellman >Assignee: Michael Kjellman >Priority: Major > > Currently the Speculative Retry Policy takes a single string as a parameter, > this can be NONE, ALWAYS, 99PERCENTILE (PERCENTILE), 50MS (CUSTOM). > The problem we have is when a single host goes into a bad state this drags up > the percentiles. This means if we are set to use p99 alone, we might not > speculate when we intended to to because the value at the specified > percentile has gone so high. > As a fix we need to have support for something like min(99percentile,50ms) > this means if the normal p99 for the table is <50ms, we will still speculate > at this value and not drag the happy path tail latencies up... but if the > p99th goes above what we know we should never exceed we use that instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14293) Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE and FIXED Policies
[ https://issues.apache.org/jira/browse/CASSANDRA-14293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16389067#comment-16389067 ] Michael Kjellman commented on CASSANDRA-14293: -- Ideally we'd express this a bit nicer by having the speculative_retry table config option as a map, but we're bound by legacy here and have no way to migrate and change this with the current state of schema. So, ultimately we'll still need to do a bunch of string parsing but we can at least get the functionality we need with the following function-esque syntax (examples): max(99.9p,50ms) MIN(50MS,90PERCENTILE) > Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE > and FIXED Policies > - > > Key: CASSANDRA-14293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14293 > Project: Cassandra > Issue Type: Improvement >Reporter: Michael Kjellman >Assignee: Michael Kjellman >Priority: Major > > Currently the Speculative Retry Policy takes a single string as a parameter, > this can be NONE, ALWAYS, 99PERCENTILE (PERCENTILE), 50MS (CUSTOM). > The problem we have is when a single host goes into a bad state this drags up > the percentiles. This means if we are set to use p99 alone, we might not > speculate when we intended to to because the value at the specified > percentile has gone so high. > As a fix we need to have support for something like min(99percentile,50ms) > this means if the normal p99 for the table is <50ms, we will still speculate > at this value and not drag the happy path tail latencies up... but if the > p99th goes above what we know we should never exceed we use that instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14293) Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE and FIXED Policies
Michael Kjellman created CASSANDRA-14293: Summary: Speculative Retry Policy Should Support Specifying MIN/MAX of 2 PERCENTILE and FIXED Policies Key: CASSANDRA-14293 URL: https://issues.apache.org/jira/browse/CASSANDRA-14293 Project: Cassandra Issue Type: Improvement Reporter: Michael Kjellman Assignee: Michael Kjellman Currently the Speculative Retry Policy takes a single string as a parameter, this can be NONE, ALWAYS, 99PERCENTILE (PERCENTILE), 50MS (CUSTOM). The problem we have is when a single host goes into a bad state this drags up the percentiles. This means if we are set to use p99 alone, we might not speculate when we intended to to because the value at the specified percentile has gone so high. As a fix we need to have support for something like min(99percentile,50ms) this means if the normal p99 for the table is <50ms, we will still speculate at this value and not drag the happy path tail latencies up... but if the p99th goes above what we know we should never exceed we use that instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14247) SASI tokenizer for simple delimiter based entries
[
https://issues.apache.org/jira/browse/CASSANDRA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380027#comment-16380027
]
Michael Kjellman commented on CASSANDRA-14247:
--
and another thought as i’m about to fall asleep: might want to add an option to
determine if we should iterate the text left or right or right to left so we
can support right to left languages
> SASI tokenizer for simple delimiter based entries
> -
>
> Key: CASSANDRA-14247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14247
> Project: Cassandra
> Issue Type: Improvement
> Components: sasi
>Reporter: mck
>Assignee: mck
>Priority: Major
> Fix For: 4.0, 3.11.x
>
>
> Currently SASI offers only two tokenizer options:
> - NonTokenizerAnalyser
> - StandardAnalyzer
> The latter is built upon Snowball, powerful for human languages but overkill
> for simple tokenization.
> A simple tokenizer is proposed here. The need for this arose as a workaround
> of CASSANDRA-11182, and to avoid the disk usage explosion when having to
> resort to {{CONTAINS}}. See https://github.com/openzipkin/zipkin/issues/1861
> Example use of this would be:
> {code}
> CREATE CUSTOM INDEX span_annotation_query_idx
> ON zipkin2.span (annotation_query) USING
> 'org.apache.cassandra.index.sasi.SASIIndex'
> WITH OPTIONS = {
> 'analyzer_class':
> 'org.apache.cassandra.index.sasi.analyzer.DelimiterAnalyzer',
> 'delimiter': '░',
> 'case_sensitive': 'true',
> 'mode': 'prefix',
> 'analyzed': 'true'};
> {code}
> Original credit for this work goes to https://github.com/zuochangan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14247) SASI tokenizer for simple delimiter based entries
[
https://issues.apache.org/jira/browse/CASSANDRA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380009#comment-16380009
]
Michael Kjellman commented on CASSANDRA-14247:
--
one other quick thought: we should have a way to escape the delimiter. when
doing change to attempt and do iteratively seems easy to check if last
character was escape character and not split if it was there or whatever
> SASI tokenizer for simple delimiter based entries
> -
>
> Key: CASSANDRA-14247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14247
> Project: Cassandra
> Issue Type: Improvement
> Components: sasi
>Reporter: mck
>Assignee: mck
>Priority: Major
> Fix For: 4.0, 3.11.x
>
>
> Currently SASI offers only two tokenizer options:
> - NonTokenizerAnalyser
> - StandardAnalyzer
> The latter is built upon Snowball, powerful for human languages but overkill
> for simple tokenization.
> A simple tokenizer is proposed here. The need for this arose as a workaround
> of CASSANDRA-11182, and to avoid the disk usage explosion when having to
> resort to {{CONTAINS}}. See https://github.com/openzipkin/zipkin/issues/1861
> Example use of this would be:
> {code}
> CREATE CUSTOM INDEX span_annotation_query_idx
> ON zipkin2.span (annotation_query) USING
> 'org.apache.cassandra.index.sasi.SASIIndex'
> WITH OPTIONS = {
> 'analyzer_class':
> 'org.apache.cassandra.index.sasi.analyzer.DelimiterAnalyzer',
> 'delimiter': '░',
> 'case_sensitive': 'true',
> 'mode': 'prefix',
> 'analyzed': 'true'};
> {code}
> Original credit for this work goes to https://github.com/zuochangan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14247) SASI tokenizer for simple delimiter based entries
[
https://issues.apache.org/jira/browse/CASSANDRA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379642#comment-16379642
]
Michael Kjellman commented on CASSANDRA-14247:
--
1) I think it would be better if we used a "," or " " for the default delimiter
2) I think it would be better if we do the work inside the iterator itself vs.
using the split() function on the entire contents of the string in reset(). If
we can do it iteratively we can then potentially reuse buffers and just go
character by character until we hit the delimiter vs. needing to process the
whole thing, no? Or did you benchmark this and find even with potentially large
strings there wasn't a win?
3) When you hit a MarshalException you're logging the whole thing.. if the
value is a 30MB text blob – the logger would get slammed so not sure logging
the entire thing by default is ideal. thoughts?
> SASI tokenizer for simple delimiter based entries
> -
>
> Key: CASSANDRA-14247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14247
> Project: Cassandra
> Issue Type: Improvement
> Components: sasi
>Reporter: mck
>Assignee: mck
>Priority: Major
> Fix For: 4.0, 3.11.x
>
>
> Currently SASI offers only two tokenizer options:
> - NonTokenizerAnalyser
> - StandardAnalyzer
> The latter is built upon Snowball, powerful for human languages but overkill
> for simple tokenization.
> A simple tokenizer is proposed here. The need for this arose as a workaround
> of CASSANDRA-11182, and to avoid the disk usage explosion when having to
> resort to {{CONTAINS}}. See https://github.com/openzipkin/zipkin/issues/1861
> Example use of this would be:
> {code}
> CREATE CUSTOM INDEX span_annotation_query_idx
> ON zipkin2.span (annotation_query) USING
> 'org.apache.cassandra.index.sasi.SASIIndex'
> WITH OPTIONS = {
> 'analyzer_class':
> 'org.apache.cassandra.index.sasi.analyzer.DelimiterAnalyzer',
> 'delimiter': '░',
> 'case_sensitive': 'true',
> 'mode': 'prefix',
> 'analyzed': 'true'};
> {code}
> Original credit for this work goes to https://github.com/zuochangan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14247) SASI tokenizer for simple delimiter based entries
[
https://issues.apache.org/jira/browse/CASSANDRA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379161#comment-16379161
]
Michael Kjellman commented on CASSANDRA-14247:
--
[~michaelsembwever]: what's the reasoning for using "░" as the delimiter?
> SASI tokenizer for simple delimiter based entries
> -
>
> Key: CASSANDRA-14247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14247
> Project: Cassandra
> Issue Type: Improvement
> Components: sasi
>Reporter: mck
>Assignee: mck
>Priority: Major
> Fix For: 4.0, 3.11.x
>
>
> Currently SASI offers only two tokenizer options:
> - NonTokenizerAnalyser
> - StandardAnalyzer
> The latter is built upon Snowball, powerful for human languages but overkill
> for simple tokenization.
> A simple tokenizer is proposed here. The need for this arose as a workaround
> of CASSANDRA-11182, and to avoid the disk usage explosion when having to
> resort to {{CONTAINS}}. See https://github.com/openzipkin/zipkin/issues/1861
> Example use of this would be:
> {code}
> CREATE CUSTOM INDEX span_annotation_query_idx
> ON zipkin2.span (annotation_query) USING
> 'org.apache.cassandra.index.sasi.SASIIndex'
> WITH OPTIONS = {
> 'analyzer_class':
> 'org.apache.cassandra.index.sasi.analyzer.DelimiterAnalyzer',
> 'delimiter': '░',
> 'case_sensitive': 'true',
> 'mode': 'prefix',
> 'analyzed': 'true'};
> {code}
> Original credit for this work goes to https://github.com/zuochangan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14002) Don't use SHA256 when building merkle trees
[ https://issues.apache.org/jira/browse/CASSANDRA-14002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16378941#comment-16378941 ] Michael Kjellman commented on CASSANDRA-14002: -- +1 to rebase. > Don't use SHA256 when building merkle trees > --- > > Key: CASSANDRA-14002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14002 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Major > Fix For: 4.x > > > We should avoid using SHA-2 when building merkle trees as we don't need a > cryptographic hash function for this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14247) SASI tokenizer for simple delimiter based entries
[
https://issues.apache.org/jira/browse/CASSANDRA-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16374981#comment-16374981
]
Michael Kjellman commented on CASSANDRA-14247:
--
i'll try to take a look shortly
> SASI tokenizer for simple delimiter based entries
> -
>
> Key: CASSANDRA-14247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14247
> Project: Cassandra
> Issue Type: Improvement
> Components: sasi
>Reporter: mck
>Assignee: mck
>Priority: Major
> Fix For: 4.0, 3.11.x
>
>
> Currently SASI offers only two tokenizer options:
> - NonTokenizerAnalyser
> - StandardAnalyzer
> The latter is built upon Snowball, powerful for human languages but overkill
> for simple tokenization.
> A simple tokenizer is proposed here. The need for this arose as a workaround
> of CASSANDRA-11182, and to avoid the disk usage explosion when having to
> resort to {{CONTAINS}}. See https://github.com/openzipkin/zipkin/issues/1861
> Example use of this would be:
> {code}
> CREATE CUSTOM INDEX span_annotation_query_idx
> ON zipkin2.span (annotation_query) USING
> 'org.apache.cassandra.index.sasi.SASIIndex'
> WITH OPTIONS = {
> 'analyzer_class':
> 'org.apache.cassandra.index.sasi.analyzer.DelimiterTokenizerAnalyzer',
> 'delimiter': '░',
> 'case_sensitive': 'true',
> 'mode': 'prefix',
> 'analyzed': 'true'};
> {code}
> Original credit for this work goes to https://github.com/zuochangan
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347636#comment-16347636 ] Michael Kjellman commented on CASSANDRA-14134: -- [~jay.zhuang] I was planning on doing that as a separate ticket/commit. got a bit sidelined with some other issues – hoping to get it done by EOD today. I'll ping the new JIRA here as well once it's created. > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman >Priority: Major > Fix For: 4.0 > > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the non-vnodes configuration. The current most recent trunk dtest job
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16321454#comment-16321454 ] Michael Kjellman commented on CASSANDRA-14134: -- Happy to remove any commits that added sleeps to attempt to work around flaky tests due to schema changes -- some of them I did with [~jjirsa] and some myself. We too already discussed that maybe these are fundamental things that ccm needs to handle so it's fixed everywhere. I don't really know the answer there ot be honest. > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the
[jira] [Updated] (CASSANDRA-14156) [DTEST] [TRUNK] TestTopology.test_movement is flaky; fails assert "values not within 16.00% of the max: (851.41, 713.26)"
[
https://issues.apache.org/jira/browse/CASSANDRA-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-14156:
-
Summary: [DTEST] [TRUNK] TestTopology.test_movement is flaky; fails assert
"values not within 16.00% of the max: (851.41, 713.26)" (was: [TRUNK] [DTEST]
TestTopology.test_movement is flaky; fails assert "values not within 16.00% of
the max: (851.41, 713.26)")
> [DTEST] [TRUNK] TestTopology.test_movement is flaky; fails assert "values not
> within 16.00% of the max: (851.41, 713.26)"
> -
>
> Key: CASSANDRA-14156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14156
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>
> DTest* TestTopology.test_movement* is flaky. All of the testing so far (and
> thus all of the current known observed failures) have been when running
> against trunk. When the test fails, it always due to the assert_almost_equal
> assert.
> {code}
> AssertionError: values not within 16.00% of the max: (851.41, 713.26) ()
> {code}
> The following CircleCI runs are 2 examples with dtests runs that failed due
> to this test failing it's assert:
> [https://circleci.com/gh/mkjellman/cassandra/487]
> [https://circleci.com/gh/mkjellman/cassandra/526]
> *p.s.* assert_almost_equal has a comment "@params error Optional margin of
> error. Default 0.16". I don't see any obvious notes for why the default is
> this magical 16% number. It looks like it was committed as part of a big bulk
> commit by Sean McCarthy (who I can't find on JIRA). If anyone has any history
> on the magic 16% allowed delta please share!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14157) [DTEST] [TRUNK] test_tracing_does_not_interfere_with_digest_calculation - cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1
[
https://issues.apache.org/jira/browse/CASSANDRA-14157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-14157:
-
Summary: [DTEST] [TRUNK]
test_tracing_does_not_interfere_with_digest_calculation -
cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1
(was: [TRUNK] [DTEST] test_tracing_does_not_interfere_with_digest_calculation -
cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1)
> [DTEST] [TRUNK] test_tracing_does_not_interfere_with_digest_calculation -
> cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1
> -
>
> Key: CASSANDRA-14157
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14157
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>
> test_tracing_does_not_interfere_with_digest_calculation -
> cql_tracing_test.TestCqlTracing failed it's assertion once today in a
> circleci run. the dtests were running against trunk.
> Although it has failed once so far, a quick read of the comments in the test
> seems to indicate that the assertion failing this way might mean that
> CASSANDRA-13964 didn't fully fix the issue.
> {code:python}
> if jmx.has_mbean(rr_count):
> # expect 0 digest mismatches
> > assert 0 == jmx.read_attribute(rr_count, 'Count')
> E AssertionError: assert 0 == 1
> E+ where 1 = 0x7f62d4156898>>('org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlocking',
> 'Count')
> E+where > =
> .read_attribute
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14158) [DTEST] [TRUNK] repair_test.py::test_dead_coordinator is flaky due to JMX connection error from nodetool
Michael Kjellman created CASSANDRA-14158:
Summary: [DTEST] [TRUNK] repair_test.py::test_dead_coordinator is
flaky due to JMX connection error from nodetool
Key: CASSANDRA-14158
URL: https://issues.apache.org/jira/browse/CASSANDRA-14158
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
repair_test.py::test_dead_coordinator is flaky due to occasionally failing when
a JMX connection error is propagated by nodetool.
the test has failed 4+ times for the same reason.
latest failure can be found in the artifacts for the following circleci run:
[https://circleci.com/gh/mkjellman/cassandra/538]
I *think* that this might be expected behavior for this test and we just need
to catch any ToolError exceptions thrown and only fail if included stack is for
any error other than "JMX connection closed."
{code}
stderr: error: [2018-01-10 07:07:55,178] JMX connection closed. You should
check server log for repair status of keyspace system_traces(Subsequent
keyspaces are not going to be repaired).
-- StackTrace --
java.io.IOException: [2018-01-10 07:07:55,178] JMX connection closed. You
should check server log for repair status of keyspace system_traces(Subsequent
keyspaces are not going to be repaired).
at
org.apache.cassandra.tools.RepairRunner.handleConnectionFailed(RepairRunner.java:104)
at
org.apache.cassandra.utils.progress.jmx.JMXNotificationProgressListener.handleNotification(JMXNotificationProgressListener.java:86)
at
javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:275)
at
javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:352)
at
javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:337)
at
javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:248)
at
javax.management.remote.rmi.RMIConnector.sendNotification(RMIConnector.java:441)
at
javax.management.remote.rmi.RMIConnector.access$1200(RMIConnector.java:121)
at
javax.management.remote.rmi.RMIConnector$RMIClientCommunicatorAdmin.gotIOException(RMIConnector.java:1531)
at
javax.management.remote.rmi.RMIConnector$RMINotifClient.fetchNotifs(RMIConnector.java:1352)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.fetchOneNotif(ClientNotifForwarder.java:655)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.fetchNotifs(ClientNotifForwarder.java:607)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.doRun(ClientNotifForwarder.java:471)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$NotifFetcher.run(ClientNotifForwarder.java:452)
at
com.sun.jmx.remote.internal.ClientNotifForwarder$LinearExecutor$1.run(ClientNotifForwarder.java:108)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14157) [TRUNK] [DTEST] test_tracing_does_not_interfere_with_digest_calculation - cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1
Michael Kjellman created CASSANDRA-14157:
Summary: [TRUNK] [DTEST]
test_tracing_does_not_interfere_with_digest_calculation -
cql_tracing_test.TestCqlTracing failed once : AssertionError: assert 0 == 1
Key: CASSANDRA-14157
URL: https://issues.apache.org/jira/browse/CASSANDRA-14157
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_tracing_does_not_interfere_with_digest_calculation -
cql_tracing_test.TestCqlTracing failed it's assertion once today in a circleci
run. the dtests were running against trunk.
Although it has failed once so far, a quick read of the comments in the test
seems to indicate that the assertion failing this way might mean that
CASSANDRA-13964 didn't fully fix the issue.
{code:python}
if jmx.has_mbean(rr_count):
# expect 0 digest mismatches
> assert 0 == jmx.read_attribute(rr_count, 'Count')
E AssertionError: assert 0 == 1
E+ where 1 = >('org.apache.cassandra.metrics:type=ReadRepair,name=RepairedBlocking',
'Count')
E+where > =
.read_attribute
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14156) [TRUNK] [DTEST] TestTopology.test_movement is flaky; fails assert "values not within 16.00% of the max: (851.41, 713.26)"
[
https://issues.apache.org/jira/browse/CASSANDRA-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319737#comment-16319737
]
Michael Kjellman commented on CASSANDRA-14156:
--
Failed again just now:
https://circleci.com/gh/mkjellman/cassandra/532
{code}
AssertionError: values not within 16.00% of the max: (870.33, 713.36) ()
{code}
> [TRUNK] [DTEST] TestTopology.test_movement is flaky; fails assert "values not
> within 16.00% of the max: (851.41, 713.26)"
> -
>
> Key: CASSANDRA-14156
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14156
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>
> DTest* TestTopology.test_movement* is flaky. All of the testing so far (and
> thus all of the current known observed failures) have been when running
> against trunk. When the test fails, it always due to the assert_almost_equal
> assert.
> {code}
> AssertionError: values not within 16.00% of the max: (851.41, 713.26) ()
> {code}
> The following CircleCI runs are 2 examples with dtests runs that failed due
> to this test failing it's assert:
> [https://circleci.com/gh/mkjellman/cassandra/487]
> [https://circleci.com/gh/mkjellman/cassandra/526]
> *p.s.* assert_almost_equal has a comment "@params error Optional margin of
> error. Default 0.16". I don't see any obvious notes for why the default is
> this magical 16% number. It looks like it was committed as part of a big bulk
> commit by Sean McCarthy (who I can't find on JIRA). If anyone has any history
> on the magic 16% allowed delta please share!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319714#comment-16319714 ] Michael Kjellman commented on CASSANDRA-14134: -- Finally just got a successful test run of the entire workflow! [https://circleci.com/workflow-run/f3c2daf6-1537-4a5a-9c68-ff4f3f27d350] Will press my luck now and see if I can get back to back green passes at the workflow level. :) > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the non-vnodes configuration. The current most recent trunk dtest job to > complete on ASF Jenkins
[jira] [Created] (CASSANDRA-14156) [TRUNK] [DTEST] TestTopology.test_movement is flaky; fails assert "values not within 16.00% of the max: (851.41, 713.26)"
Michael Kjellman created CASSANDRA-14156:
Summary: [TRUNK] [DTEST] TestTopology.test_movement is flaky;
fails assert "values not within 16.00% of the max: (851.41, 713.26)"
Key: CASSANDRA-14156
URL: https://issues.apache.org/jira/browse/CASSANDRA-14156
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
DTest* TestTopology.test_movement* is flaky. All of the testing so far (and
thus all of the current known observed failures) have been when running against
trunk. When the test fails, it always due to the assert_almost_equal assert.
{code}
AssertionError: values not within 16.00% of the max: (851.41, 713.26) ()
{code}
The following CircleCI runs are 2 examples with dtests runs that failed due to
this test failing it's assert:
[https://circleci.com/gh/mkjellman/cassandra/487]
[https://circleci.com/gh/mkjellman/cassandra/526]
*p.s.* assert_almost_equal has a comment "@params error Optional margin of
error. Default 0.16". I don't see any obvious notes for why the default is this
magical 16% number. It looks like it was committed as part of a big bulk commit
by Sean McCarthy (who I can't find on JIRA). If anyone has any history on the
magic 16% allowed delta please share!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14155) [TRUNK] Gossiper somewhat frequently hitting an NPE on node startup with dtests at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
[
https://issues.apache.org/jira/browse/CASSANDRA-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16319636#comment-16319636
]
Michael Kjellman commented on CASSANDRA-14155:
--
i've seen it on a few tests now. [~jasobrown] did a bunch of debugging this
morning and last update i heard from him was he knew *why* it was happening but
doesn't know how we get into the state in the first place.
FWIW we've seen a very similar stack in production with 2.1 -- so i think the
big question now is if this is something unique to trunk, 3.0+, or just again
exposing the fact that gossip still remains a racy hell-hole in 2018.
> [TRUNK] Gossiper somewhat frequently hitting an NPE on node startup with
> dtests at
> org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
>
>
> Key: CASSANDRA-14155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14155
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Kjellman
>Assignee: Jason Brown
>
> Gossiper is somewhat frequently hitting an NPE on node startup with dtests at
> org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2018-01-08 21:41:01,832 CassandraDaemon.java:675 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:511)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:761)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:621)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:568)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:360)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:658)
> [main/:na], ERROR [main] 2018-01-08 21:41:01,832 CassandraDaemon.java:675 -
> Exception encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:511)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:761)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:621)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:568)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:360)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:658)
> [main/:na]]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14155) [TRUNK] Gossiper somewhat frequently hitting an NPE on node startup with dtests at org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
Michael Kjellman created CASSANDRA-14155:
Summary: [TRUNK] Gossiper somewhat frequently hitting an NPE on
node startup with dtests at
org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
Key: CASSANDRA-14155
URL: https://issues.apache.org/jira/browse/CASSANDRA-14155
Project: Cassandra
Issue Type: Bug
Reporter: Michael Kjellman
Gossiper is somewhat frequently hitting an NPE on node startup with dtests at
org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
{code}
test teardown failure
Unexpected error found in node logs (see stdout for full details). Errors:
[ERROR [main] 2018-01-08 21:41:01,832 CassandraDaemon.java:675 - Exception
encountered during startup
java.lang.NullPointerException: null
at
org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
~[main/:na]
at
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:511)
~[main/:na]
at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:761)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:621)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:568)
~[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:360)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:658)
[main/:na], ERROR [main] 2018-01-08 21:41:01,832 CassandraDaemon.java:675 -
Exception encountered during startup
java.lang.NullPointerException: null
at
org.apache.cassandra.gms.Gossiper.isSafeForStartup(Gossiper.java:769)
~[main/:na]
at
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:511)
~[main/:na]
at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:761)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:621)
~[main/:na]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:568)
~[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:360)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:658)
[main/:na]]
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14151) [TRUNK] TestRepair.test_dead_sync_initiator failed due to ERROR in logs "SSTableTidier ran with no existing data file for an sstable that was not new"
Michael Kjellman created CASSANDRA-14151:
Summary: [TRUNK] TestRepair.test_dead_sync_initiator failed due to
ERROR in logs "SSTableTidier ran with no existing data file for an sstable that
was not new"
Key: CASSANDRA-14151
URL: https://issues.apache.org/jira/browse/CASSANDRA-14151
Project: Cassandra
Issue Type: Bug
Reporter: Michael Kjellman
Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log,
node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log,
stdout-novnodes.txt
TestRepair.test_dead_sync_initiator failed due to finding the following
unexpected error in the node's logs:
{code}
ERROR [NonPeriodicTasks:1] 2018-01-06 03:38:50,229 LogTransaction.java:347 -
SSTableTidier ran with no existing data file for an sstable that was not new
{code}
If this is "okay/expected" behavior we should change the log level to something
different (which will fix the test) or if it's an actual bug use this JIRA to
fix it. I've attached all of the logs from all 3 instances from the dtest run
that hit this failure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14150) [TRUNK] Many dtests failing due to java.lang.IndexOutOfBoundsException at org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(CompactionSt
[
https://issues.apache.org/jira/browse/CASSANDRA-14150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-14150:
-
Description:
lots of dtests are currently failing against trunk due to a
java.lang.IndexOutOfBoundsException checking something related to early open
{code}
ERROR [CompactionExecutor:9] 2018-01-06 00:27:06,556 CassandraDaemon.java:211 -
Exception in thread Thread[CompactionExecutor:9,1,RMI Runtime]
java.lang.IndexOutOfBoundsException: Index: 0, Size: 5
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
~[na:1.8.0_154-cassandra]
at java.util.ArrayList.get(ArrayList.java:429) ~[na:1.8.0_154-cassandra]
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(CompactionStrategyManager.java:1196)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.supportsEarlyOpen(ColumnFamilyStore.java:491)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableRewriter.construct(SSTableRewriter.java:114)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager.doCleanupOne(CompactionManager.java:1107)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager.access$400(CompactionManager.java:90)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager$6.execute(CompactionManager.java:479)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:334)
~[main/:na]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[na:1.8.0_154-cassandra]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[na:1.8.0_154-cassandra]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[na:1.8.0_154-cassandra]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
[main/:na]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_154-cassandra]
{code}
was:
lots of dtests are currently failing against trunk due to a
java.lang.IndexOutOfBoundsException checking something related to early open
ERROR [CompactionExecutor:9] 2018-01-06 00:27:06,556 CassandraDaemon.java:211 -
Exception in thread Thread[CompactionExecutor:9,1,RMI Runtime]
java.lang.IndexOutOfBoundsException: Index: 0, Size: 5
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
~[na:1.8.0_154-cassandra]
at java.util.ArrayList.get(ArrayList.java:429) ~[na:1.8.0_154-cassandra]
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(CompactionStrategyManager.java:1196)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.supportsEarlyOpen(ColumnFamilyStore.java:491)
~[main/:na]
at
org.apache.cassandra.io.sstable.SSTableRewriter.construct(SSTableRewriter.java:114)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager.doCleanupOne(CompactionManager.java:1107)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager.access$400(CompactionManager.java:90)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager$6.execute(CompactionManager.java:479)
~[main/:na]
at
org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:334)
~[main/:na]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
~[na:1.8.0_154-cassandra]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[na:1.8.0_154-cassandra]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[na:1.8.0_154-cassandra]
at
org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
[main/:na]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_154-cassandra]
> [TRUNK] Many dtests failing due to java.lang.IndexOutOfBoundsException at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(CompactionStrategyManager.java:1196
>
>
> Key: CASSANDRA-14150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14150
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Kjellman
>
> lots of dtests are currently failing against trunk due to a
> java.lang.IndexOutOfBoundsException checking something related to early open
> {code}
> ERROR [CompactionExecutor:9] 2018-01-06 00:27:06,556 CassandraDaemon.java:211
> - Exception in thread Thread[CompactionExecutor:9,1,RMI Runtime]
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 5
> at
[jira] [Commented] (CASSANDRA-14150) [TRUNK] Many dtests failing due to java.lang.IndexOutOfBoundsException at org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(Compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-14150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314244#comment-16314244 ] Michael Kjellman commented on CASSANDRA-14150: -- example test_disk_balance_after_boundary_change_stcs > [TRUNK] Many dtests failing due to java.lang.IndexOutOfBoundsException at > org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(CompactionStrategyManager.java:1196 > > > Key: CASSANDRA-14150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14150 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Kjellman > > lots of dtests are currently failing against trunk due to a > java.lang.IndexOutOfBoundsException checking something related to early open > ERROR [CompactionExecutor:9] 2018-01-06 00:27:06,556 CassandraDaemon.java:211 > - Exception in thread Thread[CompactionExecutor:9,1,RMI Runtime] > java.lang.IndexOutOfBoundsException: Index: 0, Size: 5 > at java.util.ArrayList.rangeCheck(ArrayList.java:653) > ~[na:1.8.0_154-cassandra] > at java.util.ArrayList.get(ArrayList.java:429) ~[na:1.8.0_154-cassandra] > at > org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(CompactionStrategyManager.java:1196) > ~[main/:na] > at > org.apache.cassandra.db.ColumnFamilyStore.supportsEarlyOpen(ColumnFamilyStore.java:491) > ~[main/:na] > at > org.apache.cassandra.io.sstable.SSTableRewriter.construct(SSTableRewriter.java:114) > ~[main/:na] > at > org.apache.cassandra.db.compaction.CompactionManager.doCleanupOne(CompactionManager.java:1107) > ~[main/:na] > at > org.apache.cassandra.db.compaction.CompactionManager.access$400(CompactionManager.java:90) > ~[main/:na] > at > org.apache.cassandra.db.compaction.CompactionManager$6.execute(CompactionManager.java:479) > ~[main/:na] > at > org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:334) > ~[main/:na] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > ~[na:1.8.0_154-cassandra] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > ~[na:1.8.0_154-cassandra] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [na:1.8.0_154-cassandra] > at > org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81) > [main/:na] > at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_154-cassandra] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14150) [TRUNK] Many dtests failing due to java.lang.IndexOutOfBoundsException at org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(CompactionSt
Michael Kjellman created CASSANDRA-14150: Summary: [TRUNK] Many dtests failing due to java.lang.IndexOutOfBoundsException at org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(CompactionStrategyManager.java:1196 Key: CASSANDRA-14150 URL: https://issues.apache.org/jira/browse/CASSANDRA-14150 Project: Cassandra Issue Type: Bug Reporter: Michael Kjellman lots of dtests are currently failing against trunk due to a java.lang.IndexOutOfBoundsException checking something related to early open ERROR [CompactionExecutor:9] 2018-01-06 00:27:06,556 CassandraDaemon.java:211 - Exception in thread Thread[CompactionExecutor:9,1,RMI Runtime] java.lang.IndexOutOfBoundsException: Index: 0, Size: 5 at java.util.ArrayList.rangeCheck(ArrayList.java:653) ~[na:1.8.0_154-cassandra] at java.util.ArrayList.get(ArrayList.java:429) ~[na:1.8.0_154-cassandra] at org.apache.cassandra.db.compaction.CompactionStrategyManager.supportsEarlyOpen(CompactionStrategyManager.java:1196) ~[main/:na] at org.apache.cassandra.db.ColumnFamilyStore.supportsEarlyOpen(ColumnFamilyStore.java:491) ~[main/:na] at org.apache.cassandra.io.sstable.SSTableRewriter.construct(SSTableRewriter.java:114) ~[main/:na] at org.apache.cassandra.db.compaction.CompactionManager.doCleanupOne(CompactionManager.java:1107) ~[main/:na] at org.apache.cassandra.db.compaction.CompactionManager.access$400(CompactionManager.java:90) ~[main/:na] at org.apache.cassandra.db.compaction.CompactionManager$6.execute(CompactionManager.java:479) ~[main/:na] at org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:334) ~[main/:na] at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_154-cassandra] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_154-cassandra] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_154-cassandra] at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81) [main/:na] at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_154-cassandra] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314023#comment-16314023 ] Michael Kjellman commented on CASSANDRA-14134: -- >Can you elaborate on why you had to switch to opening files in binary mode? >Was it a bug originally? Looks like those files are indeed binary. I am just >wondering if it manifested differently in python 3. This is a python3 change. This gives us the same behavior we were relying on in python2. >I see cases in asserts where constant integers were changed from say 7L to >just 7. Is that intentional? What is that about? (materialized view test, >paging test) This was just something changed by the 2to3 tool. > paxos_tests, you removed the utf-8 encoding statement at the top? Was that > doing anything? This happens in several files. this is unnecessary now in python3. everything is utf-8 by default. > read_repair_test is now inlining a method manually? test_read_repair? Do we > have to have that duplication? I know this Beobal's commit so I'll probably > have to come back to it. [~beobal], thoughts? the test isn't flaky anymore though... > base_replace_address_test failed to properly handshake peer, is this just > another case of this error is generated and it's fine? Seems like you add > this to tests that use JMX. Maybe using JMX should automatically cause this > to be added to ignored log lines? did you run this locally to see this failure? i've seen this fail a few times in circle but not frequently... > run_dtest.py still does the fork to a separate process. Does that accomplish > anything? Can we remove it? i think we can remove it... and maybe even just call pytest directly? > snapshot_test assert_directory_not_empty, I looked at this twice, it's just a > little too confusing and needs a comment as to what the parameters are and > how it works. i didn't code this.. just moved it... > You regenerated the thrift bindings to get a python 3 supported version? You > removed pycassa but it also looks like we were hardly using it? Just want to > make sure I understand what happened. yes, pycassa isn't python 3 compatible and we needed new thrift bindings to get python 3 support for the remianing thrift tests we still have. [~jjirsa] did this work. > tools/assertions.py assert_lists_equal_ignoring_order, this seems to sort > results coming from the DB. Shouldn't the DB already be providing a > consistent sort order for results? I thought that was well defined. I am > wondering if we are papering over result ordering issues in the DB. good question... i just maintained existing behavior in the asserts > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine >
[jira] [Created] (CASSANDRA-14148) test_no_base_column_in_view_pk_complex_timestamp_with_flush - materialized_views_test.TestMaterializedViews frequently fails in CI
Michael Kjellman created CASSANDRA-14148:
Summary:
test_no_base_column_in_view_pk_complex_timestamp_with_flush -
materialized_views_test.TestMaterializedViews frequently fails in CI
Key: CASSANDRA-14148
URL: https://issues.apache.org/jira/browse/CASSANDRA-14148
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_no_base_column_in_view_pk_complex_timestamp_with_flush -
materialized_views_test.TestMaterializedViews frequently fails in CI
self =
@since('3.0')
def test_no_base_column_in_view_pk_complex_timestamp_with_flush(self):
> self._test_no_base_column_in_view_pk_complex_timestamp(flush=True)
materialized_views_test.py:970:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
materialized_views_test.py:1066: in
_test_no_base_column_in_view_pk_complex_timestamp
assert_one(session, "SELECT * FROM t", [1, 1, None, None, None, 1])
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
session =
query = 'SELECT * FROM t', expected = [1, 1, None, None, None, 1], cl = None
def assert_one(session, query, expected, cl=None):
"""
Assert query returns one row.
@param session Session to use
@param query Query to run
@param expected Expected results from query
@param cl Optional Consistency Level setting. Default ONE
Examples:
assert_one(session, "LIST USERS", ['cassandra', True])
assert_one(session, query, [0, 0])
"""
simple_query = SimpleStatement(query, consistency_level=cl)
res = session.execute(simple_query)
list_res = _rows_to_list(res)
> assert list_res == [expected], "Expected {} from {}, but got
> {}".format([expected], query, list_res)
E AssertionError: Expected [[1, 1, None, None, None, 1]] from SELECT *
FROM t, but got []
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312291#comment-16312291 ] Michael Kjellman commented on CASSANDRA-14134: -- Even more exciting news! We have a SECOND fully green/successful run!!! https://circleci.com/gh/mkjellman/cassandra/383 Your build ran 796 tests in unknown with 0 failures Slowest test: consistency_test.TestConsistency test_short_read (took 773.07 seconds). > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the non-vnodes configuration. The current most recent trunk dtest job to >
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312114#comment-16312114 ] Michael Kjellman commented on CASSANDRA-14134: -- Exciting news! Just got our first fully green/successful run! https://circleci.com/gh/mkjellman/cassandra/365 Your build ran 796 tests in unknown with 0 failures Slowest test: consistency_test.TestConsistency test_short_read (took 593.89 seconds). > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the non-vnodes configuration. The current most recent trunk dtest job to > complete on
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310724#comment-16310724 ] Michael Kjellman commented on CASSANDRA-14134: -- I committed quite a lot of extra fixes today to the branch. Some was to deal with broken tests that weren't being executed due to the regex not matching some of the test classes as [~spo...@gmail.com] noticed this morning. I think that's fully resolved now but I'd appreciate it if you eyeball the branch as it exists now! I also merged in a few tests fixed today by [~beobal] and [~bdeggleston]. With all of that work, we are *very* close to passing without any test failures but there are a few flaky tests that keep popping up and preventing victory... +The latest two runs are below:+ * With vnodes ** https://circleci.com/gh/mkjellman/cassandra/339 ** ran 771 tests with 3 failures (run time 18:51) * Without vnodes ** https://circleci.com/gh/mkjellman/cassandra/338 ** ran 796 tests with 3 failures (run time 11:51) > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with >
[jira] [Commented] (CASSANDRA-14041) test_dead_sync_initiator - repair_tests.repair_test.TestRepair fails: Unexpected error in log, see stdout
[
https://issues.apache.org/jira/browse/CASSANDRA-14041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310681#comment-16310681
]
Michael Kjellman commented on CASSANDRA-14041:
--
this is failing very reliably... so we should prioritize fixing this one...
some more contents of stdout with the actual failure..
{code}
def handle_external_tool_process(process, cmd_args):
out, err = process.communicate()
rc = process.returncode
if rc != 0:
> raise ToolError(cmd_args, rc, out, err)
E ccmlib.node.ToolError: Subprocess ['stress', 'write', 'n=1k',
'no-warmup', 'cl=ONE', '-schema', 'replication(factor=3)', '-rate',
'threads=10'] exited with non-zero status; exit status: 1;
E stdout: Stress Settings
E Command:
E Type: write
E Count: 1,000
E No Warmup: true
E Consistency Level: ONE
E Target Uncertainty: not applicable
E Key Size (bytes): 10
E Counter Increment Distibution: add=fixed(1)
E Rate:
E Auto: false
E Thread Count: 10
E OpsPer Sec: 0
E Population:
E Sequence: 1..1000
E Order: ARBITRARY
E Wrap: true
E Insert:
E Revisits: Uniform: min=1,max=100
E Visits: Fixed: key=1
E Row Population Ratio: Ratio: divisor=1.00;delegate=Fixed:
key=1
E Batch Type: not batching
E Columns:
E Max Columns Per Key: 5
E Column Names: [C0, C1, C2, C3, C4]
E Comparator: AsciiType
E Timestamp: null
E Variable Column Count: false
E Slice: false
E Size Distribution: Fixed: key=34
E Count Distribution: Fixed: key=5
E Errors:
E Ignore: false
E Tries: 10
E Log:
E No Summary: false
E No Settings: false
E File: null
E Interval Millis: 1000
E Level: NORMAL
E Mode:
E API: JAVA_DRIVER_NATIVE
E Connection Style: CQL_PREPARED
E CQL Version: CQL3
E Protocol Version: V4
E Username: null
E Password: null
E Auth Provide Class: null
E Max Pending Per Connection: 128
E Connections Per Host: 8
E Compression: NONE
E Node:
E Nodes: [127.0.0.1]
E Is White List: false
E Datacenter: null
E Schema:
E Keyspace: keyspace1
E Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
E Replication Strategy Options: {replication_factor=3}
E Table Compression: null
E Table Compaction Strategy: null
E Table Compaction Strategy Options: {}
E Transport:
E truststore=null; truststore-password=null; keystore=null;
keystore-password=null; ssl-protocol=TLS; ssl-alg=SunX509;
ssl-ciphers=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA;
E Port:
E Native Port: 9042
E JMX Port: 7100
E Send To Daemon:
E *not set*
E Graph:
E File: null
E Revision: unknown
E Title: null
E Operation: WRITE
E TokenRange:
E Wrap: false
E Split Factor: 1
E
E Connected to cluster: test, max pending requests per connection
128, max connections per host 8
E Datacenter: datacenter1; Host: /127.0.0.1; Rack: rack1
E Datacenter: datacenter1; Host: /127.0.0.2; Rack: rack1
E Datacenter: datacenter1; Host: /127.0.0.3; Rack: rack1
E ;
E stderr: WARN 03:35:11,529 Error creating connection to
/127.0.0.3:9042
E com.datastax.driver.core.exceptions.TransportException:
[/127.0.0.3:9042] Cannot connect
E at
com.datastax.driver.core.Connection$1.operationComplete(Connection.java:165)
[cassandra-driver-core-3.3.2-0461ed35-SNAPSHOT-shaded.jar:na]
E at
com.datastax.driver.core.Connection$1.operationComplete(Connection.java:148)
[cassandra-driver-core-3.3.2-0461ed35-SNAPSHOT-shaded.jar:na]
E at
com.datastax.shaded.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:507)
[cassandra-driver-core-3.3.2-0461ed35-SNAPSHOT-shaded.jar:na]
E at
com.datastax.shaded.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:500)
[cassandra-driver-core-3.3.2-0461ed35-SNAPSHOT-shaded.jar:na]
E at
com.datastax.shaded.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:479)
[cassandra-driver-core-3.3.2-0461ed35-SNAPSHOT-shaded.jar:na]
E
[jira] [Created] (CASSANDRA-14146) [DTEST] cdc_test::TestCDC::test_insertion_and_commitlog_behavior_after_reaching_cdc_total_space assertion always fails (Extra items in the left set)
Michael Kjellman created CASSANDRA-14146:
Summary: [DTEST]
cdc_test::TestCDC::test_insertion_and_commitlog_behavior_after_reaching_cdc_total_space
assertion always fails (Extra items in the left set)
Key: CASSANDRA-14146
URL: https://issues.apache.org/jira/browse/CASSANDRA-14146
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
Dtest
cdc_test::TestCDC::test_insertion_and_commitlog_behavior_after_reaching_cdc_total_space
always fails on an assertion.
the assert is the final step of the test and it checks that
pre_non_cdc_write_cdc_raw_segments == _get_cdc_raw_files(node.get_path())
This fails 100% of the time locally, 100% of the time on circleci executed
under pytest, and 100% of the time for the past 40 test runs on ASF Jenkins
runs against trunk.
This is the only test failure (excluding flaky one-off failures) remaining on
the pytest dtest branch. I'm going to annotate the test with a skip marker
(including a reason reference to this JIRA)... when it's fixed we should also
remove the skip annotation from the test.
{code}
> assert pre_non_cdc_write_cdc_raw_segments ==
> _get_cdc_raw_files(node.get_path())
E AssertionError: assert {'/tmp/dtest-...169.log', ...} ==
{'/tmp/dtest-v...169.log', ...}
E Extra items in the left set:
E '/tmp/dtest-vrn4k8ov/test/node1/cdc_raw/CommitLog-7-1515030005097.log'
E '/tmp/dtest-vrn4k8ov/test/node1/cdc_raw/CommitLog-7-1515030005098.log'
E Extra items in the right set:
E '/tmp/dtest-vrn4k8ov/test/node1/cdc_raw/CommitLog-7-1515030005099.log'
E '/tmp/dtest-vrn4k8ov/test/node1/cdc_raw/CommitLog-7-1515030005100.log'
E Use -v to get the full diff
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310129#comment-16310129 ] Michael Kjellman commented on CASSANDRA-14134: -- [~bdeggleston] thanks. committed the changes for the two tests you fixed above. > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the non-vnodes configuration. The current most recent trunk dtest job to > complete on ASF Jenkins (with vnodes) was > [https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-dtest/387/]. > That test run had 36 test failures. > There are
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310125#comment-16310125 ] Michael Kjellman commented on CASSANDRA-14134: -- i strongly disagree with this [~bdeggleston] you shouldn't need to look thru the source or read random documentation to know how to run the dtests. these are required parameters and we should have good --help around them and validation when they are provided as arguments to see if they exist etc. > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the non-vnodes configuration. The
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310108#comment-16310108 ] Michael Kjellman commented on CASSANDRA-14134: -- [~aweisberg] just pushed up a fix for the missing pytest import on metadata_test.py > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the non-vnodes configuration. The current most recent trunk dtest job to > complete on ASF Jenkins (with vnodes) was > [https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-dtest/387/]. > That test run had 36 test failures. > There
[jira] [Commented] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310099#comment-16310099 ] Michael Kjellman commented on CASSANDRA-14134: -- [~spo...@gmail.com] good catch! i just pushed a commit to rename the additional snowflake test classes that i missed. i assume it's going to take me a few additional commits here to fix runtime exceptions on those tests from python 3 fallout on these test classes as they weren't being run in my testing thus far > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the non-vnodes
[jira] [Updated] (CASSANDRA-14134) Migrate dtests to use pytest and python3
[ https://issues.apache.org/jira/browse/CASSANDRA-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kjellman updated CASSANDRA-14134: - Status: Patch Available (was: Open) > Migrate dtests to use pytest and python3 > > > Key: CASSANDRA-14134 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 > Project: Cassandra > Issue Type: Improvement > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > h4. Get the C* dtests running on the pytest framework. > C* DTests currently run using the python test framework nosetest. This > framework has been largely abandoned with no releases since 2015 and a > general strong consensus in the python community that pytest is the future. > h4. Why should we do this. > Currently (and historically) dtests have always been difficult to run, flaky > and unpredictable in CI environments, and almost impossible to debug. > On November 28th, 2017, I proposed on the dev@ list that we move the dtests > from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, > and kurt greaves with really only "+1" like replies to the proposal. > Since then I've been working pretty much non stop to complete the large > refactor of dtests to pytests. As part of this effort (and due to the > migration tools that exist require it) I also ported the code to python3 > (from the current python 2.7 based code-base). > h4. High-level summary of key changes, improvements, and new features. > * Migrate dtests from executing using the nosetest framework to pytest > * Port the entire code base from Python 2.7 to Python 3.6 > * Update run_dtests.py to work with pytest > * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable > list of all available collected tests > * Update README.md for executing the dtests with pytest > * Add new debugging tips section to README.md to help with some basics of > debugging python3 and pytest > * Migrate all existing Enviornment Variable usage as a means to control dtest > operation modes to argparse command line options with documented help on each > toggles intended usage > * Migration of old unitTest and nose based test structure to modern pytest > fixture approach > * Automatic detection of physical system resources to automatically determine > if @pytest.mark.resource_intensive annotated tests should be collected and > run on the system where they are being executed > * new pytest fixture replacements for @since and @pytest.mark.upgrade_test > annotations > * Migration to python logging framework > * Upgrade thrift bindings to latest version with full python3 compatibility > * Remove deprecated cql and pycassa dependencies and migrate any remaining > tests to fully remove those dependencies > * Fixed dozens of tests that would hang the pytest framework forever when run > in CI enviornments > * Ran code nearly 300 times in CircleCI during the migration and to find, > identify, and fix any tests capable of hanging CI > * Upgrade Tests do not yet run in CI and still need additional migration work > (although all upgrade test classes compile successfully) > I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] > migration tool. As this required python 3 language support I found myself > down the 2to3 python migration path. While painful to do this, the benefits > of python3 over python2.7 are numerous and moving to python3 for the > additional debugging tools now available to use when fixing dtests makes the > effort worth it for that reason alone! > After the automated tools did their thing I began what was a much longer and > tedious manual process than I ever could have expected due to the custom many > ways we did things in dtests (frequently to work around nosetest limitations > of missing features that thankfully are now all included with the pytest > framework). I've done nearly 300 test runs of my migration branch with > circleci. > The latest CircleCI runs can be found at: > (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] > (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] > With vnodes, there are currently only 6 remaining dtest test failures. > Without vnodes, there are 12 remaining dtest failures. > It turns out that after the dtests were moved to ASF Jenkins from cassci, the > jobs were misconfigured and we actually haven't been running the dtests in > the non-vnodes configuration. The current most recent trunk dtest job to > complete on ASF Jenkins (with vnodes) was > [https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-dtest/387/]. > That test run had 36 test failures. > There are great performance improvements so far with pytests. With a > parallism factor of
[jira] [Created] (CASSANDRA-14134) Migrate dtests to use pytest and python3
Michael Kjellman created CASSANDRA-14134: Summary: Migrate dtests to use pytest and python3 Key: CASSANDRA-14134 URL: https://issues.apache.org/jira/browse/CASSANDRA-14134 Project: Cassandra Issue Type: Improvement Components: Testing Reporter: Michael Kjellman Assignee: Michael Kjellman h4. Get the C* dtests running on the pytest framework. C* DTests currently run using the python test framework nosetest. This framework has been largely abandoned with no releases since 2015 and a general strong consensus in the python community that pytest is the future. h4. Why should we do this. Currently (and historically) dtests have always been difficult to run, flaky and unpredictable in CI environments, and almost impossible to debug. On November 28th, 2017, I proposed on the dev@ list that we move the dtests from nosetests to pytests. I got replies from Jon Haddad, Philip Thompson, and kurt greaves with really only "+1" like replies to the proposal. Since then I've been working pretty much non stop to complete the large refactor of dtests to pytests. As part of this effort (and due to the migration tools that exist require it) I also ported the code to python3 (from the current python 2.7 based code-base). h4. High-level summary of key changes, improvements, and new features. * Migrate dtests from executing using the nosetest framework to pytest * Port the entire code base from Python 2.7 to Python 3.6 * Update run_dtests.py to work with pytest * Add --dtest-print-tests-only option to run_dtests.py to get easily parsable list of all available collected tests * Update README.md for executing the dtests with pytest * Add new debugging tips section to README.md to help with some basics of debugging python3 and pytest * Migrate all existing Enviornment Variable usage as a means to control dtest operation modes to argparse command line options with documented help on each toggles intended usage * Migration of old unitTest and nose based test structure to modern pytest fixture approach * Automatic detection of physical system resources to automatically determine if @pytest.mark.resource_intensive annotated tests should be collected and run on the system where they are being executed * new pytest fixture replacements for @since and @pytest.mark.upgrade_test annotations * Migration to python logging framework * Upgrade thrift bindings to latest version with full python3 compatibility * Remove deprecated cql and pycassa dependencies and migrate any remaining tests to fully remove those dependencies * Fixed dozens of tests that would hang the pytest framework forever when run in CI enviornments * Ran code nearly 300 times in CircleCI during the migration and to find, identify, and fix any tests capable of hanging CI * Upgrade Tests do not yet run in CI and still need additional migration work (although all upgrade test classes compile successfully) I started with the *nose2pytest* [https://github.com/pytest-dev/nose2pytest] migration tool. As this required python 3 language support I found myself down the 2to3 python migration path. While painful to do this, the benefits of python3 over python2.7 are numerous and moving to python3 for the additional debugging tools now available to use when fixing dtests makes the effort worth it for that reason alone! After the automated tools did their thing I began what was a much longer and tedious manual process than I ever could have expected due to the custom many ways we did things in dtests (frequently to work around nosetest limitations of missing features that thankfully are now all included with the pytest framework). I've done nearly 300 test runs of my migration branch with circleci. The latest CircleCI runs can be found at: (dtests without vnodes) [https://circleci.com/gh/mkjellman/cassandra/277] (dtests with vnodes) [https://circleci.com/gh/mkjellman/cassandra/278] With vnodes, there are currently only 6 remaining dtest test failures. Without vnodes, there are 12 remaining dtest failures. It turns out that after the dtests were moved to ASF Jenkins from cassci, the jobs were misconfigured and we actually haven't been running the dtests in the non-vnodes configuration. The current most recent trunk dtest job to complete on ASF Jenkins (with vnodes) was [https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-dtest/387/]. That test run had 36 test failures. There are great performance improvements so far with pytests. With a parallism factor of 90x in CircleCI the dtests-no-vnodes job completed all tests in 16 minutes and 24 seconds and the dtests-with-vnodes job completed all tests in 14 minutes and 22 seconds.. (Compare that to the 8+ hours ASF Jenkins currently takes!). A dtest on pytest compatible CircleCI configuration is available at
[jira] [Comment Edited] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[
https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281326#comment-16281326
]
Michael Kjellman edited comment on CASSANDRA-14054 at 12/7/17 4:44 AM:
---
[~alourie] hey, so sorry for the delayed reply.. i've been up to my eyeballs in
the dtest pytest work along with all the other stuff and totally let this slip.
I don't have a super great answer for you yet because I'm in the process of
getting that story together... but maybe we can make this work :)
If you take a look at my C* fork, there is a CircleCI config:
https://github.com/mkjellman/cassandra/blob/trunk_circle/.circleci/config.yml
Create a free CircleCI account (if you don't have one yet) and register your C*
fork on GitHub with CircleCI. Then, grab the above config and put it in a
branch of trunk in your personal fork (you'll need to create a .circleci folder
and put it in there.
Starting at L47 of the config you'll need to switch things to use the free user
config (i'm running under the assumption you don't have a paid CircleCI account
here).
{code}
# Set env_settings, env_vars, and workflows/build_and_run_tests based on
environment
env_settings: _settings
# <<: *default_env_settings
<<: *high_capacity_env_settings
env_vars: _vars
# <<: *default_env_vars
<<: *high_capacity_env_vars
workflows:
version: 2
# build_and_run_tests: *default_jobs
build_and_run_tests: *with_dtest_jobs
{code}
comment out the instances of high_capacity_* and comment back in the default_*
ones... and you might want to switch the workflows to only run the
"default_jobs" which for right now will just build C* and run the unit tests.
This test fails about 50% of the time on CircleCI. Potentially it's exacerbated
by running on Ubuntu? Another thing maybe worth trying is running the test via
ant on ubuntu... The docker image I put together for CircleCI is available on
DockerHub (config checked in to
https://github.com/mkjellman/cassandra-test-docker) or you can grab it as
kjellman/cassandra-test:0.1.3.
Another thing that we do is split up the unit tests across the total number of
Circle containers available... based on historical runs it actually will try to
distribute the tests that run in each container by time so you don't have a few
containers with all the slow tests dragging the entire thing down. This means
we use invoke the tests in each container via "ant testclasslist
-Dtest.classlistfile=/path/to/unit/tests/to/run"... potentially maybe another
test somewhere else doesn't clean up after itself and that causes
testRegularColumnTimestampUpdates to fail? To be clear -- the splits across
containers are on a per test method level -- not test class -- so you might
have various methods of ViewTest run across different containers at the same
time -- the results are all merged together by circle at the end to give one
consolidated report for all the unit tests. none of the other unit tests on
trunk have been flaky or failing when run via circle other than this test so
I'm not sure I totally believe it's related to order it's run in or another
test not cleaning up after itself -- also there are a lot of other asserts that
are passing before the 2nd to last assert is hit (which is the one that's
always failing -- and always failing with the same value of 1 instead of 2)...
hope all this helps get the ball rolling again... any hunches by just looking
at the code? i don't really know the MV code very well... any chance there is a
race between when the mv is completed building and available and when the
assert is hit? maybe we need some kind of force blocking flush before we assert
on those conditions? that's how we handle this in a lot of the other compaction
related tests that check sstables on disk and row count...
was (Author: mkjellman):
[~alourie] hey, so sorry for the delayed reply.. i've been up to my eyeballs in
the dtest pytest work along with all the other stuff and totally let this slip.
I don't have a super great answer for you yet because I'm in the process of
getting that story together... but maybe we can make this work :)
If you take a look at my C* fork, there is a CircleCI config:
https://github.com/mkjellman/cassandra/blob/trunk_circle/.circleci/config.yml
Create a free CircleCI account (if you don't have one yet) and register your C*
fork on GitHub with CircleCI. Then, grab the above config and put it in a
branch of trunk in your personal fork (you'll need to create a .circleci folder
and put it in there.
Starting at L47 of the config you'll need to switch things to use the free user
config (i'm running under the assumption you don't have a paid CircleCI account
here).
{code}
# Set env_settings, env_vars, and workflows/build_and_run_tests based on
environment
env_settings: _settings
# <<: *default_env_settings
<<:
[jira] [Commented] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[
https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281326#comment-16281326
]
Michael Kjellman commented on CASSANDRA-14054:
--
[~alourie] hey, so sorry for the delayed reply.. i've been up to my eyeballs in
the dtest pytest work along with all the other stuff and totally let this slip.
I don't have a super great answer for you yet because I'm in the process of
getting that story together... but maybe we can make this work :)
If you take a look at my C* fork, there is a CircleCI config:
https://github.com/mkjellman/cassandra/blob/trunk_circle/.circleci/config.yml
Create a free CircleCI account (if you don't have one yet) and register your C*
fork on GitHub with CircleCI. Then, grab the above config and put it in a
branch of trunk in your personal fork (you'll need to create a .circleci folder
and put it in there.
Starting at L47 of the config you'll need to switch things to use the free user
config (i'm running under the assumption you don't have a paid CircleCI account
here).
{code}
# Set env_settings, env_vars, and workflows/build_and_run_tests based on
environment
env_settings: _settings
# <<: *default_env_settings
<<: *high_capacity_env_settings
env_vars: _vars
# <<: *default_env_vars
<<: *high_capacity_env_vars
workflows:
version: 2
# build_and_run_tests: *default_jobs
build_and_run_tests: *with_dtest_jobs
comment out the instances of high_capacity_* and comment back in the default_*
ones... and you might want to switch the workflows to only run the
"default_jobs" which for right now will just build C* and run the unit tests.
This test fails about 50% of the time on CircleCI. Potentially it's exacerbated
by running on Ubuntu? Another thing maybe worth trying is running the test via
ant on ubuntu... The docker image I put together for CircleCI is available on
DockerHub (config checked in to
https://github.com/mkjellman/cassandra-test-docker) or you can grab it as
kjellman/cassandra-test:0.1.3.
Another thing that we do is split up the unit tests across the total number of
Circle containers available... based on historical runs it actually will try to
distribute the tests that run in each container by time so you don't have a few
containers with all the slow tests dragging the entire thing down. This means
we use invoke the tests in each container via "ant testclasslist
-Dtest.classlistfile=/path/to/unit/tests/to/run"... potentially maybe another
test somewhere else doesn't clean up after itself and that causes
testRegularColumnTimestampUpdates to fail? To be clear -- the splits across
containers are on a per test method level -- not test class -- so you might
have various methods of ViewTest run across different containers at the same
time -- the results are all merged together by circle at the end to give one
consolidated report for all the unit tests. none of the other unit tests on
trunk have been flaky or failing when run via circle other than this test so
I'm not sure I totally believe it's related to order it's run in or another
test not cleaning up after itself -- also there are a lot of other asserts that
are passing before the 2nd to last assert is hit (which is the one that's
always failing -- and always failing with the same value of 1 instead of 2)...
hope all this helps get the ball rolling again... any hunches by just looking
at the code? i don't really know the MV code very well... any chance there is a
race between when the mv is completed building and available and when the
assert is hit? maybe we need some kind of force blocking flush before we assert
on those conditions? that's how we handle this in a lot of the other compaction
related tests that check sstables on disk and row count...
> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is
> flaky: expected <2> but got <1>
> -
>
> Key: CASSANDRA-14054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14054
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Alex Lourie
>
> testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is
> flaky: expected <2> but got <1>
> Fails about 25% of the time. It is currently our only flaky unit test on
> trunk so it would be great to get this one fixed up so we can be confident in
> unit test failures going forward.
> junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of
> type int), expected <2> but got <1>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973)
> at
> org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380)
--
This
[jira] [Commented] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
[ https://issues.apache.org/jira/browse/CASSANDRA-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16277834#comment-16277834 ] Michael Kjellman commented on CASSANDRA-14054: -- it's failing roughly 50% of the time when executed with circleci.. i've also seen it fail on jenkins and locally on a mac. > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > - > > Key: CASSANDRA-14054 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Alex Lourie > > testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is > flaky: expected <2> but got <1> > Fails about 25% of the time. It is currently our only flaky unit test on > trunk so it would be great to get this one fixed up so we can be confident in > unit test failures going forward. > junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of > type int), expected <2> but got <1> > at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) > at > org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14075) Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with "Please remove properties [optional, enabled] from your cassandra.yaml"
[
https://issues.apache.org/jira/browse/CASSANDRA-14075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-14075:
-
Status: Ready to Commit (was: Patch Available)
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with
> "Please remove properties [optional, enabled] from your cassandra.yaml"
> --
>
> Key: CASSANDRA-14075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14075
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Kjellman
>Assignee: Jason Brown
>
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption dtests are failing on
> 3.11 with an exception on startup due to invalid yaml properties.
> Unexpected error in node1 log, error:
> ERROR [main] 2017-11-18 21:01:54,781 CassandraDaemon.java:706 - Exception
> encountered during startup: Invalid yaml. Please remove properties [optional,
> enabled] from your cassandra.yaml
> Although ccm was updated in
> https://github.com/pcmanus/ccm/commit/eaaa425b70edb84786924516aee3920d685c0e53
> to include a version check for >= 4.0, enabled and optional are emitted
> unconditionally in the actual dtest itself -- they should also be conditional
> on >= 4.0
> {code:java}
> node.set_configuration_options(values={
> 'server_encryption_options': {
> 'enabled': encryption_enabled,
> 'optional': encryption_optional,
> 'internode_encryption': internode_encryption,
> 'keystore': kspath,
> 'keystore_password': 'cassandra',
> 'truststore': tspath,
> 'truststore_password': 'cassandra',
> 'require_endpoint_verification': endpoint_verification,
> 'require_client_auth': client_auth,
> }
> })
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14075) Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with "Please remove properties [optional, enabled] from your cassandra.yaml"
[
https://issues.apache.org/jira/browse/CASSANDRA-14075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-14075:
-
Status: Patch Available (was: Open)
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with
> "Please remove properties [optional, enabled] from your cassandra.yaml"
> --
>
> Key: CASSANDRA-14075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14075
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Kjellman
>Assignee: Jason Brown
>
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption dtests are failing on
> 3.11 with an exception on startup due to invalid yaml properties.
> Unexpected error in node1 log, error:
> ERROR [main] 2017-11-18 21:01:54,781 CassandraDaemon.java:706 - Exception
> encountered during startup: Invalid yaml. Please remove properties [optional,
> enabled] from your cassandra.yaml
> Although ccm was updated in
> https://github.com/pcmanus/ccm/commit/eaaa425b70edb84786924516aee3920d685c0e53
> to include a version check for >= 4.0, enabled and optional are emitted
> unconditionally in the actual dtest itself -- they should also be conditional
> on >= 4.0
> {code:java}
> node.set_configuration_options(values={
> 'server_encryption_options': {
> 'enabled': encryption_enabled,
> 'optional': encryption_optional,
> 'internode_encryption': internode_encryption,
> 'keystore': kspath,
> 'keystore_password': 'cassandra',
> 'truststore': tspath,
> 'truststore_password': 'cassandra',
> 'require_endpoint_verification': endpoint_verification,
> 'require_client_auth': client_auth,
> }
> })
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14075) Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with "Please remove properties [optional, enabled] from your cassandra.yaml"
[
https://issues.apache.org/jira/browse/CASSANDRA-14075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-14075:
-
Reviewer: Michael Kjellman
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with
> "Please remove properties [optional, enabled] from your cassandra.yaml"
> --
>
> Key: CASSANDRA-14075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14075
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Kjellman
>Assignee: Jason Brown
>
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption dtests are failing on
> 3.11 with an exception on startup due to invalid yaml properties.
> Unexpected error in node1 log, error:
> ERROR [main] 2017-11-18 21:01:54,781 CassandraDaemon.java:706 - Exception
> encountered during startup: Invalid yaml. Please remove properties [optional,
> enabled] from your cassandra.yaml
> Although ccm was updated in
> https://github.com/pcmanus/ccm/commit/eaaa425b70edb84786924516aee3920d685c0e53
> to include a version check for >= 4.0, enabled and optional are emitted
> unconditionally in the actual dtest itself -- they should also be conditional
> on >= 4.0
> {code:java}
> node.set_configuration_options(values={
> 'server_encryption_options': {
> 'enabled': encryption_enabled,
> 'optional': encryption_optional,
> 'internode_encryption': internode_encryption,
> 'keystore': kspath,
> 'keystore_password': 'cassandra',
> 'truststore': tspath,
> 'truststore_password': 'cassandra',
> 'require_endpoint_verification': endpoint_verification,
> 'require_client_auth': client_auth,
> }
> })
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14075) Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with "Please remove properties [optional, enabled] from your cassandra.yaml"
[
https://issues.apache.org/jira/browse/CASSANDRA-14075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16273615#comment-16273615
]
Michael Kjellman commented on CASSANDRA-14075:
--
looks good! +1
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with
> "Please remove properties [optional, enabled] from your cassandra.yaml"
> --
>
> Key: CASSANDRA-14075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14075
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Kjellman
>Assignee: Jason Brown
>
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption dtests are failing on
> 3.11 with an exception on startup due to invalid yaml properties.
> Unexpected error in node1 log, error:
> ERROR [main] 2017-11-18 21:01:54,781 CassandraDaemon.java:706 - Exception
> encountered during startup: Invalid yaml. Please remove properties [optional,
> enabled] from your cassandra.yaml
> Although ccm was updated in
> https://github.com/pcmanus/ccm/commit/eaaa425b70edb84786924516aee3920d685c0e53
> to include a version check for >= 4.0, enabled and optional are emitted
> unconditionally in the actual dtest itself -- they should also be conditional
> on >= 4.0
> {code:java}
> node.set_configuration_options(values={
> 'server_encryption_options': {
> 'enabled': encryption_enabled,
> 'optional': encryption_optional,
> 'internode_encryption': internode_encryption,
> 'keystore': kspath,
> 'keystore_password': 'cassandra',
> 'truststore': tspath,
> 'truststore_password': 'cassandra',
> 'require_endpoint_verification': endpoint_verification,
> 'require_client_auth': client_auth,
> }
> })
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14075) Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with "Please remove properties [optional, enabled] from your cassandra.yaml"
[
https://issues.apache.org/jira/browse/CASSANDRA-14075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-14075:
-
Description:
Many sslnodetonode_test.TestNodeToNodeSSLEncryption dtests are failing on 3.11
with an exception on startup due to invalid yaml properties.
Unexpected error in node1 log, error:
ERROR [main] 2017-11-18 21:01:54,781 CassandraDaemon.java:706 - Exception
encountered during startup: Invalid yaml. Please remove properties [optional,
enabled] from your cassandra.yaml
Although ccm was updated in
https://github.com/pcmanus/ccm/commit/eaaa425b70edb84786924516aee3920d685c0e53
to include a version check for >= 4.0, enabled and optional are emitted
unconditionally in the actual dtest itself -- they should also be conditional
on >= 4.0
{code:java}
node.set_configuration_options(values={
'server_encryption_options': {
'enabled': encryption_enabled,
'optional': encryption_optional,
'internode_encryption': internode_encryption,
'keystore': kspath,
'keystore_password': 'cassandra',
'truststore': tspath,
'truststore_password': 'cassandra',
'require_endpoint_verification': endpoint_verification,
'require_client_auth': client_auth,
}
})
{code}
was:
Many sslnodetonode_test.TestNodeToNodeSSLEncryption dtests are failing on 3.11
with an exception on startup due to invalid yaml properties.
Unexpected error in node1 log, error:
ERROR [main] 2017-11-18 21:01:54,781 CassandraDaemon.java:706 - Exception
encountered during startup: Invalid yaml. Please remove properties [optional,
enabled] from your cassandra.yaml
Although ccm was updated in
https://github.com/pcmanus/ccm/commit/eaaa425b70edb84786924516aee3920d685c0e53
to include a version check for >= 4.0, enabled and optional are emitted
unconditionally in the actual dtest itself -- they should also be conditional
on >= 4.0
node.set_configuration_options(values={
'server_encryption_options': {
'enabled': encryption_enabled,
'optional': encryption_optional,
'internode_encryption': internode_encryption,
'keystore': kspath,
'keystore_password': 'cassandra',
'truststore': tspath,
'truststore_password': 'cassandra',
'require_endpoint_verification': endpoint_verification,
'require_client_auth': client_auth,
}
})
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with
> "Please remove properties [optional, enabled] from your cassandra.yaml"
> --
>
> Key: CASSANDRA-14075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14075
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Kjellman
>Assignee: Jason Brown
>
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption dtests are failing on
> 3.11 with an exception on startup due to invalid yaml properties.
> Unexpected error in node1 log, error:
> ERROR [main] 2017-11-18 21:01:54,781 CassandraDaemon.java:706 - Exception
> encountered during startup: Invalid yaml. Please remove properties [optional,
> enabled] from your cassandra.yaml
> Although ccm was updated in
> https://github.com/pcmanus/ccm/commit/eaaa425b70edb84786924516aee3920d685c0e53
> to include a version check for >= 4.0, enabled and optional are emitted
> unconditionally in the actual dtest itself -- they should also be conditional
> on >= 4.0
> {code:java}
> node.set_configuration_options(values={
> 'server_encryption_options': {
> 'enabled': encryption_enabled,
> 'optional': encryption_optional,
> 'internode_encryption': internode_encryption,
> 'keystore': kspath,
> 'keystore_password': 'cassandra',
> 'truststore': tspath,
> 'truststore_password': 'cassandra',
> 'require_endpoint_verification': endpoint_verification,
> 'require_client_auth': client_auth,
> }
> })
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14075) Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with "Please remove properties [optional, enabled] from your cassandra.yaml"
Michael Kjellman created CASSANDRA-14075:
Summary: Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests
failing with "Please remove properties [optional, enabled] from your
cassandra.yaml"
Key: CASSANDRA-14075
URL: https://issues.apache.org/jira/browse/CASSANDRA-14075
Project: Cassandra
Issue Type: Bug
Reporter: Michael Kjellman
Many sslnodetonode_test.TestNodeToNodeSSLEncryption dtests are failing on 3.11
with an exception on startup due to invalid yaml properties.
Unexpected error in node1 log, error:
ERROR [main] 2017-11-18 21:01:54,781 CassandraDaemon.java:706 - Exception
encountered during startup: Invalid yaml. Please remove properties [optional,
enabled] from your cassandra.yaml
Although ccm was updated in
https://github.com/pcmanus/ccm/commit/eaaa425b70edb84786924516aee3920d685c0e53
to include a version check for >= 4.0, enabled and optional are emitted
unconditionally in the actual dtest itself -- they should also be conditional
on >= 4.0
node.set_configuration_options(values={
'server_encryption_options': {
'enabled': encryption_enabled,
'optional': encryption_optional,
'internode_encryption': internode_encryption,
'keystore': kspath,
'keystore_password': 'cassandra',
'truststore': tspath,
'truststore_password': 'cassandra',
'require_endpoint_verification': endpoint_verification,
'require_client_auth': client_auth,
}
})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14075) Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with "Please remove properties [optional, enabled] from your cassandra.yaml"
[
https://issues.apache.org/jira/browse/CASSANDRA-14075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman reassigned CASSANDRA-14075:
Assignee: Jason Brown
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption tests failing with
> "Please remove properties [optional, enabled] from your cassandra.yaml"
> --
>
> Key: CASSANDRA-14075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14075
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Kjellman
>Assignee: Jason Brown
>
> Many sslnodetonode_test.TestNodeToNodeSSLEncryption dtests are failing on
> 3.11 with an exception on startup due to invalid yaml properties.
> Unexpected error in node1 log, error:
> ERROR [main] 2017-11-18 21:01:54,781 CassandraDaemon.java:706 - Exception
> encountered during startup: Invalid yaml. Please remove properties [optional,
> enabled] from your cassandra.yaml
> Although ccm was updated in
> https://github.com/pcmanus/ccm/commit/eaaa425b70edb84786924516aee3920d685c0e53
> to include a version check for >= 4.0, enabled and optional are emitted
> unconditionally in the actual dtest itself -- they should also be conditional
> on >= 4.0
>node.set_configuration_options(values={
> 'server_encryption_options': {
> 'enabled': encryption_enabled,
> 'optional': encryption_optional,
> 'internode_encryption': internode_encryption,
> 'keystore': kspath,
> 'keystore_password': 'cassandra',
> 'truststore': tspath,
> 'truststore_password': 'cassandra',
> 'require_endpoint_verification': endpoint_verification,
> 'require_client_auth': client_auth,
> }
> })
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14074) Remove "OpenJDK is not recommended" Startup Warning
Michael Kjellman created CASSANDRA-14074: Summary: Remove "OpenJDK is not recommended" Startup Warning Key: CASSANDRA-14074 URL: https://issues.apache.org/jira/browse/CASSANDRA-14074 Project: Cassandra Issue Type: Improvement Reporter: Michael Kjellman We should remove the following warning on C* startup that OpenJDK is not recommended. Now that with JDK8 OpenJDK is the reference JVM implementation and things are much more stable -- and that all of our tests run on OpenJDK builds due to the Oracle JDK license, this warning isn't helpful and is actually wrong and we should remove it to prevent any user confusion. WARN [main] 2017-11-28 19:39:08,446 StartupChecks.java:202 - OpenJDK is not recommended. Please upgrade to the newest Oracle Java release -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14020) test_pep8_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh: pep8 has been renamed to pycodestyle (GitHub issue #466)
[ https://issues.apache.org/jira/browse/CASSANDRA-14020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16267910#comment-16267910 ] Michael Kjellman commented on CASSANDRA-14020: -- [~jay.zhuang] my bad, i forgot to link the two jira's... the pycodestyle issue is handled in CASSANDRA-14021 (commit available there)... > test_pep8_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh: pep8 has been > renamed to pycodestyle (GitHub issue #466) > -- > > Key: CASSANDRA-14020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14020 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman >Assignee: Michael Kjellman > > test_pep8_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh always fails due to > us catching a informative warning from the pip8 tool.. looks like we just > need to swap out the usage > /home/cassandra/env/local/lib/python2.7/site-packages/pep8.py:2124: > UserWarning: > pep8 has been renamed to pycodestyle (GitHub issue #466) > Use of the pep8 tool will be removed in a future release. > Please install and use `pycodestyle` instead. > $ pip install pycodestyle > $ pycodestyle ... > '\n\n' -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14056) Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true"
Michael Kjellman created CASSANDRA-14056: Summary: Many dtests fail with ConfigurationException: offheap_objects are not available in 3.0 when OFFHEAP_MEMTABLES="true" Key: CASSANDRA-14056 URL: https://issues.apache.org/jira/browse/CASSANDRA-14056 Project: Cassandra Issue Type: Bug Components: Testing Reporter: Michael Kjellman Tons of dtests are running when they shouldn't as it looks like the path is no longer supported.. we need to add a bunch of logic that's missing to fully support running dtests with off-heap memtables enabled (via the OFFHEAP_MEMTABLES="true" environment variable) [node2 ERROR] java.lang.ExceptionInInitializerError at org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:394) at org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:361) at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:577) at org.apache.cassandra.db.ColumnFamilyStore.createColumnFamilyStore(ColumnFamilyStore.java:554) at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:368) at org.apache.cassandra.db.Keyspace.(Keyspace.java:305) at org.apache.cassandra.db.Keyspace.open(Keyspace.java:129) at org.apache.cassandra.db.Keyspace.open(Keyspace.java:106) at org.apache.cassandra.db.SystemKeyspace.checkHealth(SystemKeyspace.java:887) at org.apache.cassandra.service.StartupChecks$9.execute(StartupChecks.java:354) at org.apache.cassandra.service.StartupChecks.verify(StartupChecks.java:110) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:179) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:569) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:697) Caused by: org.apache.cassandra.exceptions.ConfigurationException: offheap_objects are not available in 3.0. They will be re-introduced in a future release, see https://issues.apache.org/jira/browse/CASSANDRA-9472 for details at org.apache.cassandra.config.DatabaseDescriptor.getMemtableAllocatorPool(DatabaseDescriptor.java:1907) at org.apache.cassandra.db.Memtable.(Memtable.java:65) ... 14 more -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14054) testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1>
Michael Kjellman created CASSANDRA-14054: Summary: testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1> Key: CASSANDRA-14054 URL: https://issues.apache.org/jira/browse/CASSANDRA-14054 Project: Cassandra Issue Type: Bug Components: Testing Reporter: Michael Kjellman testRegularColumnTimestampUpdates - org.apache.cassandra.cql3.ViewTest is flaky: expected <2> but got <1> Fails about 25% of the time. It is currently our only flaky unit test on trunk so it would be great to get this one fixed up so we can be confident in unit test failures going forward. junit.framework.AssertionFailedError: Invalid value for row 0 column 0 (c of type int), expected <2> but got <1> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:973) at org.apache.cassandra.cql3.ViewTest.testRegularColumnTimestampUpdates(ViewTest.java:380) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14053) test_scrub_static_table - scrub_test.TestScrubIndexes fails: Keyspace 'ks' already exists
Michael Kjellman created CASSANDRA-14053:
Summary: test_scrub_static_table - scrub_test.TestScrubIndexes
fails: Keyspace 'ks' already exists
Key: CASSANDRA-14053
URL: https://issues.apache.org/jira/browse/CASSANDRA-14053
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_scrub_static_table - scrub_test.TestScrubIndexes fails: Keyspace 'ks'
already exists... looks like another test isn't cleaning up after itself or
something which causes all the other tests in this suite to fail going forward..
test_select_in_clause_with_duplicate_keys - paging_test.TestPagingData
test_scrub_collections_table - scrub_test.TestScrubIndexes
test_scrub_static_table - scrub_test.TestScrubIndexes
Error from server: code=1000 [Unavailable exception] message="Cannot achieve
consistency level ONE" info={'required_replicas': 1, 'alive_replicas': 0,
'consistency': 'ONE'}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14052) test_low_cardinality_indexes almost always deadlocks nosetests
Michael Kjellman created CASSANDRA-14052: Summary: test_low_cardinality_indexes almost always deadlocks nosetests Key: CASSANDRA-14052 URL: https://issues.apache.org/jira/browse/CASSANDRA-14052 Project: Cassandra Issue Type: Bug Components: Testing Reporter: Michael Kjellman test_low_cardinality_indexes currently almost always causes nosetests to deadlock on test cleanup after it runs. This causes us to have to hit timeouts and the test never actually completes successfully. We should disable this test from running until we root cause it and make it a useful test. I've yet to get this test to pass once successfully. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14051) Many materialized_views_test are busted
Michael Kjellman created CASSANDRA-14051: Summary: Many materialized_views_test are busted Key: CASSANDRA-14051 URL: https://issues.apache.org/jira/browse/CASSANDRA-14051 Project: Cassandra Issue Type: Bug Components: Testing Reporter: Michael Kjellman Many materialized_views_test are busted... For now we should disable the entire MV test suite until effort is put into making these test usable and helpful. Currently they aren't helpful and almost all fail. test_base_column_in_view_pk_commutative_tombstone_without_flush - materialized_views_test.TestMaterializedViews test_base_column_in_view_pk_complex_timestamp_with_flush - materialized_views_test.TestMaterializedViews add_dc_after_mv_network_replication_test - materialized_views_test.TestMaterializedViews add_dc_after_mv_simple_replication_test - materialized_views_test.TestMaterializedViews add_node_after_mv_test - materialized_views_test.TestMaterializedViews add_node_after_very_wide_mv_test - materialized_views_test.TestMaterializedViews add_node_after_wide_mv_with_range_deletions_test - materialized_views_test.TestMaterializedViews -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14036) simple_rebuild_test - rebuild_test.TestRebuild fails
Michael Kjellman created CASSANDRA-14036:
Summary: simple_rebuild_test - rebuild_test.TestRebuild fails
Key: CASSANDRA-14036
URL: https://issues.apache.org/jira/browse/CASSANDRA-14036
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
simple_rebuild_test - rebuild_test.TestRebuild fails
Inet address 127.0.0.1:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback alias
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-GqqOHa
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/rebuild_test.py", line 42, in
simple_rebuild_test
node1.start(wait_for_binary_proto=True)
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 606, in start
common.assert_socket_available(itf)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/common.py", line
519, in assert_socket_available
raise UnavailableSocketError("Inet address %s:%s is not available: %s; a
cluster may already be running or you may need to add the loopback alias" %
(addr, port, msg))
"Inet address 127.0.0.1:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback
alias\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-GqqOHa\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
[Errno 2] No such file or directory:
'/tmp/dtest-GqqOHa/test/node1/logs/system.log'
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-GqqOHa
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 358, in run
self.tearDown()
File "/home/cassandra/cassandra-dtest/dtest.py", line 597, in tearDown
if not self.allow_log_errors and self.check_logs_for_errors():
File "/home/cassandra/cassandra-dtest/dtest.py", line 614, in
check_logs_for_errors
['\n'.join(msg) for msg in node.grep_log_for_errors()]))
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 386, in grep_log_for_errors
return self.grep_log_for_errors_from(seek_start=getattr(self, 'error_mark',
0))
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 389, in grep_log_for_errors_from
with open(os.path.join(self.get_path(), 'logs', filename)) as f:
"[Errno 2] No such file or directory:
'/tmp/dtest-GqqOHa/test/node1/logs/system.log'\n >> begin
captured logging << \ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-GqqOHa\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14050) Many cqlsh_copy_tests are busted
Michael Kjellman created CASSANDRA-14050:
Summary: Many cqlsh_copy_tests are busted
Key: CASSANDRA-14050
URL: https://issues.apache.org/jira/browse/CASSANDRA-14050
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
Many cqlsh_copy_tests are busted. We should disable the entire suite until this
is resolved as these tests are currently nothing but a waste of time.
test_bulk_round_trip_blogposts - cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest
test_bulk_round_trip_blogposts_with_max_connections -
cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest
test_bulk_round_trip_default - cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest
Error starting node3.
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-S9NfIH
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'memtable_allocation_type': 'offheap_objects',
'num_tokens': '256',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", line
2546, in test_bulk_round_trip_blogposts
stress_table='stresscql.blogposts')
File "/home/cassandra/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", line
2451, in _test_bulk_round_trip
self.prepare(nodes=nodes, partitioner=partitioner,
configuration_options=configuration_options)
File "/home/cassandra/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", line
115, in prepare
self.cluster.populate(nodes,
tokens=tokens).start(wait_for_binary_proto=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
423, in start
raise NodeError("Error starting {0}.".format(node.name), p)
"Error starting node3.\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-S9NfIH\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'memtable_allocation_type': 'offheap_objects',\n
'num_tokens': '256',\n'phi_convict_threshold': 5,\n
'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms':
1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14041) test_dead_sync_initiator - repair_tests.repair_test.TestRepair fails: Unexpected error in log, see stdout
Michael Kjellman created CASSANDRA-14041:
Summary: test_dead_sync_initiator -
repair_tests.repair_test.TestRepair fails: Unexpected error in log, see stdout
Key: CASSANDRA-14041
URL: https://issues.apache.org/jira/browse/CASSANDRA-14041
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_dead_sync_initiator - repair_tests.repair_test.TestRepair fails:
Unexpected error in log, see stdout
Unexpected error in log, see stdout
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-unRvig
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'memtable_allocation_type': 'offheap_objects',
'num_tokens': '256',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Setting up cluster..
dtest: DEBUG: Setting up byteman on node2
dtest: DEBUG: Starting cluster..
dtest: DEBUG: stopping node3
cassandra.cluster: INFO: New Cassandra host
discovered
cassandra.cluster: INFO: New Cassandra host
discovered
dtest: DEBUG: inserting data while node3 is down
dtest: DEBUG: bring back node3
cassandra.cluster: WARNING: Node 127.0.0.1 is reporting a schema disagreement:
{UUID('b79efe52-1b85-32f0-ade8-f6505602bd97'): ['127.0.0.2', '127.0.0.1'],
UUID('59a1610b-0384-337c-a2c5-9c8efaba12be'): ['127.0.0.3']}
dtest: DEBUG: Submitting byteman script to node2
dtest: DEBUG: repair node1
dtest: DEBUG: Will kill node2 in middle of sync
cassandra.cluster: INFO: Host 127.0.0.3 may be up; will prepare queries and
open connection pool
dtest: DEBUG: Killed node2, now waiting repair to finish
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 358, in run
self.tearDown()
File "/home/cassandra/cassandra-dtest/dtest.py", line 599, in tearDown
raise AssertionError('Unexpected error in log, see stdout')
"Unexpected error in log, see stdout\n >> begin captured
logging << \ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-unRvig\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'memtable_allocation_type': 'offheap_objects',\n
'num_tokens': '256',\n'phi_convict_threshold': 5,\n
'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms':
1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\ndtest: DEBUG: Setting up cluster..\ndtest: DEBUG: Setting up byteman on
node2\ndtest: DEBUG: Starting cluster..\ndtest: DEBUG: stopping
node3\ncassandra.cluster: INFO: New Cassandra host discovered\ncassandra.cluster: INFO: New Cassandra host discovered\ndtest: DEBUG: inserting data while node3 is
down\ndtest: DEBUG: bring back node3\ncassandra.cluster: WARNING: Node
127.0.0.1 is reporting a schema disagreement:
{UUID('b79efe52-1b85-32f0-ade8-f6505602bd97'): ['127.0.0.2', '127.0.0.1'],
UUID('59a1610b-0384-337c-a2c5-9c8efaba12be'): ['127.0.0.3']}\ndtest: DEBUG:
Submitting byteman script to node2\ndtest: DEBUG: repair node1\ndtest: DEBUG:
Will kill node2 in middle of sync\ncassandra.cluster: INFO: Host 127.0.0.3 may
be up; will prepare queries and open connection pool\ndtest: DEBUG: Killed
node2, now waiting repair to finish\n- >> end captured
logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14049) All auth upgrade dtests are busted
Michael Kjellman created CASSANDRA-14049:
Summary: All auth upgrade dtests are busted
Key: CASSANDRA-14049
URL: https://issues.apache.org/jira/browse/CASSANDRA-14049
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
All of the upgrade tests that use authentication are busted
upgrade_to_22_test - upgrade_internal_auth_test.TestAuthUpgrade
upgrade_to_30_test - upgrade_internal_auth_test.TestAuthUpgrade
Unexpected error in log, see stdout
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-B7HBYk
dtest: DEBUG: Done setting configuration options:
{ 'authenticator': 'PasswordAuthenticator',
'authorizer': 'CassandraAuthorizer',
'initial_token': None,
'memtable_allocation_type': 'offheap_objects',
'num_tokens': '256',
'phi_convict_threshold': 5}
ccm: INFO: Cloning Cassandra...
repository: INFO:
repository: INFO: Cloning into bare repository
'/home/cassandra/.ccm/repository/_git_cache_apache'...
Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of
known hosts.
ccm: INFO: Cloning Cassandra (from local cache)
repository: INFO:
repository: INFO: Cloning into
'/home/cassandra/.ccm/repository/githubCOLONapacheSLASHcassandra-2.1'...
done.
ccm: INFO: Checking out requested branch (cassandra-2.1)
repository: INFO: Branch cassandra-2.1 set up to track remote branch
cassandra-2.1 from origin.
repository: INFO: Switched to a new branch 'cassandra-2.1'
ccm: INFO: Compiling Cassandra cassandra-2.1 ...
repository: INFO: --- Cassandra Build ---
repository: INFO: Buildfile:
/home/cassandra/.ccm/repository/githubCOLONapacheSLASHcassandra-2.1/build.xml
init:
[mkdir] Created dir:
/home/cassandra/.ccm/repository/githubCOLONapacheSLASHcassandra-2.1/build/classes/main
[mkdir] Created dir:
/home/cassandra/.ccm/repository/githubCOLONapacheSLASHcassandra-2.1/build/classes/thrift
[mkdir] Created dir:
/home/cassandra/.ccm/repository/githubCOLONapacheSLASHcassandra-2.1/build/test/lib
[mkdir] Created dir:
/home/cassandra/.ccm/repository/githubCOLONapacheSLASHcassandra-2.1/build/test/classes
[mkdir] Created dir:
/home/cassandra/.ccm/repository/githubCOLONapacheSLASHcassandra-2.1/src/gen-java
[mkdir] Created dir:
/home/cassandra/.ccm/repository/githubCOLONapacheSLASHcassandra-2.1/build/lib
maven-ant-tasks-localrepo:
[copy] Copying 1 file to
/home/cassandra/.ccm/repository/githubCOLONapacheSLASHcassandra-2.1/build
maven-ant-tasks-download:
maven-ant-tasks-init:
maven-declare-dependencies:
maven-ant-tasks-retrieve-build:
[artifact:dependencies] Downloading: junit/junit/4.6/junit-4.6.pom from
repository central at http://repo1.maven.org/maven2
[artifact:dependencies] Transferring 1K from central
[artifact:dependencies] Downloading:
commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.pom from repository
central at http://repo1.maven.org/maven2
[artifact:dependencies] Transferring 18K from central
[artifact:dependencies] Downloading:
org/apache/commons/commons-parent/5/commons-parent-5.pom from repository
central at http://repo1.maven.org/maven2
[artifact:dependencies] Transferring 16K from central
[artifact:dependencies] Downloading: junit/junit/3.8.1/junit-3.8.1.pom from
repository apache at http://repo.maven.apache.org/maven2
[artifact:dependencies] Transferring 1K from apache
[artifact:dependencies] Downloading:
commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.pom from repository
apache at http://repo.maven.apache.org/maven2
[artifact:dependencies] Transferring 1K from apache
[artifact:dependencies] Downloading:
commons-logging/commons-logging/1.1/commons-logging-1.1.pom from repository
apache at http://repo.maven.apache.org/maven2
[artifact:dependencies] Transferring 6K from apache
[artifact:dependencies] Downloading: org/eclipse/jdt/core/3.1.1/core-3.1.1.pom
from repository apache at http://repo.maven.apache.org/maven2
[artifact:dependencies] Transferring 1K from apache
[artifact:dependencies] Downloading:
org/slf4j/slf4j-api/1.5.2/slf4j-api-1.5.2.pom from repository apache at
http://repo.maven.apache.org/maven2
[artifact:dependencies] Transferring 3K from apache
[artifact:dependencies] Downloading:
org/slf4j/slf4j-parent/1.5.2/slf4j-parent-1.5.2.pom from repository apache at
http://repo.maven.apache.org/maven2
[artifact:dependencies] Transferring 7K from apache
[artifact:dependencies] Downloading: asm/asm/3.1/asm-3.1.pom from repository
apache at http://repo.maven.apache.org/maven2
[artifact:dependencies] Transferring 0K from apache
[artifact:dependencies] Downloading: asm/asm-parent/3.1/asm-parent-3.1.pom from
repository apache at http://repo.maven.apache.org/maven2
[artifact:dependencies] Transferring 4K from apache
[artifact:dependencies] Downloading:
[jira] [Created] (CASSANDRA-14048) test_ttl_deletions - paging_test.TestPagingWithDeletions fails: [Unavailable exception]
Michael Kjellman created CASSANDRA-14048:
Summary: test_ttl_deletions - paging_test.TestPagingWithDeletions
fails: [Unavailable exception]
Key: CASSANDRA-14048
URL: https://issues.apache.org/jira/browse/CASSANDRA-14048
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_ttl_deletions - paging_test.TestPagingWithDeletions fails: [Unavailable
exception]
Error from server: code=1000 [Unavailable exception] message="Cannot achieve
consistency level ALL" info={'required_replicas': 2, 'alive_replicas': 1,
'consistency': 'ALL'}
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-lCOixs
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
cassandra.cluster: INFO: New Cassandra host discovered
cassandra.cluster: INFO: New Cassandra host
discovered
cassandra.cluster: INFO: New Cassandra host discovered
cassandra.cluster: INFO: New Cassandra host
discovered
cassandra.cluster: INFO: New Cassandra host discovered
cassandra.cluster: WARNING: Failed to create connection pool for new host
127.0.0.9:
Traceback (most recent call last):
File "cassandra/cluster.py", line 2452, in
cassandra.cluster.Session.add_or_renew_pool.run_add_or_renew_pool
new_pool = HostConnection(host, distance, self)
File "cassandra/pool.py", line 332, in cassandra.pool.HostConnection.__init__
self._connection = session.cluster.connection_factory(host.address)
File "cassandra/cluster.py", line 1195, in
cassandra.cluster.Cluster.connection_factory
return self.connection_class.factory(address, self.connect_timeout, *args,
**kwargs)
File "cassandra/connection.py", line 332, in
cassandra.connection.Connection.factory
conn = cls(host, *args, **kwargs)
File
"/home/cassandra/env/src/cassandra-driver/cassandra/io/asyncorereactor.py",
line 344, in __init__
self._connect_socket()
File "cassandra/connection.py", line 371, in
cassandra.connection.Connection._connect_socket
raise socket.error(sockerr.errno, "Tried connecting to %s. Last error: %s"
% ([a[4] for a in addresses], sockerr.strerror or sockerr))
error: [Errno 111] Tried connecting to [('127.0.0.9', 9042)]. Last error:
Connection refused
cassandra.cluster: WARNING: Failed to create connection pool for new host
127.0.0.4:
Traceback (most recent call last):
File "cassandra/cluster.py", line 2452, in
cassandra.cluster.Session.add_or_renew_pool.run_add_or_renew_pool
new_pool = HostConnection(host, distance, self)
File "cassandra/pool.py", line 332, in cassandra.pool.HostConnection.__init__
self._connection = session.cluster.connection_factory(host.address)
File "cassandra/cluster.py", line 1195, in
cassandra.cluster.Cluster.connection_factory
return self.connection_class.factory(address, self.connect_timeout, *args,
**kwargs)
File "cassandra/connection.py", line 332, in
cassandra.connection.Connection.factory
conn = cls(host, *args, **kwargs)
File
"/home/cassandra/env/src/cassandra-driver/cassandra/io/asyncorereactor.py",
line 344, in __init__
self._connect_socket()
File "cassandra/connection.py", line 371, in
cassandra.connection.Connection._connect_socket
raise socket.error(sockerr.errno, "Tried connecting to %s. Last error: %s"
% ([a[4] for a in addresses], sockerr.strerror or sockerr))
error: [Errno 111] Tried connecting to [('127.0.0.4', 9042)]. Last error:
Connection refused
cassandra.cluster: WARNING: Host 127.0.0.9 has been marked down
cassandra.cluster: WARNING: Host 127.0.0.4 has been marked down
cassandra.pool: WARNING: Error attempting to reconnect to 127.0.0.9, scheduling
retry in 2.0 seconds: [Errno 111] Tried connecting to [('127.0.0.9', 9042)].
Last error: Connection refused
cassandra.pool: WARNING: Error attempting to reconnect to 127.0.0.4, scheduling
retry in 2.0 seconds: [Errno 111] Tried connecting to [('127.0.0.4', 9042)].
Last error: Connection refused
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE. Attempt #0
dtest: DEBUG: Retrying request after UE.
[jira] [Created] (CASSANDRA-14047) test_simple_strategy_each_quorum_users - consistency_test.TestAccuracy fails: Missing: ['127.0.0.3.* now UP']:
Michael Kjellman created CASSANDRA-14047:
Summary: test_simple_strategy_each_quorum_users -
consistency_test.TestAccuracy fails: Missing: ['127.0.0.3.* now UP']:
Key: CASSANDRA-14047
URL: https://issues.apache.org/jira/browse/CASSANDRA-14047
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_simple_strategy_each_quorum_users - consistency_test.TestAccuracy fails:
Missing: ['127.0.0.3.* now UP']:
15 Nov 2017 11:23:37 [node1] Missing: ['127.0.0.3.* now UP']:
INFO [main] 2017-11-15 11:21:32,452 YamlConfigura.
See system.log for remainder
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-v3VgyS
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Testing single dc, users, each quorum reads
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/tools/decorators.py", line 48, in
wrapped
f(obj)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 621, in
test_simple_strategy_each_quorum_users
self._run_test_function_in_parallel(TestAccuracy.Validation.validate_users,
[self.nodes], [self.rf], combinations)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 535, in
_run_test_function_in_parallel
self._start_cluster(save_sessions=True,
requires_local_reads=requires_local_reads)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 141, in
_start_cluster
cluster.start(wait_for_binary_proto=True, wait_other_notice=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
428, in start
node.watch_log_for_alive(other_node, from_mark=mark)
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 520, in watch_log_for_alive
self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
filename=filename)
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 488, in watch_log_for
raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " ["
+ self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" +
reads[:50] + ".\nSee {} for remainder".format(filename))
"15 Nov 2017 11:23:37 [node1] Missing: ['127.0.0.3.* now UP']:\nINFO [main]
2017-11-15 11:21:32,452 YamlConfigura.\nSee system.log for
remainder\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-v3VgyS\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\ndtest: DEBUG: Testing single dc, users, each quorum
reads\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14046) test_simple_strategy_counters - consistency_test.TestAccuracy fails:
Michael Kjellman created CASSANDRA-14046:
Summary: test_simple_strategy_counters -
consistency_test.TestAccuracy fails: https://issues.apache.org/jira/browse/CASSANDRA-14046
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_simple_strategy_counters - consistency_test.TestAccuracy fails:
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-KYtuWZ
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Testing single dc, counters
dtest: DEBUG: Changing snitch for single dc case
cassandra.cluster: INFO: New Cassandra host discovered
cassandra.cluster: INFO: New Cassandra host discovered
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 704, in
test_simple_strategy_counters
self._run_test_function_in_parallel(TestAccuracy.Validation.validate_counters,
[self.nodes], [self.rf], combinations)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 535, in
_run_test_function_in_parallel
self._start_cluster(save_sessions=True,
requires_local_reads=requires_local_reads)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 147, in
_start_cluster
self.create_tables(session, requires_local_reads)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 156, in
create_tables
self.create_users_table(session, requires_local_reads)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 178, in
create_users_table
session.execute(create_cmd)
File "cassandra/cluster.py", line 2122, in cassandra.cluster.Session.execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state).result()
File "cassandra/cluster.py", line 3982, in
cassandra.cluster.ResponseFuture.result
raise self._final_exception
'\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-KYtuWZ\ndtest: DEBUG: Done setting configuration options:\n{
\'initial_token\': None,\n\'num_tokens\': \'32\',\n
\'phi_convict_threshold\': 5,\n\'range_request_timeout_in_ms\': 1,\n
\'read_request_timeout_in_ms\': 1,\n\'request_timeout_in_ms\': 1,\n
\'truncate_request_timeout_in_ms\': 1,\n
\'write_request_timeout_in_ms\': 1}\ndtest: DEBUG: Testing single dc,
counters\ndtest: DEBUG: Changing snitch for single dc case\ncassandra.cluster:
INFO: New Cassandra host discovered\ncassandra.cluster:
INFO: New Cassandra host
discovered\n- >> end captured logging <<
-'
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14045) test_rf_collapse_gossiping_property_file_snitch_multi_dc - replication_test.SnitchConfigurationUpdateTest fails: Error starting node1.
Michael Kjellman created CASSANDRA-14045:
Summary: test_rf_collapse_gossiping_property_file_snitch_multi_dc
- replication_test.SnitchConfigurationUpdateTest fails: Error starting node1.
Key: CASSANDRA-14045
URL: https://issues.apache.org/jira/browse/CASSANDRA-14045
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_rf_collapse_gossiping_property_file_snitch_multi_dc -
replication_test.SnitchConfigurationUpdateTest fails: Error starting node1.
Error starting node1.
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-uLxzkm
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/replication_test.py", line 401, in
test_rf_collapse_gossiping_property_file_snitch_multi_dc
nodes_to_shutdown=[0, 2, 3, 5])
File "/home/cassandra/cassandra-dtest/replication_test.py", line 536, in
_test_rf_on_snitch_update
cluster.start(wait_for_binary_proto=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
423, in start
raise NodeError("Error starting {0}.".format(node.name), p)
"Error starting node1.\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-uLxzkm\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14044) test_paging_with_filtering_on_partition_key - paging_test.TestPagingData fails
Michael Kjellman created CASSANDRA-14044:
Summary: test_paging_with_filtering_on_partition_key -
paging_test.TestPagingData fails
Key: CASSANDRA-14044
URL: https://issues.apache.org/jira/browse/CASSANDRA-14044
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_paging_with_filtering_on_partition_key - paging_test.TestPagingData fails
Inet address 127.0.0.3:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback alias
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-c8abwC
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/tools/decorators.py", line 48, in
wrapped
f(obj)
File "/home/cassandra/cassandra-dtest/paging_test.py", line 2154, in
test_paging_with_filtering_on_partition_key
session = self.prepare(row_factory=tuple_factory)
File "/home/cassandra/cassandra-dtest/paging_test.py", line 26, in prepare
cluster.populate(3).start(wait_for_binary_proto=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
389, in start
common.assert_socket_available(itf)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/common.py", line
519, in assert_socket_available
raise UnavailableSocketError("Inet address %s:%s is not available: %s; a
cluster may already be running or you may need to add the loopback alias" %
(addr, port, msg))
"Inet address 127.0.0.3:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback
alias\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-c8abwC\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14043) Lots of failures in test_network_topology_strategy
Michael Kjellman created CASSANDRA-14043:
Summary: Lots of failures in test_network_topology_strategy
Key: CASSANDRA-14043
URL: https://issues.apache.org/jira/browse/CASSANDRA-14043
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
There are lots of failures in test_network_topology_strategy... Creating one
JIRA to track them all...
test_network_topology_strategy - consistency_test.TestAvailability
[Errno 2] No such file or directory:
'/tmp/dtest-H1psQ0/test/node1/logs/system.log'
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-H1psQ0
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 358, in run
self.tearDown()
File "/home/cassandra/cassandra-dtest/dtest.py", line 597, in tearDown
if not self.allow_log_errors and self.check_logs_for_errors():
File "/home/cassandra/cassandra-dtest/dtest.py", line 614, in
check_logs_for_errors
['\n'.join(msg) for msg in node.grep_log_for_errors()]))
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 386, in grep_log_for_errors
return self.grep_log_for_errors_from(seek_start=getattr(self, 'error_mark',
0))
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 389, in grep_log_for_errors_from
with open(os.path.join(self.get_path(), 'logs', filename)) as f:
"[Errno 2] No such file or directory:
'/tmp/dtest-H1psQ0/test/node1/logs/system.log'\n >> begin
captured logging << \ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-H1psQ0\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
test_network_topology_strategy_counters - consistency_test.TestAccuracy
Error starting node3.
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-3px8TH
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Testing multiple dcs, counters
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 753, in
test_network_topology_strategy_counters
self._run_test_function_in_parallel(TestAccuracy.Validation.validate_counters,
self.nodes, self.rf.values(), combinations),
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 535, in
_run_test_function_in_parallel
self._start_cluster(save_sessions=True,
requires_local_reads=requires_local_reads)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 141, in
_start_cluster
cluster.start(wait_for_binary_proto=True, wait_other_notice=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
423, in start
raise NodeError("Error starting {0}.".format(node.name), p)
"Error starting node3.\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-3px8TH\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\ndtest: DEBUG: Testing multiple dcs, counters\n- >>
end captured logging << -"
test_network_topology_strategy_each_quorum_counters -
consistency_test.TestAccuracy
Error starting node1.
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-EkrtYq
dtest: DEBUG:
[jira] [Created] (CASSANDRA-14042) test_multidatacenter_local_quorum - snitch_test.TestDynamicEndpointSnitch fails: Error starting node1.
Michael Kjellman created CASSANDRA-14042:
Summary: test_multidatacenter_local_quorum -
snitch_test.TestDynamicEndpointSnitch fails: Error starting node1.
Key: CASSANDRA-14042
URL: https://issues.apache.org/jira/browse/CASSANDRA-14042
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_multidatacenter_local_quorum - snitch_test.TestDynamicEndpointSnitch
fails: Error starting node1.
Error starting node1.
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-tqpTer
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/tools/decorators.py", line 48, in
wrapped
f(obj)
File "/home/cassandra/cassandra-dtest/snitch_test.py", line 130, in
test_multidatacenter_local_quorum
cluster.start(wait_for_binary_proto=30, wait_other_notice=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
423, in start
raise NodeError("Error starting {0}.".format(node.name), p)
"Error starting node1.\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-tqpTer\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14040) test_create_keyspace - cqlsh_tests.cqlsh_tests.CqlshSmokeTest fails: Inet address 127.0.0.1:9042 is not available
Michael Kjellman created CASSANDRA-14040:
Summary: test_create_keyspace -
cqlsh_tests.cqlsh_tests.CqlshSmokeTest fails: Inet address 127.0.0.1:9042 is
not available
Key: CASSANDRA-14040
URL: https://issues.apache.org/jira/browse/CASSANDRA-14040
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_create_keyspace - cqlsh_tests.cqlsh_tests.CqlshSmokeTest fails: Inet
address 127.0.0.1:9042 is not available
Inet address 127.0.0.1:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback alias
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-fwDheX
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 320, in run
self.setUp()
File "/home/cassandra/cassandra-dtest/cqlsh_tests/cqlsh_tests.py", line 1673,
in setUp
self.cluster.populate(1).start(wait_for_binary_proto=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
389, in start
common.assert_socket_available(itf)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/common.py", line
519, in assert_socket_available
raise UnavailableSocketError("Inet address %s:%s is not available: %s; a
cluster may already be running or you may need to add the loopback alias" %
(addr, port, msg))
"Inet address 127.0.0.1:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback
alias\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-fwDheX\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14039) sstableofflinerelevel_test - offline_tools_test.TestOfflineTools fails: 1 not greater than 1
Michael Kjellman created CASSANDRA-14039:
Summary: sstableofflinerelevel_test -
offline_tools_test.TestOfflineTools fails: 1 not greater than 1
Key: CASSANDRA-14039
URL: https://issues.apache.org/jira/browse/CASSANDRA-14039
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
sstableofflinerelevel_test - offline_tools_test.TestOfflineTools fails: 1 not
greater than 1
1 not greater than 1
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-6dD19K
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Altering compaction strategy to LCS
dtest: DEBUG: Waiting for compactions to finish
cassandra.connection: WARNING: Heartbeat failed for connection
(140282187829904) to 127.0.0.1
cassandra.cluster: WARNING: Host 127.0.0.1 has been marked down
dtest: DEBUG: Stopping node
cassandra.pool: WARNING: Error attempting to reconnect to 127.0.0.1, scheduling
retry in 2.0 seconds: [Errno 111] Tried connecting to [('127.0.0.1', 9042)].
Last error: Connection refused
cassandra.pool: WARNING: Error attempting to reconnect to 127.0.0.1, scheduling
retry in 4.0 seconds: [Errno 111] Tried connecting to [('127.0.0.1', 9042)].
Last error: Connection refused
dtest: DEBUG: Done stopping node
dtest: DEBUG: Getting initial levels
dtest: DEBUG: initial_levels:
dtest: DEBUG: [2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1,
2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 1, 2, 2, 1, 2, 2, 2, 1, 2, 2,
2, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 1, 2, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 2, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 1, 1, 2, 2, 2, 2,
2, 2, 1, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 1, 2, 1, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1,
2, 2, 2, 1, 2, 2, 1, 2, 2, 2, 2, 2, 2, 2, 1, 1, 2, 2, 2, 2, 2, 2, 2]
dtest: DEBUG: Running sstablelevelreset
cassandra.pool: WARNING: Error attempting to reconnect to 127.0.0.1, scheduling
retry in 8.0 seconds: [Errno 111] Tried connecting to [('127.0.0.1', 9042)].
Last error: Connection refused
dtest: DEBUG: Getting final levels
dtest: DEBUG: final levels:
dtest: DEBUG: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
dtest: DEBUG: Getting initial levels
dtest: DEBUG: Running sstableofflinerelevel
cassandra.pool: WARNING: Error attempting to reconnect to 127.0.0.1, scheduling
retry in 16.0 seconds: [Errno 111] Tried connecting to [('127.0.0.1', 9042)].
Last error: Connection refused
dtest: DEBUG: Getting final levels
dtest: DEBUG: For sstables in
/tmp/dtest-6dD19K/test/node1/data2/keyspace1/standard1-364d7340c9f711e7b4ce2bad8be7872b:
Current leveling:
L0=83
New leveling:
L0=0
L1=83
For sstables in
/tmp/dtest-6dD19K/test/node1/data0/keyspace1/standard1-364d7340c9f711e7b4ce2bad8be7872b:
Current leveling:
L0=93
New leveling:
L0=0
L1=93
For sstables in
/tmp/dtest-6dD19K/test/node1/data1/keyspace1/standard1-364d7340c9f711e7b4ce2bad8be7872b:
Current leveling:
L0=102
New leveling:
L0=0
L1=102
dtest: DEBUG: WARN 11:23:37,855 Max sstable size of 1MB is configured for
standard1.standard1. Testing done for CASSANDRA-5727 indicates that
performance improves up to 160MB
WARN 11:23:37,862 Max sstable size of 1MB is configured for
standard1.standard1. Testing done for CASSANDRA-5727 indicates that
performance improves up to 160MB
WARN 11:23:37,862 Max sstable size of 1MB is configured
[jira] [Created] (CASSANDRA-14038) sstableloader_with_mv_test - sstable_generation_loading_test.TestSSTableGenerationAndLoading fails
Michael Kjellman created CASSANDRA-14038:
Summary: sstableloader_with_mv_test -
sstable_generation_loading_test.TestSSTableGenerationAndLoading fails
Key: CASSANDRA-14038
URL: https://issues.apache.org/jira/browse/CASSANDRA-14038
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
sstableloader_with_mv_test -
sstable_generation_loading_test.TestSSTableGenerationAndLoading fails
Inet address 127.0.0.1:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback alias
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-LuSwz5
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Testing sstableloader with pre_compression=None and
post_compression=None
dtest: DEBUG: Using jvm_args=()
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/sstable_generation_loading_test.py",
line 296, in sstableloader_with_mv_test
self.load_sstable_with_configuration(ks='"Keyspace1"',
create_schema=create_schema_with_mv)
File "/home/cassandra/cassandra-dtest/sstable_generation_loading_test.py",
line 125, in load_sstable_with_configuration
cluster.populate(2).start(jvm_args=list(self.jvm_args))
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
389, in start
common.assert_socket_available(itf)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/common.py", line
519, in assert_socket_available
raise UnavailableSocketError("Inet address %s:%s is not available: %s; a
cluster may already be running or you may need to add the loopback alias" %
(addr, port, msg))
"Inet address 127.0.0.1:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback
alias\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-LuSwz5\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\ndtest: DEBUG: Testing sstableloader with pre_compression=None and
post_compression=None\ndtest: DEBUG: Using jvm_args=()\n-
>> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14037) sstableloader_with_failing_2i_test - sstable_generation_loading_test.TestSSTableGenerationAndLoading fails: Expected [['k', 'idx']] ... but got [[u'k', u'idx', None]
Michael Kjellman created CASSANDRA-14037:
Summary: sstableloader_with_failing_2i_test -
sstable_generation_loading_test.TestSSTableGenerationAndLoading fails: Expected
[['k', 'idx']] ... but got [[u'k', u'idx', None]]
Key: CASSANDRA-14037
URL: https://issues.apache.org/jira/browse/CASSANDRA-14037
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
sstableloader_with_failing_2i_test -
sstable_generation_loading_test.TestSSTableGenerationAndLoading fails: Expected
[['k', 'idx']] ... but got [[u'k', u'idx', None]]
Expected [['k', 'idx']] from SELECT * FROM system."IndexInfo" WHERE
table_name='k', but got [[u'k', u'idx', None]]
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-2My0fh
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
cassandra.cluster: WARNING: [control connection] Error connecting to 127.0.0.1:
Traceback (most recent call last):
File "cassandra/cluster.py", line 2781, in
cassandra.cluster.ControlConnection._reconnect_internal
return self._try_connect(host)
File "cassandra/cluster.py", line 2803, in
cassandra.cluster.ControlConnection._try_connect
connection = self._cluster.connection_factory(host.address,
is_control_connection=True)
File "cassandra/cluster.py", line 1195, in
cassandra.cluster.Cluster.connection_factory
return self.connection_class.factory(address, self.connect_timeout, *args,
**kwargs)
File "cassandra/connection.py", line 332, in
cassandra.connection.Connection.factory
conn = cls(host, *args, **kwargs)
File
"/home/cassandra/env/src/cassandra-driver/cassandra/io/asyncorereactor.py",
line 344, in __init__
self._connect_socket()
File "cassandra/connection.py", line 371, in
cassandra.connection.Connection._connect_socket
raise socket.error(sockerr.errno, "Tried connecting to %s. Last error: %s"
% ([a[4] for a in addresses], sockerr.strerror or sockerr))
error: [Errno 111] Tried connecting to [('127.0.0.1', 9042)]. Last error:
Connection refused
cassandra.cluster: WARNING: [control connection] Error connecting to 127.0.0.1:
Traceback (most recent call last):
File "cassandra/cluster.py", line 2781, in
cassandra.cluster.ControlConnection._reconnect_internal
return self._try_connect(host)
File "cassandra/cluster.py", line 2803, in
cassandra.cluster.ControlConnection._try_connect
connection = self._cluster.connection_factory(host.address,
is_control_connection=True)
File "cassandra/cluster.py", line 1195, in
cassandra.cluster.Cluster.connection_factory
return self.connection_class.factory(address, self.connect_timeout, *args,
**kwargs)
File "cassandra/connection.py", line 332, in
cassandra.connection.Connection.factory
conn = cls(host, *args, **kwargs)
File
"/home/cassandra/env/src/cassandra-driver/cassandra/io/asyncorereactor.py",
line 344, in __init__
self._connect_socket()
File "cassandra/connection.py", line 371, in
cassandra.connection.Connection._connect_socket
raise socket.error(sockerr.errno, "Tried connecting to %s. Last error: %s"
% ([a[4] for a in addresses], sockerr.strerror or sockerr))
error: [Errno 111] Tried connecting to [('127.0.0.1', 9042)]. Last error:
Connection refused
cassandra.cluster: WARNING: [control connection] Error connecting to 127.0.0.1:
Traceback (most recent call last):
File "cassandra/cluster.py", line 2781, in
cassandra.cluster.ControlConnection._reconnect_internal
return self._try_connect(host)
File "cassandra/cluster.py", line 2803, in
cassandra.cluster.ControlConnection._try_connect
connection = self._cluster.connection_factory(host.address,
is_control_connection=True)
File "cassandra/cluster.py", line 1195, in
cassandra.cluster.Cluster.connection_factory
return self.connection_class.factory(address, self.connect_timeout, *args,
**kwargs)
File "cassandra/connection.py", line 332, in
cassandra.connection.Connection.factory
conn = cls(host, *args, **kwargs)
File
"/home/cassandra/env/src/cassandra-driver/cassandra/io/asyncorereactor.py",
line 344, in __init__
self._connect_socket()
File "cassandra/connection.py", line 371, in
cassandra.connection.Connection._connect_socket
raise socket.error(sockerr.errno, "Tried connecting to %s. Last error: %s"
% ([a[4] for a in addresses], sockerr.strerror or sockerr))
error: [Errno 111] Tried connecting to [('127.0.0.1', 9042)]. Last error:
Connection refused
cassandra.cluster: WARNING: [control connection] Error connecting to 127.0.0.1:
Traceback
[jira] [Created] (CASSANDRA-14035) replace_nonexistent_node_test - replace_address_test.TestReplaceAddress fails
Michael Kjellman created CASSANDRA-14035:
Summary: replace_nonexistent_node_test -
replace_address_test.TestReplaceAddress fails
Key: CASSANDRA-14035
URL: https://issues.apache.org/jira/browse/CASSANDRA-14035
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
replace_nonexistent_node_test - replace_address_test.TestReplaceAddress fails
[Errno 2] No such file or directory:
'/tmp/dtest-5ohWPV/test/node1/logs/system.log'
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-5ohWPV
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Starting cluster with 3 nodes.
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 358, in run
self.tearDown()
File "/home/cassandra/cassandra-dtest/dtest.py", line 597, in tearDown
if not self.allow_log_errors and self.check_logs_for_errors():
File "/home/cassandra/cassandra-dtest/dtest.py", line 614, in
check_logs_for_errors
['\n'.join(msg) for msg in node.grep_log_for_errors()]))
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 386, in grep_log_for_errors
return self.grep_log_for_errors_from(seek_start=getattr(self, 'error_mark',
0))
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 389, in grep_log_for_errors_from
with open(os.path.join(self.get_path(), 'logs', filename)) as f:
"[Errno 2] No such file or directory:
'/tmp/dtest-5ohWPV/test/node1/logs/system.log'\n >> begin
captured logging << \ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-5ohWPV\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\ndtest: DEBUG: Starting cluster with 3 nodes.\n- >>
end captured logging << -"
Inet address 127.0.0.3:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback alias
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-5ohWPV
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Starting cluster with 3 nodes.
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/replace_address_test.py", line 307, in
replace_nonexistent_node_test
self._setup(n=3)
File "/home/cassandra/cassandra-dtest/replace_address_test.py", line 63, in
_setup
self.cluster.start()
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
389, in start
common.assert_socket_available(itf)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/common.py", line
519, in assert_socket_available
raise UnavailableSocketError("Inet address %s:%s is not available: %s; a
cluster may already be running or you may need to add the loopback alias" %
(addr, port, msg))
"Inet address 127.0.0.3:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback
alias\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-5ohWPV\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\ndtest: DEBUG: Starting cluster with 3 nodes.\n- >>
end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CASSANDRA-14034) repair_parent_table_test - repair_tests.repair_test.TestRepairDataSystemTable fails: Missing: ['127.0.0.3.* now UP']:
Michael Kjellman created CASSANDRA-14034:
Summary: repair_parent_table_test -
repair_tests.repair_test.TestRepairDataSystemTable fails: Missing:
['127.0.0.3.* now UP']:
Key: CASSANDRA-14034
URL: https://issues.apache.org/jira/browse/CASSANDRA-14034
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
repair_parent_table_test - repair_tests.repair_test.TestRepairDataSystemTable
fails: Missing: ['127.0.0.3.* now UP']:
15 Nov 2017 11:25:47 [node1] Missing: ['127.0.0.3.* now UP']:
INFO [main] 2017-11-15 11:22:42,141 YamlConfigura.
See system.log for remainder
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-t8lb86
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 320, in run
self.setUp()
File "/home/cassandra/cassandra-dtest/tools/decorators.py", line 31, in
wrapped_setUp
orig_setUp(obj, *args, **kwargs)
File "/home/cassandra/cassandra-dtest/repair_tests/repair_test.py", line
1248, in setUp
self.cluster.populate(5).start(wait_for_binary_proto=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
428, in start
node.watch_log_for_alive(other_node, from_mark=mark)
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 520, in watch_log_for_alive
self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
filename=filename)
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 488, in watch_log_for
raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " ["
+ self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" +
reads[:50] + ".\nSee {} for remainder".format(filename))
"15 Nov 2017 11:25:47 [node1] Missing: ['127.0.0.3.* now UP']:\nINFO [main]
2017-11-15 11:22:42,141 YamlConfigura.\nSee system.log for
remainder\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-t8lb86\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14033) putget_snappy_test - putget_test.TestPutGet fails
Michael Kjellman created CASSANDRA-14033:
Summary: putget_snappy_test - putget_test.TestPutGet fails
Key: CASSANDRA-14033
URL: https://issues.apache.org/jira/browse/CASSANDRA-14033
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
putget_snappy_test - putget_test.TestPutGet fails
errors={'127.0.0.3': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.3
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-ewffmO
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'memtable_allocation_type': 'offheap_objects',
'num_tokens': '256',
'phi_convict_threshold': 5}
cassandra.cluster: INFO: New Cassandra host
discovered
cassandra.cluster: INFO: New Cassandra host
discovered
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/putget_test.py", line 23, in
putget_snappy_test
self._putget(compression="Snappy")
File "/home/cassandra/cassandra-dtest/putget_test.py", line 39, in _putget
create_cf(session, 'cf', compression=compression)
File "/home/cassandra/cassandra-dtest/dtest.py", line 723, in create_cf
session.execute(query)
File "cassandra/cluster.py", line 2122, in cassandra.cluster.Session.execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state).result()
File "cassandra/cluster.py", line 3982, in
cassandra.cluster.ResponseFuture.result
raise self._final_exception
"errors={'127.0.0.3': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.3\n
>> begin captured logging << \ndtest: DEBUG: cluster ccm
directory: /tmp/dtest-ewffmO\ndtest: DEBUG: Done setting configuration
options:\n{ 'initial_token': None,\n'memtable_allocation_type':
'offheap_objects',\n'num_tokens': '256',\n'phi_convict_threshold':
5}\ncassandra.cluster: INFO: New Cassandra host
discovered\ncassandra.cluster: INFO: New Cassandra host discovered\n- >> end captured logging <<
-"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14032) netstats_test - jmx_test.TestJMX fails
Michael Kjellman created CASSANDRA-14032:
Summary: netstats_test - jmx_test.TestJMX fails
Key: CASSANDRA-14032
URL: https://issues.apache.org/jira/browse/CASSANDRA-14032
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
netstats_test - jmx_test.TestJMX fails
[Errno 2] No such file or directory:
'/tmp/dtest-0q58I3/test/node1/logs/system.log'
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-IxAadk
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: cluster ccm directory: /tmp/dtest-0q58I3
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 358, in run
self.tearDown()
File "/home/cassandra/cassandra-dtest/dtest.py", line 597, in tearDown
if not self.allow_log_errors and self.check_logs_for_errors():
File "/home/cassandra/cassandra-dtest/dtest.py", line 614, in
check_logs_for_errors
['\n'.join(msg) for msg in node.grep_log_for_errors()]))
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 386, in grep_log_for_errors
return self.grep_log_for_errors_from(seek_start=getattr(self, 'error_mark',
0))
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 389, in grep_log_for_errors_from
with open(os.path.join(self.get_path(), 'logs', filename)) as f:
"[Errno 2] No such file or directory:
'/tmp/dtest-0q58I3/test/node1/logs/system.log'\n >> begin
captured logging << \ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-IxAadk\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\ndtest: DEBUG: Done setting configuration options:\n{ 'initial_token':
None,\n'num_tokens': '32',\n'phi_convict_threshold': 5,\n
'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms':
1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\ndtest: DEBUG: cluster ccm directory: /tmp/dtest-0q58I3\ndtest: DEBUG:
Done setting configuration options:\n{ 'initial_token': None,\n
'num_tokens': '32',\n'phi_convict_threshold': 5,\n
'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms':
1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
Inet address 127.0.0.3:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback alias
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-IxAadk
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: cluster ccm directory: /tmp/dtest-0q58I3
dtest: DEBUG: Done setting
[jira] [Created] (CASSANDRA-14031) large_compaction_warning_test - compaction_test.TestCompaction_with_SizeTieredCompactionStrategy fails: errors={'127.0.0.1': 'Client request timeout
Michael Kjellman created CASSANDRA-14031:
Summary: large_compaction_warning_test -
compaction_test.TestCompaction_with_SizeTieredCompactionStrategy fails:
errors={'127.0.0.1': 'Client request timeout
Key: CASSANDRA-14031
URL: https://issues.apache.org/jira/browse/CASSANDRA-14031
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
large_compaction_warning_test -
compaction_test.TestCompaction_with_SizeTieredCompactionStrategy fails:
errors={'127.0.0.1': 'Client request timeout
errors={'127.0.0.1': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.1
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-Ulg9O1
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/compaction_test.py", line 344, in
large_compaction_warning_test
session.execute("CREATE TABLE large(userid text PRIMARY KEY, properties
map) with compression = {}")
File "cassandra/cluster.py", line 2122, in cassandra.cluster.Session.execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state).result()
File "cassandra/cluster.py", line 3982, in
cassandra.cluster.ResponseFuture.result
raise self._final_exception
"errors={'127.0.0.1': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.1\n
>> begin captured logging << \ndtest: DEBUG: cluster ccm
directory: /tmp/dtest-Ulg9O1\ndtest: DEBUG: Done setting configuration
options:\n{ 'initial_token': None,\n'num_tokens': '32',\n
'phi_convict_threshold': 5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14030) disk_balance_bootstrap_test - disk_balance_test.TestDiskBalance fails: Missing: ['127.0.0.5.* now UP']:
Michael Kjellman created CASSANDRA-14030:
Summary: disk_balance_bootstrap_test -
disk_balance_test.TestDiskBalance fails: Missing: ['127.0.0.5.* now UP']:
Key: CASSANDRA-14030
URL: https://issues.apache.org/jira/browse/CASSANDRA-14030
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
disk_balance_bootstrap_test - disk_balance_test.TestDiskBalance fails: Missing:
['127.0.0.5.* now UP']:
15 Nov 2017 11:28:03 [node4] Missing: ['127.0.0.5.* now UP']:
.
See system.log for remainder
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-NZzhNb
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/disk_balance_test.py", line 44, in
disk_balance_bootstrap_test
node5.start(wait_for_binary_proto=True)
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 706, in start
node.watch_log_for_alive(self, from_mark=mark)
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 520, in watch_log_for_alive
self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
filename=filename)
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 488, in watch_log_for
raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " ["
+ self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" +
reads[:50] + ".\nSee {} for remainder".format(filename))
"15 Nov 2017 11:28:03 [node4] Missing: ['127.0.0.5.* now UP']:\n.\nSee
system.log for remainder\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-NZzhNb\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14029) counter_leader_with_partial_view_test-novnodes - counter_tests.TestCounters fails: Error starting node2
Michael Kjellman created CASSANDRA-14029:
Summary: counter_leader_with_partial_view_test-novnodes -
counter_tests.TestCounters fails: Error starting node2
Key: CASSANDRA-14029
URL: https://issues.apache.org/jira/browse/CASSANDRA-14029
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
counter_leader_with_partial_view_test-novnodes - counter_tests.TestCounters
fails: Error starting node2
Error starting node2.
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-S1sTss
dtest: DEBUG: Done setting configuration options:
{ 'num_tokens': None,
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/counter_tests.py", line 95, in
counter_leader_with_partial_view_test
cluster.start(wait_for_binary_proto=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
423, in start
raise NodeError("Error starting {0}.".format(node.name), p)
"Error starting node2.\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-S1sTss\ndtest: DEBUG: Done setting configuration options:\n{
'num_tokens': None,\n'phi_convict_threshold': 5,\n
'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms':
1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14028) counter_leader_with_partial_view_test-novnodes - counter_tests.TestCounters fails
Michael Kjellman created CASSANDRA-14028:
Summary: counter_leader_with_partial_view_test-novnodes -
counter_tests.TestCounters fails
Key: CASSANDRA-14028
URL: https://issues.apache.org/jira/browse/CASSANDRA-14028
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
Unexpected error in log, see stdout
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-S1sTss
dtest: DEBUG: Done setting configuration options:
{ 'num_tokens': None,
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 358, in run
self.tearDown()
File "/home/cassandra/cassandra-dtest/dtest.py", line 599, in tearDown
raise AssertionError('Unexpected error in log, see stdout')
"Unexpected error in log, see stdout\n >> begin captured
logging << \ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-S1sTss\ndtest: DEBUG: Done setting configuration options:\n{
'num_tokens': None,\n'phi_convict_threshold': 5,\n
'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms':
1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14026) Dtest fails ContextSuite context=LWTTester>:setup - net address 127.0.0.3:9042 is not available: [Errno 98] Address already in use;
Michael Kjellman created CASSANDRA-14026:
Summary: Dtest fails ContextSuite context=LWTTester>:setup - net
address 127.0.0.3:9042 is not available: [Errno 98] Address already in use;
Key: CASSANDRA-14026
URL: https://issues.apache.org/jira/browse/CASSANDRA-14026
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
ContextSuite context=LWTTester>:setup - > begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-IxAadk
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/home/cassandra/env/local/lib/python2.7/site-packages/nose/suite.py",
line 209, in run
self.setUp()
File "/home/cassandra/env/local/lib/python2.7/site-packages/nose/suite.py",
line 292, in setUp
self.setupContext(ancestor)
File "/home/cassandra/env/local/lib/python2.7/site-packages/nose/suite.py",
line 315, in setupContext
try_run(context, names)
File "/home/cassandra/env/local/lib/python2.7/site-packages/nose/util.py",
line 471, in try_run
return func()
File "/home/cassandra/cassandra-dtest/dtest.py", line 1002, in setUpClass
cls.initialize_cluster()
File "/home/cassandra/cassandra-dtest/dtest.py", line 1060, in
initialize_cluster
cls.post_initialize_cluster()
File "/home/cassandra/cassandra-dtest/cql_tests.py", line 1232, in
post_initialize_cluster
cluster.start(wait_for_binary_proto=True)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
389, in start
common.assert_socket_available(itf)
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/common.py", line
519, in assert_socket_available
raise UnavailableSocketError("Inet address %s:%s is not available: %s; a
cluster may already be running or you may need to add the loopback alias" %
(addr, port, msg))
"Inet address 127.0.0.3:9042 is not available: [Errno 98] Address already in
use; a cluster may already be running or you may need to add the loopback
alias\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-IxAadk\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\ndtest: DEBUG: Done setting configuration options:\n{ 'initial_token':
None,\n'num_tokens': '32',\n'phi_convict_threshold': 5,\n
'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms':
1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14027) consistent_range_movement_false_with_rf1_should_succeed_test - bootstrap_test.TestBootstrap
Michael Kjellman created CASSANDRA-14027:
Summary:
consistent_range_movement_false_with_rf1_should_succeed_test -
bootstrap_test.TestBootstrap
Key: CASSANDRA-14027
URL: https://issues.apache.org/jira/browse/CASSANDRA-14027
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
15 Nov 2017 11:22:19 [node2] Timed out waiting for
/tmp/dtest-3SeOAb/test/node2/logs/system.log to be created.
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-3SeOAb
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'num_tokens': '32',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/bootstrap_test.py", line 239, in
consistent_range_movement_false_with_rf1_should_succeed_test
self._bootstrap_test_with_replica_down(False, rf=1)
File "/home/cassandra/cassandra-dtest/bootstrap_test.py", line 261, in
_bootstrap_test_with_replica_down
cluster.start()
File
"/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/cluster.py", line
415, in start
node.watch_log_for(start_message, timeout=kwargs.get('timeout',60),
process=p, verbose=verbose, from_mark=mark)
File "/home/cassandra/env/local/lib/python2.7/site-packages/ccmlib/node.py",
line 449, in watch_log_for
raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + " ["
+ self.name + "] Timed out waiting for {} to be created.".format(log_file))
"15 Nov 2017 11:22:19 [node2] Timed out waiting for
/tmp/dtest-3SeOAb/test/node2/logs/system.log to be
created.\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-3SeOAb\ndtest: DEBUG: Done setting configuration options:\n{
'initial_token': None,\n'num_tokens': '32',\n'phi_convict_threshold':
5,\n'range_request_timeout_in_ms': 1,\n
'read_request_timeout_in_ms': 1,\n'request_timeout_in_ms': 1,\n
'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
1}\n- >> end captured logging << -"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14025) test_simple_strategy_counters - consistency_test.TestAccuracy always fails code=2000 [Syntax error in CQL query] message="line 7:14 mismatched input 'AND' expecting
Michael Kjellman created CASSANDRA-14025:
Summary: test_simple_strategy_counters -
consistency_test.TestAccuracy always fails code=2000 [Syntax error in CQL
query] message="line 7:14 mismatched input 'AND' expecting EOF (... text, age
int ) [AND]...)
Key: CASSANDRA-14025
URL: https://issues.apache.org/jira/browse/CASSANDRA-14025
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
test_simple_strategy_counters - consistency_test.TestAccuracy always fails
code=2000 [Syntax error in CQL query] message="line 7:14 mismatched input 'AND'
expecting EOF (... text,age int) [AND]...)
>> begin captured logging <<
dtest: DEBUG: cluster ccm directory: /tmp/dtest-dYXpHm
dtest: DEBUG: Done setting configuration options:
{ 'initial_token': None,
'memtable_allocation_type': 'offheap_objects',
'num_tokens': '256',
'phi_convict_threshold': 5,
'range_request_timeout_in_ms': 1,
'read_request_timeout_in_ms': 1,
'request_timeout_in_ms': 1,
'truncate_request_timeout_in_ms': 1,
'write_request_timeout_in_ms': 1}
dtest: DEBUG: Testing single dc, counters
dtest: DEBUG: Changing snitch for single dc case
cassandra.cluster: INFO: New Cassandra host discovered
cassandra.cluster: INFO: New Cassandra host discovered
- >> end captured logging << -
File "/usr/lib/python2.7/unittest/case.py", line 329, in run
testMethod()
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 704, in
test_simple_strategy_counters
self._run_test_function_in_parallel(TestAccuracy.Validation.validate_counters,
[self.nodes], [self.rf], combinations)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 535, in
_run_test_function_in_parallel
self._start_cluster(save_sessions=True,
requires_local_reads=requires_local_reads)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 147, in
_start_cluster
self.create_tables(session, requires_local_reads)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 156, in
create_tables
self.create_users_table(session, requires_local_reads)
File "/home/cassandra/cassandra-dtest/consistency_test.py", line 178, in
create_users_table
session.execute(create_cmd)
File "cassandra/cluster.py", line 2122, in cassandra.cluster.Session.execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state).result()
File "cassandra/cluster.py", line 3982, in
cassandra.cluster.ResponseFuture.result
raise self._final_exception
'\n >> begin captured logging <<
\ndtest: DEBUG: cluster ccm directory:
/tmp/dtest-dYXpHm\ndtest: DEBUG: Done setting configuration options:\n{
\'initial_token\': None,\n\'memtable_allocation_type\':
\'offheap_objects\',\n\'num_tokens\': \'256\',\n
\'phi_convict_threshold\': 5,\n\'range_request_timeout_in_ms\': 1,\n
\'read_request_timeout_in_ms\': 1,\n\'request_timeout_in_ms\': 1,\n
\'truncate_request_timeout_in_ms\': 1,\n
\'write_request_timeout_in_ms\': 1}\ndtest: DEBUG: Testing single dc,
counters\ndtest: DEBUG: Changing snitch for single dc case\ncassandra.cluster:
INFO: New Cassandra host discovered\ncassandra.cluster:
INFO: New Cassandra host
discovered\n- >> end captured logging <<
-'
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14024) secondary_indexes_test#test_query_indexes_with_vnodes always fails on trunk due to "WITH COMPACT STORAGE"
[
https://issues.apache.org/jira/browse/CASSANDRA-14024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254315#comment-16254315
]
Michael Kjellman commented on CASSANDRA-14024:
--
https://github.com/mkjellman/cassandra-dtest/commit/e517ed1dd9702507ae19da1a3bd49f137d3a6eed
> secondary_indexes_test#test_query_indexes_with_vnodes always fails on trunk
> due to "WITH COMPACT STORAGE"
> -
>
> Key: CASSANDRA-14024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14024
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>
> secondary_indexes_test#test_query_indexes_with_vnodes always fails on trunk
> due to "WITH COMPACT STORAGE"
> Most likely just needs @since("2.0", max_version="3.X")... looks like other
> ones got this annotation added but this one was missed?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14024) secondary_indexes_test#test_query_indexes_with_vnodes always fails on trunk due to "WITH COMPACT STORAGE"
Michael Kjellman created CASSANDRA-14024:
Summary: secondary_indexes_test#test_query_indexes_with_vnodes
always fails on trunk due to "WITH COMPACT STORAGE"
Key: CASSANDRA-14024
URL: https://issues.apache.org/jira/browse/CASSANDRA-14024
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
secondary_indexes_test#test_query_indexes_with_vnodes always fails on trunk due
to "WITH COMPACT STORAGE"
Most likely just needs @since("2.0", max_version="3.X")... looks like other
ones got this annotation added but this one was missed?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14022) Multiple tests failing erroneously due to regex match on "error" on Cluster.__init__ deprecation contact_points
[
https://issues.apache.org/jira/browse/CASSANDRA-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254311#comment-16254311
]
Michael Kjellman commented on CASSANDRA-14022:
--
Looking at the tests, all the keyspaces are created with SimpleStrategy so i
don't know how this would ever have worked.
> Multiple tests failing erroneously due to regex match on "error" on
> Cluster.__init__ deprecation contact_points
> ---
>
> Key: CASSANDRA-14022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14022
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>
> Multiple tests failing erroneously due to regex match on "error" on
> Cluster.__init__ deprecation contact_points
> WARNING: Cluster.__init__ called with contact_points specified, but
> load-balancing policies are not specified in some ExecutionProfiles. In the
> next major version, this will raise an error; please specify a load-balancing
> policy. (contact_points = ['127.0.0.1'], EPs without explicit LBPs =
> ('EXEC_PROFILE_DEFAULT',))\ncassandra.policies:
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14023) add_dc_after_mv_network_replication_test - materialized_views_test.TestMaterializedViews fails due to invalid datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-14023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254313#comment-16254313
]
Michael Kjellman commented on CASSANDRA-14023:
--
Looking at the tests, all the keyspaces are created with SimpleStrategy so i
don't know how this would ever have worked.
> add_dc_after_mv_network_replication_test -
> materialized_views_test.TestMaterializedViews fails due to invalid datacenter
>
>
> Key: CASSANDRA-14023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14023
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>
> add_dc_after_mv_network_replication_test -
> materialized_views_test.TestMaterializedViews always fails due to:
> message="Unrecognized strategy option {dc2} passed to NetworkTopologyStrategy
> for keyspace ks">
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-14022) Multiple tests failing erroneously due to regex match on "error" on Cluster.__init__ deprecation contact_points
[
https://issues.apache.org/jira/browse/CASSANDRA-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Kjellman updated CASSANDRA-14022:
-
Comment: was deleted
(was: Looking at the tests, all the keyspaces are created with SimpleStrategy
so i don't know how this would ever have worked.)
> Multiple tests failing erroneously due to regex match on "error" on
> Cluster.__init__ deprecation contact_points
> ---
>
> Key: CASSANDRA-14022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14022
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>
> Multiple tests failing erroneously due to regex match on "error" on
> Cluster.__init__ deprecation contact_points
> WARNING: Cluster.__init__ called with contact_points specified, but
> load-balancing policies are not specified in some ExecutionProfiles. In the
> next major version, this will raise an error; please specify a load-balancing
> policy. (contact_points = ['127.0.0.1'], EPs without explicit LBPs =
> ('EXEC_PROFILE_DEFAULT',))\ncassandra.policies:
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14023) add_dc_after_mv_network_replication_test - materialized_views_test.TestMaterializedViews fails due to invalid datacenter
Michael Kjellman created CASSANDRA-14023: Summary: add_dc_after_mv_network_replication_test - materialized_views_test.TestMaterializedViews fails due to invalid datacenter Key: CASSANDRA-14023 URL: https://issues.apache.org/jira/browse/CASSANDRA-14023 Project: Cassandra Issue Type: Bug Components: Testing Reporter: Michael Kjellman add_dc_after_mv_network_replication_test - materialized_views_test.TestMaterializedViews always fails due to: -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14022) Multiple tests failing erroneously due to regex match on "error" on Cluster.__init__ deprecation contact_points
[
https://issues.apache.org/jira/browse/CASSANDRA-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254307#comment-16254307
]
Michael Kjellman commented on CASSANDRA-14022:
--
https://github.com/mkjellman/cassandra-dtest/commit/0560b95e1e8ccdd18f7dd79e03735f4d47bdd48f
> Multiple tests failing erroneously due to regex match on "error" on
> Cluster.__init__ deprecation contact_points
> ---
>
> Key: CASSANDRA-14022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14022
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>
> Multiple tests failing erroneously due to regex match on "error" on
> Cluster.__init__ deprecation contact_points
> WARNING: Cluster.__init__ called with contact_points specified, but
> load-balancing policies are not specified in some ExecutionProfiles. In the
> next major version, this will raise an error; please specify a load-balancing
> policy. (contact_points = ['127.0.0.1'], EPs without explicit LBPs =
> ('EXEC_PROFILE_DEFAULT',))\ncassandra.policies:
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14022) Multiple tests failing erroneously due to regex match on "error" on Cluster.__init__ deprecation contact_points
Michael Kjellman created CASSANDRA-14022:
Summary: Multiple tests failing erroneously due to regex match on
"error" on Cluster.__init__ deprecation contact_points
Key: CASSANDRA-14022
URL: https://issues.apache.org/jira/browse/CASSANDRA-14022
Project: Cassandra
Issue Type: Bug
Components: Testing
Reporter: Michael Kjellman
Multiple tests failing erroneously due to regex match on "error" on
Cluster.__init__ deprecation contact_points
WARNING: Cluster.__init__ called with contact_points specified, but
load-balancing policies are not specified in some ExecutionProfiles. In the
next major version, this will raise an error; please specify a load-balancing
policy. (contact_points = ['127.0.0.1'], EPs without explicit LBPs =
('EXEC_PROFILE_DEFAULT',))\ncassandra.policies:
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14021) test_pycodestyle_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh code style errors
[ https://issues.apache.org/jira/browse/CASSANDRA-14021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254303#comment-16254303 ] Michael Kjellman commented on CASSANDRA-14021: -- https://github.com/mkjellman/cassandra/commit/4a7ef7b2b8fd7133af418626ada79b2b6696ad85 > test_pycodestyle_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh code style > errors > - > > Key: CASSANDRA-14021 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14021 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Kjellman > > Once we commit CASSANDRA-14020, we'll need to cleanup all of the errors that > pycodestyle has found to get the test passing -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14021) test_pycodestyle_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh code style errors
Michael Kjellman created CASSANDRA-14021: Summary: test_pycodestyle_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh code style errors Key: CASSANDRA-14021 URL: https://issues.apache.org/jira/browse/CASSANDRA-14021 Project: Cassandra Issue Type: Bug Reporter: Michael Kjellman Once we commit CASSANDRA-14020, we'll need to cleanup all of the errors that pycodestyle has found to get the test passing -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14020) test_pep8_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh: pep8 has been renamed to pycodestyle (GitHub issue #466)
[ https://issues.apache.org/jira/browse/CASSANDRA-14020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16254298#comment-16254298 ] Michael Kjellman commented on CASSANDRA-14020: -- https://github.com/mkjellman/cassandra-dtest/commit/0a5a2b1df8fb2d51102822a00ff15bd70f9b4e63 > test_pep8_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh: pep8 has been > renamed to pycodestyle (GitHub issue #466) > -- > > Key: CASSANDRA-14020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14020 > Project: Cassandra > Issue Type: Bug > Components: Testing >Reporter: Michael Kjellman > > test_pep8_compliance - cqlsh_tests.cqlsh_tests.TestCqlsh always fails due to > us catching a informative warning from the pip8 tool.. looks like we just > need to swap out the usage > /home/cassandra/env/local/lib/python2.7/site-packages/pep8.py:2124: > UserWarning: > pep8 has been renamed to pycodestyle (GitHub issue #466) > Use of the pep8 tool will be removed in a future release. > Please install and use `pycodestyle` instead. > $ pip install pycodestyle > $ pycodestyle ... > '\n\n' -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
