[jira] [Commented] (CASSANDRA-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032223#comment-17032223
]
Sam Tunnicliffe commented on CASSANDRA-15313:
-
{quote}[~samt] would it be possible for you to take a look?{quote}
Sure, but I won't be able to get to it immediately. This will go away with
CASSANDRA-15299, so if it's causing test failures maybe we can {{@Ignore}} the
test for now and I'll come back to it if 15299 gets bumped from 4.0.
> Fix flaky - ChecksummingTransformerTest -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> ---
>
> Key: CASSANDRA-15313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15313-hack.patch
>
>
> During the recent runs, this test appears to be flaky.
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
> corruptionCausesFailure-compression -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> {code:java}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at org.quicktheories.impl.Precursor.(Precursor.java:17)
> at
> org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
> at
> org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
> at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
> at
> org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
> at
> org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
> at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
> at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
> Source)
> at
> org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
> at
> org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.impl.Core.generate(Core.java:150)
> at org.quicktheories.impl.Core.shrink(Core.java:103)
> at org.quicktheories.impl.Core.run(Core.java:39)
> at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
> at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
> at
> org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
> at
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-15556:
Reviewers: Jordan West, Jordan West (was: Jordan West)
Jordan West, Jordan West
Status: Review In Progress (was: Patch Available)
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032249#comment-17032249
]
Jordan West commented on CASSANDRA-15556:
-
Thanks [~dcapwell]. Patch overall looks good a couple comments:
* I think we need to update the dependency in {{lib}} as well.
* Minor nit: any reason I'm missing why the test can't be included in the
existing class (it already has some unit tests)?
Also re:
bq. it has been fixed already for sstables it seems.
I agree they are separate code paths but it looks like we are still using
{{FastDecompressor}} in
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/compress/LZ4Compressor.java#L75
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032249#comment-17032249
]
Jordan West edited comment on CASSANDRA-15556 at 2/7/20 9:39 AM:
-
Thanks [~dcapwell] -- appreciate the benchmarks and new unit test! Patch looks
good overall. A couple comments:
* I think we need to update the dependency in {{lib}} as well.
* Minor nit: any reason I'm missing why the test can't be included in the
existing class (it already has some unit tests)?
Also re:
bq. it has been fixed already for sstables it seems.
I agree they are separate code paths but it looks like we are still using
{{FastDecompressor}} in
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/compress/LZ4Compressor.java#L75
was (Author: jrwest):
Thanks [~dcapwell]. Patch overall looks good a couple comments:
* I think we need to update the dependency in {{lib}} as well.
* Minor nit: any reason I'm missing why the test can't be included in the
existing class (it already has some unit tests)?
Also re:
bq. it has been fixed already for sstables it seems.
I agree they are separate code paths but it looks like we are still using
{{FastDecompressor}} in
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/compress/LZ4Compressor.java#L75
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032254#comment-17032254
]
Jordan West commented on CASSANDRA-15313:
-
If we aren't able to fix it now / are waiting for a future change, can we mark
it as flaky (maybe this JIRA being open is fine) in some way but not @Ignore
it? I think that would more likely ensure we don't forget it -- especially
since its been effective at finding bugs. The test should apply to the code
post-15529 as well.
> Fix flaky - ChecksummingTransformerTest -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> ---
>
> Key: CASSANDRA-15313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15313-hack.patch
>
>
> During the recent runs, this test appears to be flaky.
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
> corruptionCausesFailure-compression -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> {code:java}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at org.quicktheories.impl.Precursor.(Precursor.java:17)
> at
> org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
> at
> org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
> at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
> at
> org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
> at
> org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
> at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
> at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
> Source)
> at
> org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
> at
> org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.impl.Core.generate(Core.java:150)
> at org.quicktheories.impl.Core.shrink(Core.java:103)
> at org.quicktheories.impl.Core.run(Core.java:39)
> at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
> at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
> at
> org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
> at
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032249#comment-17032249
]
Jordan West edited comment on CASSANDRA-15556 at 2/7/20 9:52 AM:
-
Thanks [~dcapwell] -- appreciate the benchmarks and new unit test! Patch looks
good overall. A couple comments:
* I think we need to update the dependency in {{lib}} as well.
* Minor nit: any reason I'm missing why the test can't be included in the
existing class (it already has some unit tests)?
Also re:
bq. it has been fixed already for sstables it seems.
I agree they are separate code paths but it looks like we are still using
{{FastDecompressor}} in
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/compress/LZ4Compressor.java#L75
EDIT: I now see the patch you linked in cassandra-dev slack. But should we be
using a deprecated lz4 function at all?
was (Author: jrwest):
Thanks [~dcapwell] -- appreciate the benchmarks and new unit test! Patch looks
good overall. A couple comments:
* I think we need to update the dependency in {{lib}} as well.
* Minor nit: any reason I'm missing why the test can't be included in the
existing class (it already has some unit tests)?
Also re:
bq. it has been fixed already for sstables it seems.
I agree they are separate code paths but it looks like we are still using
{{FastDecompressor}} in
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/compress/LZ4Compressor.java#L75
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032276#comment-17032276
]
Sam Tunnicliffe commented on CASSANDRA-15313:
-
I wasn't suggesting we close this JIRA, so it would still effectively be marked
flaky and a blocker for 4.0. Marking it {{@Ignore}} would just improve the
signal:noise ratio for builds broken by other things.
> Fix flaky - ChecksummingTransformerTest -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> ---
>
> Key: CASSANDRA-15313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15313-hack.patch
>
>
> During the recent runs, this test appears to be flaky.
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
> corruptionCausesFailure-compression -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> {code:java}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at org.quicktheories.impl.Precursor.(Precursor.java:17)
> at
> org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
> at
> org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
> at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
> at
> org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
> at
> org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
> at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
> at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
> Source)
> at
> org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
> at
> org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.impl.Core.generate(Core.java:150)
> at org.quicktheories.impl.Core.shrink(Core.java:103)
> at org.quicktheories.impl.Core.run(Core.java:39)
> at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
> at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
> at
> org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
> at
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11368) Lists inserts are not truly idempotent
[
https://issues.apache.org/jira/browse/CASSANDRA-11368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032405#comment-17032405
]
Jelmer Kuperus commented on CASSANDRA-11368:
I just observed something similar
{code:java}
BEGIN BATCH
insert into test_1(id, vector, version) values ('3', [0.1, 0.2], 0)
insert into test_1(id, vector, version) values ('3', [0.1, 0.2], 0)
APPLY BATCH;{code}
Will result in
{code:java}
id | vector | version
+--+-
3 | [0.1, 0.2, 0.1, 0.2] | 0{code}
This is highly unexpected. Does this have the same root cause ?
> Lists inserts are not truly idempotent
> --
>
> Key: CASSANDRA-11368
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11368
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Thanh
>Priority: Normal
>
> List of UDT can't be updated properly when using USING TIMESTAMP
> Observe:
> {code}
> cqlsh:t360> CREATE TYPE fullname (
> ... fname text,
> ... lname text
> ... );
> cqlsh:t360> CREATE TABLE users (
> ... id text PRIMARY KEY,
> ... names list>,
> ... phone text
> ... );
> cqlsh:t360> UPDATE users USING TIMESTAMP 1458019725701 SET names = [{ fname:
> 'fname1', lname: 'lname1'},{ fname: 'fname2', lname: 'lname2'},{ fname:
> 'fname3', lname: 'lname3'}] WHERE id='a';
> cqlsh:t360> select * from users;
> id | names | phone
> +--+---
>
> a | [{lname: 'lname1', fname: 'fname1'}, {lname: 'lname2', fname: 'fname2'},
> {lname: 'lname3', fname: 'fname3'}] | null
> (1 rows)
> cqlsh:t360> UPDATE users USING TIMESTAMP 1458019725701 SET names = [{ fname:
> 'fname1', lname: 'lname1'},{ fname: 'fname2', lname: 'lname2'},{ fname:
> 'fname3', lname: 'lname3'}] WHERE id='a';
> cqlsh:t360> select * from users;
> id | names | phone
> +--+---
>
> a | [{lname: 'lname1', fname: 'fname1'}, {lname: 'lname2', fname: 'fname2'},
> {lname: 'lname3', fname: 'fname3'}, {lname: 'lname1', fname: 'fname1'},
> {lname: 'lname2', fname: 'fname2'}, {lname: 'lname3', fname: 'fname3'}] | null
> (1 rows)
> {code}
> => the list doesn't get replaced, it gets appended, which is not the
> expected/desired result
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11368) Lists inserts are not truly idempotent
[
https://issues.apache.org/jira/browse/CASSANDRA-11368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032405#comment-17032405
]
Jelmer Kuperus edited comment on CASSANDRA-11368 at 2/7/20 2:35 PM:
I just observed something similar
{code:java}
BEGIN BATCH
insert into test_1(id, vector, version) values ('3', [0.1, 0.2], 0)
insert into test_1(id, vector, version) values ('3', [0.1, 0.2], 0)
APPLY BATCH;{code}
Will result in
{code:java}
id | vector | version
+--+-
3 | [0.1, 0.2, 0.1, 0.2] | 0{code}
This is highly unexpected. Does this have the same root cause ?
In my case I was able to work around it my making the list frozen (which it
should have been to begin with)
was (Author: jelmer):
I just observed something similar
{code:java}
BEGIN BATCH
insert into test_1(id, vector, version) values ('3', [0.1, 0.2], 0)
insert into test_1(id, vector, version) values ('3', [0.1, 0.2], 0)
APPLY BATCH;{code}
Will result in
{code:java}
id | vector | version
+--+-
3 | [0.1, 0.2, 0.1, 0.2] | 0{code}
This is highly unexpected. Does this have the same root cause ?
> Lists inserts are not truly idempotent
> --
>
> Key: CASSANDRA-11368
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11368
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Thanh
>Priority: Normal
>
> List of UDT can't be updated properly when using USING TIMESTAMP
> Observe:
> {code}
> cqlsh:t360> CREATE TYPE fullname (
> ... fname text,
> ... lname text
> ... );
> cqlsh:t360> CREATE TABLE users (
> ... id text PRIMARY KEY,
> ... names list>,
> ... phone text
> ... );
> cqlsh:t360> UPDATE users USING TIMESTAMP 1458019725701 SET names = [{ fname:
> 'fname1', lname: 'lname1'},{ fname: 'fname2', lname: 'lname2'},{ fname:
> 'fname3', lname: 'lname3'}] WHERE id='a';
> cqlsh:t360> select * from users;
> id | names | phone
> +--+---
>
> a | [{lname: 'lname1', fname: 'fname1'}, {lname: 'lname2', fname: 'fname2'},
> {lname: 'lname3', fname: 'fname3'}] | null
> (1 rows)
> cqlsh:t360> UPDATE users USING TIMESTAMP 1458019725701 SET names = [{ fname:
> 'fname1', lname: 'lname1'},{ fname: 'fname2', lname: 'lname2'},{ fname:
> 'fname3', lname: 'lname3'}] WHERE id='a';
> cqlsh:t360> select * from users;
> id | names | phone
> +--+---
>
> a | [{lname: 'lname1', fname: 'fname1'}, {lname: 'lname2', fname: 'fname2'},
> {lname: 'lname3', fname: 'fname3'}, {lname: 'lname1', fname: 'fname1'},
> {lname: 'lname2', fname: 'fname2'}, {lname: 'lname3', fname: 'fname3'}] | null
> (1 rows)
> {code}
> => the list doesn't get replaced, it gets appended, which is not the
> expected/desired result
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15551) Fix flaky tests org.apache.cassandra.service.MoveTest testStateJumpToNormal and testMoveWithPendingRangesNetworkStrategyRackAwareThirtyNodes
[
https://issues.apache.org/jira/browse/CASSANDRA-15551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032421#comment-17032421
]
Brandon Williams commented on CASSANDRA-15551:
--
I was able to run both of these a few thousand times without failure on java 8.
:(
> Fix flaky tests org.apache.cassandra.service.MoveTest testStateJumpToNormal
> and testMoveWithPendingRangesNetworkStrategyRackAwareThirtyNodes
>
>
> Key: CASSANDRA-15551
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15551
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> testStateJumpToNormal failure was on java 11
> {code}
> java.lang.NullPointerException
> at org.apache.cassandra.gms.Gossiper.getHostId(Gossiper.java:1028)
> at org.apache.cassandra.gms.Gossiper.getHostId(Gossiper.java:1023)
> at
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2513)
> at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2055)
> at org.apache.cassandra.Util.createInitialRing(Util.java:225)
> at
> org.apache.cassandra.service.MoveTest.testStateJumpToNormal(MoveTest.java:935)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> testMoveWithPendingRangesNetworkStrategyRackAwareThirtyNodes failure was on
> java 8
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2174)
> at
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2511)
> at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2055)
> at org.apache.cassandra.Util.createInitialRing(Util.java:225)
> at
> org.apache.cassandra.service.MoveTest.testMoveWithPendingRangesNetworkStrategyRackAwareThirtyNodes(MoveTest.java:199)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11368) Lists inserts are not truly idempotent
[
https://issues.apache.org/jira/browse/CASSANDRA-11368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032446#comment-17032446
]
Russell Spitzer commented on CASSANDRA-11368:
-
This is a combination of batch behavior and collection behavior conflicting.
Batches give all mutations in the batch the same timestamp. List appends work
by doing a tombstone at t-1 from the append.
This means this code
{code}
BEGIN BATCH
insert into test_1(id, vector, version) values ('3', [0.1, 0.2], 0)
insert into test_1(id, vector, version) values ('3', [0.1, 0.2], 0)
APPLY BATCH;
{code}
Translates to
{code}
t-1 -- Delete
t-1 -- Delete
t -- Insert
t -- Insert
{code}
So you end up with the same element twice because what the collection api was
expecting was something more along the lines of
{code}
t - 3 -- Delete
t - 2 -- Insert
t - 1 -- Delete
t - 0 -- Insert
{code}
For more info check out
https://datastax-oss.atlassian.net/browse/SPARKC-545 where we looked into this
issue
> Lists inserts are not truly idempotent
> --
>
> Key: CASSANDRA-11368
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11368
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Thanh
>Priority: Normal
>
> List of UDT can't be updated properly when using USING TIMESTAMP
> Observe:
> {code}
> cqlsh:t360> CREATE TYPE fullname (
> ... fname text,
> ... lname text
> ... );
> cqlsh:t360> CREATE TABLE users (
> ... id text PRIMARY KEY,
> ... names list>,
> ... phone text
> ... );
> cqlsh:t360> UPDATE users USING TIMESTAMP 1458019725701 SET names = [{ fname:
> 'fname1', lname: 'lname1'},{ fname: 'fname2', lname: 'lname2'},{ fname:
> 'fname3', lname: 'lname3'}] WHERE id='a';
> cqlsh:t360> select * from users;
> id | names | phone
> +--+---
>
> a | [{lname: 'lname1', fname: 'fname1'}, {lname: 'lname2', fname: 'fname2'},
> {lname: 'lname3', fname: 'fname3'}] | null
> (1 rows)
> cqlsh:t360> UPDATE users USING TIMESTAMP 1458019725701 SET names = [{ fname:
> 'fname1', lname: 'lname1'},{ fname: 'fname2', lname: 'lname2'},{ fname:
> 'fname3', lname: 'lname3'}] WHERE id='a';
> cqlsh:t360> select * from users;
> id | names | phone
> +--+---
>
> a | [{lname: 'lname1', fname: 'fname1'}, {lname: 'lname2', fname: 'fname2'},
> {lname: 'lname3', fname: 'fname3'}, {lname: 'lname1', fname: 'fname1'},
> {lname: 'lname2', fname: 'fname2'}, {lname: 'lname3', fname: 'fname3'}] | null
> (1 rows)
> {code}
> => the list doesn't get replaced, it gets appended, which is not the
> expected/desired result
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032447#comment-17032447
]
David Capwell commented on CASSANDRA-15556:
---
I’ll have to double check /lib; thought ant would pull it...
I kept it a isolated class just in case it does crash. When the jvm crashes in
CI we loose all test results and only know about the crash.
Is sstable impacted? Unknown and believe not to be as of the Jira I linked.
Should it switch? I rather leave that for another Jira to tackle :)
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032451#comment-17032451
]
David Capwell commented on CASSANDRA-15313:
---
If the argument that everything will be better with that Jira, I’m fine for
now. I am curious why the condition happens but if checksum is done on
compressed data it’s not likely to hit it.
I rather keep the test running. Yes it’s red, yes it’s noise; it’s calling out
a bug that isn’t fixed yet though.
> Fix flaky - ChecksummingTransformerTest -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> ---
>
> Key: CASSANDRA-15313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15313-hack.patch
>
>
> During the recent runs, this test appears to be flaky.
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
> corruptionCausesFailure-compression -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> {code:java}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at org.quicktheories.impl.Precursor.(Precursor.java:17)
> at
> org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
> at
> org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
> at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
> at
> org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
> at
> org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
> at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
> at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
> Source)
> at
> org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
> at
> org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.impl.Core.generate(Core.java:150)
> at org.quicktheories.impl.Core.shrink(Core.java:103)
> at org.quicktheories.impl.Core.run(Core.java:39)
> at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
> at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
> at
> org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
> at
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032453#comment-17032453
]
Alex Petrov commented on CASSANDRA-15556:
-
There's one more issue that is related, attaching.
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032456#comment-17032456
]
Brandon Williams commented on CASSANDRA-15556:
--
bq. I’ll have to double check /lib; thought ant would pull it...
Nope, it's checked in.
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032453#comment-17032453
]
Alex Petrov edited comment on CASSANDRA-15556 at 2/7/20 3:26 PM:
-
There's one more issue that is related: [CASSANDRA-14997] main concern not to
merge was a difference in performance. It's hard to recall all details, but I
remember segfaulting was somehow related to passing expected length. Maybe it's
worth to check/try again.
was (Author: ifesdjeen):
There's one more issue that is related, attaching.
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032507#comment-17032507
]
David Capwell commented on CASSANDRA-15556:
---
Thanks.
so my test ran against the old library; cool. I’ll work to get it fixed and run
against latest
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Make native_transport_max_concurrent_requests_in_bytes updatable
This is an automated email from the ASF dual-hosted git repository.
clohfink pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new da90439 Make native_transport_max_concurrent_requests_in_bytes
updatable
da90439 is described below
commit da90439f0052c3a05aaf6d4268a8c719e10fafde
Author: Jordan West
AuthorDate: Fri Feb 7 08:24:14 2020 -0800
Make native_transport_max_concurrent_requests_in_bytes updatable
Patch by Jordan West; Reviewed by Chris Lohfink CASSANDRA-15519
---
CHANGES.txt| 1 +
.../org/apache/cassandra/net/ResourceLimits.java | 38 -
.../apache/cassandra/service/StorageService.java | 25
.../cassandra/service/StorageServiceMBean.java | 7 +
.../org/apache/cassandra/transport/Server.java | 28
.../InflightRequestPayloadTrackerTest.java | 153 -
6 files changed, 248 insertions(+), 4 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 997d9d0..33a0581 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-alpha4
+ * Make native_transport_max_concurrent_requests_in_bytes updatable
(CASSANDRA-15519)
* Cleanup and improvements to IndexInfo/ColumnIndex (CASSANDRA-15469)
* Potential Overflow in DatabaseDescriptor Functions That Convert Between
KB/MB & Bytes (CASSANDRA-15470)
4.0-alpha3
diff --git a/src/java/org/apache/cassandra/net/ResourceLimits.java
b/src/java/org/apache/cassandra/net/ResourceLimits.java
index f8d24d7..4c97c2a 100644
--- a/src/java/org/apache/cassandra/net/ResourceLimits.java
+++ b/src/java/org/apache/cassandra/net/ResourceLimits.java
@@ -36,6 +36,20 @@ public abstract class ResourceLimits
long limit();
/**
+ * Sets the total amount of permits represented by this {@link Limit}
- the capacity
+ *
+ * If the old limit has been reached and the new limit is large enough
to allow for more
+ * permits to be aqcuired, subsequent calls to {@link #allocate(long)}
or {@link #tryAllocate(long)}
+ * will succeed.
+ *
+ * If the new limit is lower than the current amount of allocated
permits then subsequent calls
+ * to {@link #allocate(long)} or {@link #tryAllocate(long)} will block
or fail respectively.
+ *
+ * @return the old limit
+ */
+long setLimit(long newLimit);
+
+/**
* @return remaining, unallocated permit amount
*/
long remaining();
@@ -73,7 +87,9 @@ public abstract class ResourceLimits
*/
public static class Concurrent implements Limit
{
-private final long limit;
+private volatile long limit;
+private static final AtomicLongFieldUpdater limitUpdater =
+AtomicLongFieldUpdater.newUpdater(Concurrent.class, "limit");
private volatile long using;
private static final AtomicLongFieldUpdater usingUpdater =
@@ -89,6 +105,16 @@ public abstract class ResourceLimits
return limit;
}
+public long setLimit(long newLimit)
+{
+long oldLimit;
+do {
+oldLimit = limit;
+} while (!limitUpdater.compareAndSet(this, oldLimit, newLimit));
+
+return oldLimit;
+}
+
public long remaining()
{
return limit - using;
@@ -139,7 +165,7 @@ public abstract class ResourceLimits
*/
static class Basic implements Limit
{
-private final long limit;
+private long limit;
private long using;
Basic(long limit)
@@ -152,6 +178,14 @@ public abstract class ResourceLimits
return limit;
}
+public long setLimit(long newLimit)
+{
+long oldLimit = limit;
+limit = newLimit;
+
+return oldLimit;
+}
+
public long remaining()
{
return limit - using;
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 6dd5d37..aa03aea 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -96,6 +96,7 @@ import org.apache.cassandra.schema.ViewMetadata;
import org.apache.cassandra.streaming.*;
import org.apache.cassandra.tracing.TraceKeyspace;
import org.apache.cassandra.transport.ProtocolVersion;
+import org.apache.cassandra.transport.Server;
import org.apache.cassandra.utils.*;
import org.apache.cassandra.utils.logging.LoggingSupportFactory;
import org.apache.cassandra.utils.progress.ProgressEvent;
@@ -5447,6 +5448,30 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
logger.info("Setting corrupted tombstone strategy to {}", strategy);
}
+@Overr
[jira] [Updated] (CASSANDRA-15519) Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15519: -- Source Control Link: https://github.com/apache/cassandra/commit/da90439f0052c3a05aaf6d4268a8c719e10fafde Resolution: Fixed Status: Resolved (was: Ready to Commit) > Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at > runtime > - > > Key: CASSANDRA-15519 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15519 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config, Messaging/Client >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-15013 added configurable global and per endpoint limits on the > number of in flight requests, measured in bytes. During times when the > cluster is overloaded, it can be useful to change this setting without having > to restart the Cassandra process. Changing the limits should affect all > existing and new connections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15527) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testCrossSSTableQueries
[
https://issues.apache.org/jira/browse/CASSANDRA-15527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032524#comment-17032524
]
Ekaterina Dimitrova commented on CASSANDRA-15527:
-
Last update: Running testConcurrentMemtableReadsAndWrites on ubuntu VM
reproduced the failure immediately...
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest
> testCrossSSTableQueries
> ---
>
> Key: CASSANDRA-15527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15527
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15527.txt
>
>
> {code}
> junit.framework.AssertionFailedError: [key13, key2977, key2978, key2979,
> key2980, key2982, key2983, key2984, key2985, key6]
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testCrossSSTableQueries(SASIIndexTest.java:340)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testCrossSSTableQueries(SASIIndexTest.java:286)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032117#comment-17032117
]
David Capwell edited comment on CASSANDRA-15556 at 2/7/20 5:47 PM:
---
With the patch (without jar upgrade)
{code}
BenchmarkMode Cnt
ScoreError Units
ChecksummingTransformerLz4.decompresLargeBlob thrpt 16
3033.525 ± 46.975 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishASCII thrpt 16
10,349,596.715 ± 904,951.399 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishUtf8 thrpt 16
10,687,989.427 ± 595,770.939 ops/s
{code}
With the patch (with jar upgrade)
{code}
BenchmarkMode Cnt
ScoreError Units
ChecksummingTransformerLz4.decompresLargeBlob thrpt 16
4554.158 ±136.973 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishASCII thrpt 16
10,954,513.427 ± 169,683.412 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishUtf8 thrpt 16
10,843,273.039 ± 338,583.588 ops/s
{code}
Without the patch
{code}
BenchmarkMode Cnt
ScoreError Units
ChecksummingTransformerLz4.decompresLargeBlob thrpt 16
2960.954 ±149.584 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishASCII thrpt 16
10,273,136.182 ± 436,391.068 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishUtf8 thrpt 16
10,692,302.907 ± 337,789.609 ops/s
{code}
At least with the samples I created, there isn't a real difference between this
patch (which doesn't crash) and previous
was (Author: dcapwell):
With the patch
{code}
BenchmarkMode Cnt
ScoreError Units
ChecksummingTransformerLz4.decompresLargeBlob thrpt 16
3033.525 ± 46.975 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishASCII thrpt 16
10,349,596.715 ± 904,951.399 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishUtf8 thrpt 16
10,687,989.427 ± 595,770.939 ops/s
{code}
Without the patch
{code}
BenchmarkMode Cnt
ScoreError Units
ChecksummingTransformerLz4.decompresLargeBlob thrpt 16
2960.954 ±149.584 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishASCII thrpt 16
10,273,136.182 ± 436,391.068 ops/s
ChecksummingTransformerLz4.decompresSsmallEnglishUtf8 thrpt 16
10,692,302.907 ± 337,789.609 ops/s
{code}
At least with the samples I created, there isn't a real difference between this
patch (which doesn't crash) and previous
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15527) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testCrossSSTableQueries
[
https://issues.apache.org/jira/browse/CASSANDRA-15527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032561#comment-17032561
]
David Capwell commented on CASSANDRA-15527:
---
YES! IM NOT CRAZY! =D
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest
> testCrossSSTableQueries
> ---
>
> Key: CASSANDRA-15527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15527
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15527.txt
>
>
> {code}
> junit.framework.AssertionFailedError: [key13, key2977, key2978, key2979,
> key2980, key2982, key2983, key2984, key2985, key6]
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testCrossSSTableQueries(SASIIndexTest.java:340)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testCrossSSTableQueries(SASIIndexTest.java:286)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15526) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testConcurrentMemtableReadsAndWrites
[
https://issues.apache.org/jira/browse/CASSANDRA-15526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032574#comment-17032574
]
Ekaterina Dimitrova commented on CASSANDRA-15526:
-
[~jrwest] , are you looking into this one? I see it unassigned so I wasn't
sure.
As I said in CASSANDRA-15527, on Ubuntu VM I am able to reproduce this one.
Still no success with the other two reported by [~dcapwell] so I think his
point that this one might be the main trouble maker is a valid assumption to
start with.
Do you want me to look into it?
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest
> testConcurrentMemtableReadsAndWrites
>
>
> Key: CASSANDRA-15526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15526
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.index.sasi.utils.RangeIterator.(RangeIterator.java:46)
> at
> org.apache.cassandra.index.sasi.memory.KeyRangeIterator.(KeyRangeIterator.java:42)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex$ConcurrentTrie.search(TrieMemIndex.java:150)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex.search(TrieMemIndex.java:102)
> at
> org.apache.cassandra.index.sasi.memory.IndexMemtable.search(IndexMemtable.java:70)
> at
> org.apache.cassandra.index.sasi.conf.ColumnIndex.searchMemtable(ColumnIndex.java:138)
> at org.apache.cassandra.index.sasi.TermIterator.build(TermIterator.java:91)
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndexes(QueryController.java:145)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:434)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.analyze(QueryPlan.java:57)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.execute(QueryPlan.java:68)
> at
> org.apache.cassandra.index.sasi.SASIIndex.lambda$searcherFor$2(SASIIndex.java:301)
> at org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:455)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getIndexed(SASIIndexTest.java:2576)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getPaged(SASIIndexTest.java:2537)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testConcurrentMemtableReadsAndWrites(SASIIndexTest.java:1108)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13810) Overload because of hint pressure + MVs
[
https://issues.apache.org/jira/browse/CASSANDRA-13810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-13810:
---
Bug Category: Parent values: Availability(12983)Level 1 values:
Unavailable(12994)
Fix Version/s: 4.x
3.11.x
3.0.x
Severity: Critical (was: Normal)
> Overload because of hint pressure + MVs
> ---
>
> Key: CASSANDRA-13810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13810
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Tom van der Woerdt
>Priority: Urgent
> Labels: materializedviews
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Cluster setup: 3 DCs, 20 Cassandra nodes each, all 3.0.14, with approx. 200GB
> data per machine. Many tables have MVs associated.
> During some maintenance we did a rolling restart of all nodes in the cluster.
> This caused a buildup of hints/batches, as expected. Most nodes came back
> just fine, except for two nodes.
> These two nodes came back with a loadavg of >100, and 'nodetool tpstats'
> showed a million (not exaggerating) MutationStage tasks per second(!). It was
> clear that these were mostly (all?) mutations coming from hints, as indicated
> by thousands of log entries per second in debug.log :
> {noformat}
> DEBUG [SharedPool-Worker-107] 2017-08-27 13:16:51,098 HintVerbHandler.java:95
> - Failed to apply hint
> java.util.concurrent.CompletionException:
> org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out -
> received only 0 responses.
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:308)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.uniAccept(CompletableFuture.java:647)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:632)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:1977)
> ~[na:1.8.0_144]
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:481)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.db.Keyspace.lambda$applyInternal$0(Keyspace.java:495)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_144]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_144]
> Caused by: org.apache.cassandra.exceptions.WriteTimeoutException: Operation
> timed out - received only 0 responses.
> ... 6 common frames omitted
> {noformat}
> After reading the relevant code, it seems that a hint is considered
> droppable, and in the mutation path when the table contains a MV and the lock
> fails to acquire and the mutation is droppable, it throws a WTE without
> waiting until the timeout expires. This explains why Cassandra is able to
> process a million mutations per second without actually considering them
> 'dropped' in the 'nodetool tpstats' output.
> I managed to recover the two nodes by stopping handoffs on all nodes in the
> cluster and reenabling them one at a time. It's likely that the hint/batchlog
> settings were sub-optimal on this cluster, but I think that the retry
> behavior(?) of hints should be improved as it's hard to express hint
> throughput in kb/s when the mutations can involve MVs.
> More data available upon request -- I'm not sure which bits are relevant and
> which aren't.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15526) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testConcurrentMemtableReadsAndWrites
[
https://issues.apache.org/jira/browse/CASSANDRA-15526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032579#comment-17032579
]
Jordan West commented on CASSANDRA-15526:
-
[~e.dimitrova] any input here is appreciated. I hadn't assigned it to myself
since I wasn't able to look at it immediately (likely early next week I can)
but I have been thinking about it on and off. The challenge, at first glance,
is that {{ConcurrentSkipListSet#size()}} doesn't seem to be reliable (and the
javadoc hints that this is sort of the case -- although I can't explain what I
am seeing in that assert above just yet). The problem is we rely on the count
(which is what we use {{size()}} for) for one important thing in
RangeIntersectionIterator, the heuristic to determine if we use bounce or
lookup.
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest
> testConcurrentMemtableReadsAndWrites
>
>
> Key: CASSANDRA-15526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15526
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.index.sasi.utils.RangeIterator.(RangeIterator.java:46)
> at
> org.apache.cassandra.index.sasi.memory.KeyRangeIterator.(KeyRangeIterator.java:42)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex$ConcurrentTrie.search(TrieMemIndex.java:150)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex.search(TrieMemIndex.java:102)
> at
> org.apache.cassandra.index.sasi.memory.IndexMemtable.search(IndexMemtable.java:70)
> at
> org.apache.cassandra.index.sasi.conf.ColumnIndex.searchMemtable(ColumnIndex.java:138)
> at org.apache.cassandra.index.sasi.TermIterator.build(TermIterator.java:91)
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndexes(QueryController.java:145)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:434)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.analyze(QueryPlan.java:57)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.execute(QueryPlan.java:68)
> at
> org.apache.cassandra.index.sasi.SASIIndex.lambda$searcherFor$2(SASIIndex.java:301)
> at org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:455)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getIndexed(SASIIndexTest.java:2576)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getPaged(SASIIndexTest.java:2537)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testConcurrentMemtableReadsAndWrites(SASIIndexTest.java:1108)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032582#comment-17032582
]
Jordan West commented on CASSANDRA-15313:
-
agreed re: keeping test running [~dcapwell]
> Fix flaky - ChecksummingTransformerTest -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> ---
>
> Key: CASSANDRA-15313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15313-hack.patch
>
>
> During the recent runs, this test appears to be flaky.
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
> corruptionCausesFailure-compression -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> {code:java}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at org.quicktheories.impl.Precursor.(Precursor.java:17)
> at
> org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
> at
> org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
> at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
> at
> org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
> at
> org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
> at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
> at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
> Source)
> at
> org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
> at
> org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.impl.Core.generate(Core.java:150)
> at org.quicktheories.impl.Core.shrink(Core.java:103)
> at org.quicktheories.impl.Core.run(Core.java:39)
> at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
> at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
> at
> org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
> at
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13810) Overload because of hint pressure + MVs
[
https://issues.apache.org/jira/browse/CASSANDRA-13810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032585#comment-17032585
]
Surbhi Gupta commented on CASSANDRA-13810:
--
We are on 3.11.1 and also facing the same issue ...
Even lowering the hinted_handoff_throttle_in_kb to 100 doesn't help much
even when we have hinted handoff in very small amount .
CPU gets 100% busy and load becomes very high but if we truncate the hints then
CPU and Load goes down immediately .
Can it be prioritized ?
Any other suggestion?
> Overload because of hint pressure + MVs
> ---
>
> Key: CASSANDRA-13810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13810
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Tom van der Woerdt
>Priority: Urgent
> Labels: materializedviews
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Cluster setup: 3 DCs, 20 Cassandra nodes each, all 3.0.14, with approx. 200GB
> data per machine. Many tables have MVs associated.
> During some maintenance we did a rolling restart of all nodes in the cluster.
> This caused a buildup of hints/batches, as expected. Most nodes came back
> just fine, except for two nodes.
> These two nodes came back with a loadavg of >100, and 'nodetool tpstats'
> showed a million (not exaggerating) MutationStage tasks per second(!). It was
> clear that these were mostly (all?) mutations coming from hints, as indicated
> by thousands of log entries per second in debug.log :
> {noformat}
> DEBUG [SharedPool-Worker-107] 2017-08-27 13:16:51,098 HintVerbHandler.java:95
> - Failed to apply hint
> java.util.concurrent.CompletionException:
> org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out -
> received only 0 responses.
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:308)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.uniAccept(CompletableFuture.java:647)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:632)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> ~[na:1.8.0_144]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:1977)
> ~[na:1.8.0_144]
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:481)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.db.Keyspace.lambda$applyInternal$0(Keyspace.java:495)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_144]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_144]
> Caused by: org.apache.cassandra.exceptions.WriteTimeoutException: Operation
> timed out - received only 0 responses.
> ... 6 common frames omitted
> {noformat}
> After reading the relevant code, it seems that a hint is considered
> droppable, and in the mutation path when the table contains a MV and the lock
> fails to acquire and the mutation is droppable, it throws a WTE without
> waiting until the timeout expires. This explains why Cassandra is able to
> process a million mutations per second without actually considering them
> 'dropped' in the 'nodetool tpstats' output.
> I managed to recover the two nodes by stopping handoffs on all nodes in the
> cluster and reenabling them one at a time. It's likely that the hint/batchlog
> settings were sub-optimal on this cluster, but I think that the retry
> behavior(?) of hints should be improved as it's hard to express hint
> throughput in kb/s when the mutations can involve MVs.
> More data available upon request -- I'm not sure which bits are relevant and
> which aren't.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032596#comment-17032596
]
David Capwell commented on CASSANDRA-15556:
---
latest test results with the jar
https://circleci.com/workflow-run/e043f111-ea02-4e59-85f7-69d772eefca3
The linked run failed with a test that passes if you run again (ill file the
jira...). I also ran it against dtest and had a small number of failures, but
don't have good history in circle to say if this is normal or not (I really
only use the low version, I didn't touch high).
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15527) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testCrossSSTableQueries
[
https://issues.apache.org/jira/browse/CASSANDRA-15527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032608#comment-17032608
]
Ekaterina Dimitrova commented on CASSANDRA-15527:
-
No, definitely not, I heard such issues happen a lot, unfortunately.
Now the thing is that only that one I can reproduce, the other two not. So I
guess your theory might prove correct and it is good to first start from our
main contributor of troubles -
testConcurrentMemtableReadsAndWrites
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest
> testCrossSSTableQueries
> ---
>
> Key: CASSANDRA-15527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15527
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15527.txt
>
>
> {code}
> junit.framework.AssertionFailedError: [key13, key2977, key2978, key2979,
> key2980, key2982, key2983, key2984, key2985, key6]
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testCrossSSTableQueries(SASIIndexTest.java:340)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testCrossSSTableQueries(SASIIndexTest.java:286)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15526) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testConcurrentMemtableReadsAndWrites
[
https://issues.apache.org/jira/browse/CASSANDRA-15526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032613#comment-17032613
]
Ekaterina Dimitrova commented on CASSANDRA-15526:
-
[~jrwest] Alright, I will try to dig into this now until the rest of the day
and try to come up with some feedback too.
Thanks for sharing your findings, I was in the same direction yesterday but
need to explore more the code.
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest
> testConcurrentMemtableReadsAndWrites
>
>
> Key: CASSANDRA-15526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15526
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.index.sasi.utils.RangeIterator.(RangeIterator.java:46)
> at
> org.apache.cassandra.index.sasi.memory.KeyRangeIterator.(KeyRangeIterator.java:42)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex$ConcurrentTrie.search(TrieMemIndex.java:150)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex.search(TrieMemIndex.java:102)
> at
> org.apache.cassandra.index.sasi.memory.IndexMemtable.search(IndexMemtable.java:70)
> at
> org.apache.cassandra.index.sasi.conf.ColumnIndex.searchMemtable(ColumnIndex.java:138)
> at org.apache.cassandra.index.sasi.TermIterator.build(TermIterator.java:91)
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndexes(QueryController.java:145)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:434)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.analyze(QueryPlan.java:57)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.execute(QueryPlan.java:68)
> at
> org.apache.cassandra.index.sasi.SASIIndex.lambda$searcherFor$2(SASIIndex.java:301)
> at org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:455)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getIndexed(SASIIndexTest.java:2576)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getPaged(SASIIndexTest.java:2537)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testConcurrentMemtableReadsAndWrites(SASIIndexTest.java:1108)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Increment version to 4.0-alpha4
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new a064bbd Increment version to 4.0-alpha4 a064bbd is described below commit a064bbd26418ba59abf892de610718ea165f20ff Author: Mick Semb Wever AuthorDate: Fri Feb 7 21:18:16 2020 +0100 Increment version to 4.0-alpha4 --- CHANGES.txt | 1 + build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 33a0581..e6f967d 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -2,6 +2,7 @@ * Make native_transport_max_concurrent_requests_in_bytes updatable (CASSANDRA-15519) * Cleanup and improvements to IndexInfo/ColumnIndex (CASSANDRA-15469) * Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes (CASSANDRA-15470) + 4.0-alpha3 * Restore monotonic read consistency guarantees for blocking read repair (CASSANDRA-14740) * Separate exceptions for CAS write timeout exceptions caused by contention and unkown result (CASSANDRA-15350) diff --git a/build.xml b/build.xml index 1f782e8..8ea7740 100644 --- a/build.xml +++ b/build.xml @@ -25,7 +25,7 @@ - + https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --git a/debian/changelog b/debian/changelog index bae9e73..c0e206b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (4.0~alpha4) UNRELEASED; urgency=medium + + * New release + + -- Michael Shuler Tue, 29 Oct 2019 16:16:36 -0500 + cassandra (4.0~alpha3) UNRELEASED; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15558) Fix flaky test org.apache.cassandra.db.ReadCommandTest purgeGCableTombstonesBeforeCalculatingDigest
David Capwell created CASSANDRA-15558:
-
Summary: Fix flaky test org.apache.cassandra.db.ReadCommandTest
purgeGCableTombstonesBeforeCalculatingDigest
Key: CASSANDRA-15558
URL: https://issues.apache.org/jira/browse/CASSANDRA-15558
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: David Capwell
https://app.circleci.com/jobs/github/dcapwell/cassandra/502/tests
{code}
junit.framework.AssertionFailedError
at
org.apache.cassandra.db.ReadCommandTest.lambda$purgeGCableTombstonesBeforeCalculatingDigest$5(ReadCommandTest.java:812)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
org.apache.cassandra.db.ReadCommandTest.purgeGCableTombstonesBeforeCalculatingDigest(ReadCommandTest.java:805)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15558) Fix flaky test org.apache.cassandra.db.ReadCommandTest purgeGCableTombstonesBeforeCalculatingDigest
[
https://issues.apache.org/jira/browse/CASSANDRA-15558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15558:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Fix Version/s: 4.0-alpha
Severity: Normal
Status: Open (was: Triage Needed)
> Fix flaky test org.apache.cassandra.db.ReadCommandTest
> purgeGCableTombstonesBeforeCalculatingDigest
> ---
>
> Key: CASSANDRA-15558
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15558
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> https://app.circleci.com/jobs/github/dcapwell/cassandra/502/tests
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.db.ReadCommandTest.lambda$purgeGCableTombstonesBeforeCalculatingDigest$5(ReadCommandTest.java:812)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.cassandra.db.ReadCommandTest.purgeGCableTombstonesBeforeCalculatingDigest(ReadCommandTest.java:805)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032643#comment-17032643
]
David Capwell commented on CASSANDRA-15556:
---
bq. Minor nit: any reason I'm missing why the test can't be included in the
existing class (it already has some unit tests)?
Ill add it to the docs why its this way.
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032646#comment-17032646
]
David Capwell commented on CASSANDRA-15556:
---
[~jrwest] pushed the change to document why the test is isolated.
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15526) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testConcurrentMemtableReadsAndWrites
[
https://issues.apache.org/jira/browse/CASSANDRA-15526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032647#comment-17032647
]
Jordan West commented on CASSANDRA-15526:
-
[~e.dimitrova] forgot to mention that you may find this minor change helpful:
https://github.com/jrwest/cassandra/tree/sasi-concurrent-read-write-failure.
Its the added assertion message above.
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest
> testConcurrentMemtableReadsAndWrites
>
>
> Key: CASSANDRA-15526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15526
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.index.sasi.utils.RangeIterator.(RangeIterator.java:46)
> at
> org.apache.cassandra.index.sasi.memory.KeyRangeIterator.(KeyRangeIterator.java:42)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex$ConcurrentTrie.search(TrieMemIndex.java:150)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex.search(TrieMemIndex.java:102)
> at
> org.apache.cassandra.index.sasi.memory.IndexMemtable.search(IndexMemtable.java:70)
> at
> org.apache.cassandra.index.sasi.conf.ColumnIndex.searchMemtable(ColumnIndex.java:138)
> at org.apache.cassandra.index.sasi.TermIterator.build(TermIterator.java:91)
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndexes(QueryController.java:145)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:434)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.analyze(QueryPlan.java:57)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.execute(QueryPlan.java:68)
> at
> org.apache.cassandra.index.sasi.SASIIndex.lambda$searcherFor$2(SASIIndex.java:301)
> at org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:455)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getIndexed(SASIIndexTest.java:2576)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getPaged(SASIIndexTest.java:2537)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testConcurrentMemtableReadsAndWrites(SASIIndexTest.java:1108)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15526) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testConcurrentMemtableReadsAndWrites
[
https://issues.apache.org/jira/browse/CASSANDRA-15526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West reassigned CASSANDRA-15526:
---
Assignee: (was: Jordan West)
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest
> testConcurrentMemtableReadsAndWrites
>
>
> Key: CASSANDRA-15526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15526
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.index.sasi.utils.RangeIterator.(RangeIterator.java:46)
> at
> org.apache.cassandra.index.sasi.memory.KeyRangeIterator.(KeyRangeIterator.java:42)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex$ConcurrentTrie.search(TrieMemIndex.java:150)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex.search(TrieMemIndex.java:102)
> at
> org.apache.cassandra.index.sasi.memory.IndexMemtable.search(IndexMemtable.java:70)
> at
> org.apache.cassandra.index.sasi.conf.ColumnIndex.searchMemtable(ColumnIndex.java:138)
> at org.apache.cassandra.index.sasi.TermIterator.build(TermIterator.java:91)
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndexes(QueryController.java:145)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:434)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.analyze(QueryPlan.java:57)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.execute(QueryPlan.java:68)
> at
> org.apache.cassandra.index.sasi.SASIIndex.lambda$searcherFor$2(SASIIndex.java:301)
> at org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:455)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getIndexed(SASIIndexTest.java:2576)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getPaged(SASIIndexTest.java:2537)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testConcurrentMemtableReadsAndWrites(SASIIndexTest.java:1108)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15526) Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testConcurrentMemtableReadsAndWrites
[
https://issues.apache.org/jira/browse/CASSANDRA-15526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West reassigned CASSANDRA-15526:
---
Assignee: Jordan West
> Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest
> testConcurrentMemtableReadsAndWrites
>
>
> Key: CASSANDRA-15526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15526
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.index.sasi.utils.RangeIterator.(RangeIterator.java:46)
> at
> org.apache.cassandra.index.sasi.memory.KeyRangeIterator.(KeyRangeIterator.java:42)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex$ConcurrentTrie.search(TrieMemIndex.java:150)
> at
> org.apache.cassandra.index.sasi.memory.TrieMemIndex.search(TrieMemIndex.java:102)
> at
> org.apache.cassandra.index.sasi.memory.IndexMemtable.search(IndexMemtable.java:70)
> at
> org.apache.cassandra.index.sasi.conf.ColumnIndex.searchMemtable(ColumnIndex.java:138)
> at org.apache.cassandra.index.sasi.TermIterator.build(TermIterator.java:91)
> at
> org.apache.cassandra.index.sasi.plan.QueryController.getIndexes(QueryController.java:145)
> at
> org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:434)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.analyze(QueryPlan.java:57)
> at org.apache.cassandra.index.sasi.plan.QueryPlan.execute(QueryPlan.java:68)
> at
> org.apache.cassandra.index.sasi.SASIIndex.lambda$searcherFor$2(SASIIndex.java:301)
> at org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:455)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getIndexed(SASIIndexTest.java:2576)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.getPaged(SASIIndexTest.java:2537)
> at
> org.apache.cassandra.index.sasi.SASIIndexTest.testConcurrentMemtableReadsAndWrites(SASIIndexTest.java:1108)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15556) When a LZ4 stream is corrupted it could cause the JVM to crash
[
https://issues.apache.org/jira/browse/CASSANDRA-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032650#comment-17032650
]
David Capwell commented on CASSANDRA-15556:
---
bq. but I remember segfaulting was somehow related to passing expected length.
Maybe it's worth to check/try again.
[~ifesdjeen] attempted to try that out but it looks like every method requires
length and all all methods boil down to the following methods
{code}
/** Decompresses src[srcOff:] into
dest[destOff:destOff+destLen]
* and returns the number of bytes read from src.
* destLen must be exactly the size of the decompressed data.
*
* @param src the compressed data
* @param srcOff the start offset in src
* @param dest the destination buffer to store the decompressed data
* @param destOff the start offset in dest
* @param destLen the exact size of the original input
* @return the number of bytes read to restore the original input
*/
public abstract int decompress(byte[] src, int srcOff, byte[] dest, int
destOff, int destLen);
/** Decompresses src[srcOff:] into
dest[destOff:destOff+destLen]
* and returns the number of bytes read from src.
* destLen must be exactly the size of the decompressed data.
* The positions and limits of the {@link ByteBuffer}s remain unchanged.
*
* @param src the compressed data
* @param srcOff the start offset in src
* @param dest the destination buffer to store the decompressed data
* @param destOff the start offset in dest
* @param destLen the exact size of the original input
* @return the number of bytes read to restore the original input
*/
public abstract int decompress(ByteBuffer src, int srcOff, ByteBuffer dest,
int destOff, int destLen);
{code}
see
https://github.com/lz4/lz4-java/blob/master/src/java/net/jpountz/lz4/LZ4FastDecompressor.java#L46
Given this, there isn't any method I see which doesn't take the length, and its
actually required; so unable to test against what you recommended.
> When a LZ4 stream is corrupted it could cause the JVM to crash
> --
>
> Key: CASSANDRA-15556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15556
> Project: Cassandra
> Issue Type: Sub-task
> Components: Messaging/Client
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a spin off of CASSANDRA-15313 and CASSANDRA-15299
> This was found when lz4 sees compressed data (not all, but happens) which is
> corrupted; in some cases the JVM crashes producing the following
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x000110d46ad1, pid=86555, tid=0x1103
> #
> # JRE version: OpenJDK Runtime Environment (8.0_222-b10) (build 1.8.0_222-b10)
> # Java VM: OpenJDK 64-Bit Server VM (25.222-b10 mixed mode bsd-amd64
> compressed oops)
> # Problematic frame:
> # C [liblz4-java2766366422904460658.dylib+0x3ad1] LZ4_decompress_fast+0xf1
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /Users/davidcapwell/src/github/apache/cassandra/hs_err_pid86555.log
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15519) Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032658#comment-17032658 ] Jordan West commented on CASSANDRA-15519: - [~clohfink] thanks for committing. Committed in da90439f0052c3a05aaf6d4268a8c719e10fafde > Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at > runtime > - > > Key: CASSANDRA-15519 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15519 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config, Messaging/Client >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-15013 added configurable global and per endpoint limits on the > number of in flight requests, measured in bytes. During times when the > cluster is overloaded, it can be useful to change this setting without having > to restart the Cassandra process. Changing the limits should affect all > existing and new connections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15552) Fix flaky test org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-15552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032659#comment-17032659
]
David Capwell commented on CASSANDRA-15552:
---
Saw it again on java 11.
> Fix flaky test
> org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction
> --
>
> Key: CASSANDRA-15552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15552
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction(PendingAntiCompactionBytemanTest.java:80)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:364)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {code}
> Failure was on java 11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15559) Cassandra nodes not responding
Reeta created CASSANDRA-15559: - Summary: Cassandra nodes not responding Key: CASSANDRA-15559 URL: https://issues.apache.org/jira/browse/CASSANDRA-15559 Project: Cassandra Issue Type: Bug Reporter: Reeta Attachments: system.log The following cassandra nodes failed to respond giving Exception:- 10.0.88.138 Cassandra node 10.0.91.41 10.0.89.60 10.0.90.186 10.0.91.90 2020-02-06 19:35:58:337 thread=https-jsse-nio-8443-exec-125, level=ERROR, logger=o.a.c.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet], , message="Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.datastax.driver.core.exceptions.OperationTimedOutException: [/10.0.88.138:9042] Timed out waiting for server response] with root cause" com.datastax.driver.core.exceptions.OperationTimedOutException: [/10.0.88.138:9042] 2020-02-06 19:35:35:907 thread=https-jsse-nio-8443-exec-97, level=ERROR, logger=o.a.c.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet], , message="Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout during read query at consistency LOCAL_ONE (1 responses were required but only 0 replica responded)] with root cause" nodetool status on 10.0.88.138 node gave pretty inconsistent distribution in us-east-1:- Datacenter: us-east === Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.0.93.177 17.22 TB 256 ? bfe1d84b-eac9-4132-afca-35fde09377c4 1d UN 10.0.91.41 1.07 TB 256 ? bff1158e-985d-4ace-a152-1cd5747d58ca 1a UN 10.0.91.90 2.35 TB 256 ? 5230d506-3675-47e9-a8a6-8a59ec94c303 1a UN 10.0.88.138 1.59 TB 256 ? ff21fbac-ae71-48d8-8d78-e638b98dd3ed 1a UN 10.0.90.186 877.51 GB 256 ? ef58c52b-73fe-406e-adfd-09585b5da5ed 1a UN 10.0.93.123 5.6 TB 256 ? d29dbd92-174d-47bf-aeb4-5376aa05e352 1d UN 10.0.89.60 1.08 TB 256 ? ae8e25b5-e336-4bbc-853c-54574cd0814f 1a UN 10.0.91.237 1.25 TB 256 ? 085234df-6b46-4c9b-a512-9db034271458 1a UN 10.0.92.62 5.5 TB 256 ? 3b02ad6f-ed92-4fd6-8725-b2105f26ead3 1d Datacenter: us-west-2 = Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 10.3.192.211 1.55 TB 256 ? d6e47a22-e479-4df5-b1d7-a9c25a93d0e6 2a UN 10.3.194.246 1.56 TB 256 ? 343a8828-1d94-4845-85bd-eaa3fde6115c 2a UN 10.3.193.139 1.58 TB 256 ? 469d4a8d-a88d-42d2-a332-2dac1b03b7e7 2a UN 10.3.197.153 1.55 TB 256 ? 6b2db4b7-d3df-4a82-93ec-a8913c741bcd 2c UN 10.3.197.47 1.41 TB 256 ? c4636cb0-4419-4900-b5c2-2a62767b1513 2c UN 10.3.198.15 1.52 TB 256 ? 4fec0a33-16bf-420b-adda-2807290de2f1 2c UN 10.3.192.127 1.58 TB 256 ? 837e8256-7d29-4db4-b746-0a7aed8409a4 2a UN 10.3.196.190 1.63 TB 256 ? 99580b60-b329-4912-89c0-677be342c3af 2c -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15559) Cassandra nodes did not respond
[ https://issues.apache.org/jira/browse/CASSANDRA-15559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reeta updated CASSANDRA-15559: -- Summary: Cassandra nodes did not respond (was: Cassandra nodes not responding) > Cassandra nodes did not respond > --- > > Key: CASSANDRA-15559 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15559 > Project: Cassandra > Issue Type: Bug >Reporter: Reeta >Priority: Normal > Attachments: system.log > > > The following cassandra nodes failed to respond giving Exception:- > 10.0.88.138 Cassandra node > 10.0.91.41 > 10.0.89.60 > 10.0.90.186 > 10.0.91.90 > 2020-02-06 19:35:58:337 thread=https-jsse-nio-8443-exec-125, level=ERROR, > logger=o.a.c.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet], > , message="Servlet.service() for servlet [dispatcherServlet] in context with > path [] threw exception [Request processing failed; nested exception is > com.datastax.driver.core.exceptions.OperationTimedOutException: > [/10.0.88.138:9042] Timed out waiting for server response] with root cause" > com.datastax.driver.core.exceptions.OperationTimedOutException: > [/10.0.88.138:9042] > 2020-02-06 19:35:35:907 thread=https-jsse-nio-8443-exec-97, level=ERROR, > logger=o.a.c.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet], > , message="Servlet.service() for servlet [dispatcherServlet] in context with > path [] threw exception [Request processing failed; nested exception is > com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout > during read query at consistency LOCAL_ONE (1 responses were required but > only 0 replica responded)] with root cause" > nodetool status on 10.0.88.138 node gave pretty inconsistent distribution in > us-east-1:- > Datacenter: us-east > === > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- Address Load Tokens Owns Host ID Rack > UN 10.0.93.177 17.22 TB 256 ? bfe1d84b-eac9-4132-afca-35fde09377c4 1d > UN 10.0.91.41 1.07 TB 256 ? bff1158e-985d-4ace-a152-1cd5747d58ca 1a > UN 10.0.91.90 2.35 TB 256 ? 5230d506-3675-47e9-a8a6-8a59ec94c303 1a > UN 10.0.88.138 1.59 TB 256 ? ff21fbac-ae71-48d8-8d78-e638b98dd3ed 1a > UN 10.0.90.186 877.51 GB 256 ? ef58c52b-73fe-406e-adfd-09585b5da5ed 1a > UN 10.0.93.123 5.6 TB 256 ? d29dbd92-174d-47bf-aeb4-5376aa05e352 1d > UN 10.0.89.60 1.08 TB 256 ? ae8e25b5-e336-4bbc-853c-54574cd0814f 1a > UN 10.0.91.237 1.25 TB 256 ? 085234df-6b46-4c9b-a512-9db034271458 1a > UN 10.0.92.62 5.5 TB 256 ? 3b02ad6f-ed92-4fd6-8725-b2105f26ead3 1d > Datacenter: us-west-2 > = > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- Address Load Tokens Owns Host ID Rack > UN 10.3.192.211 1.55 TB 256 ? d6e47a22-e479-4df5-b1d7-a9c25a93d0e6 2a > UN 10.3.194.246 1.56 TB 256 ? 343a8828-1d94-4845-85bd-eaa3fde6115c 2a > UN 10.3.193.139 1.58 TB 256 ? 469d4a8d-a88d-42d2-a332-2dac1b03b7e7 2a > UN 10.3.197.153 1.55 TB 256 ? 6b2db4b7-d3df-4a82-93ec-a8913c741bcd 2c > UN 10.3.197.47 1.41 TB 256 ? c4636cb0-4419-4900-b5c2-2a62767b1513 2c > UN 10.3.198.15 1.52 TB 256 ? 4fec0a33-16bf-420b-adda-2807290de2f1 2c > UN 10.3.192.127 1.58 TB 256 ? 837e8256-7d29-4db4-b746-0a7aed8409a4 2a > UN 10.3.196.190 1.63 TB 256 ? 99580b60-b329-4912-89c0-677be342c3af 2c -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15559) Cassandra nodes did not respond
[ https://issues.apache.org/jira/browse/CASSANDRA-15559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15559: - Resolution: Not A Bug Status: Resolved (was: Triage Needed) This is a garden variety read timeout, caused by any number of environmental or operational factors, not a bug. I recommend taking this to the user list for help. > Cassandra nodes did not respond > --- > > Key: CASSANDRA-15559 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15559 > Project: Cassandra > Issue Type: Bug >Reporter: Reeta >Priority: Normal > Attachments: system.log > > > The following cassandra nodes failed to respond giving Exception:- > 10.0.88.138 Cassandra node > 10.0.91.41 > 10.0.89.60 > 10.0.90.186 > 10.0.91.90 > 2020-02-06 19:35:58:337 thread=https-jsse-nio-8443-exec-125, level=ERROR, > logger=o.a.c.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet], > , message="Servlet.service() for servlet [dispatcherServlet] in context with > path [] threw exception [Request processing failed; nested exception is > com.datastax.driver.core.exceptions.OperationTimedOutException: > [/10.0.88.138:9042] Timed out waiting for server response] with root cause" > com.datastax.driver.core.exceptions.OperationTimedOutException: > [/10.0.88.138:9042] > 2020-02-06 19:35:35:907 thread=https-jsse-nio-8443-exec-97, level=ERROR, > logger=o.a.c.core.ContainerBase.[Tomcat].[localhost].[/].[dispatcherServlet], > , message="Servlet.service() for servlet [dispatcherServlet] in context with > path [] threw exception [Request processing failed; nested exception is > com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout > during read query at consistency LOCAL_ONE (1 responses were required but > only 0 replica responded)] with root cause" > nodetool status on 10.0.88.138 node gave pretty inconsistent distribution in > us-east-1:- > Datacenter: us-east > === > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- Address Load Tokens Owns Host ID Rack > UN 10.0.93.177 17.22 TB 256 ? bfe1d84b-eac9-4132-afca-35fde09377c4 1d > UN 10.0.91.41 1.07 TB 256 ? bff1158e-985d-4ace-a152-1cd5747d58ca 1a > UN 10.0.91.90 2.35 TB 256 ? 5230d506-3675-47e9-a8a6-8a59ec94c303 1a > UN 10.0.88.138 1.59 TB 256 ? ff21fbac-ae71-48d8-8d78-e638b98dd3ed 1a > UN 10.0.90.186 877.51 GB 256 ? ef58c52b-73fe-406e-adfd-09585b5da5ed 1a > UN 10.0.93.123 5.6 TB 256 ? d29dbd92-174d-47bf-aeb4-5376aa05e352 1d > UN 10.0.89.60 1.08 TB 256 ? ae8e25b5-e336-4bbc-853c-54574cd0814f 1a > UN 10.0.91.237 1.25 TB 256 ? 085234df-6b46-4c9b-a512-9db034271458 1a > UN 10.0.92.62 5.5 TB 256 ? 3b02ad6f-ed92-4fd6-8725-b2105f26ead3 1d > Datacenter: us-west-2 > = > Status=Up/Down > |/ State=Normal/Leaving/Joining/Moving > -- Address Load Tokens Owns Host ID Rack > UN 10.3.192.211 1.55 TB 256 ? d6e47a22-e479-4df5-b1d7-a9c25a93d0e6 2a > UN 10.3.194.246 1.56 TB 256 ? 343a8828-1d94-4845-85bd-eaa3fde6115c 2a > UN 10.3.193.139 1.58 TB 256 ? 469d4a8d-a88d-42d2-a332-2dac1b03b7e7 2a > UN 10.3.197.153 1.55 TB 256 ? 6b2db4b7-d3df-4a82-93ec-a8913c741bcd 2c > UN 10.3.197.47 1.41 TB 256 ? c4636cb0-4419-4900-b5c2-2a62767b1513 2c > UN 10.3.198.15 1.52 TB 256 ? 4fec0a33-16bf-420b-adda-2807290de2f1 2c > UN 10.3.192.127 1.58 TB 256 ? 837e8256-7d29-4db4-b746-0a7aed8409a4 2a > UN 10.3.196.190 1.63 TB 256 ? 99580b60-b329-4912-89c0-677be342c3af 2c -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15560) Change io.compressor.LZ4Compressor to LZ4SafeDecompressor
[ https://issues.apache.org/jira/browse/CASSANDRA-15560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15560: Change Category: Quality Assurance Complexity: Low Hanging Fruit Fix Version/s: 4.0-rc Status: Open (was: Triage Needed) > Change io.compressor.LZ4Compressor to LZ4SafeDecompressor > - > > Key: CASSANDRA-15560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15560 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Compression >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-15556 and related tickets showed that LZ4FastDecompressor can crash > the JVM and that LZ4SafeDecompressor performs better w/o the crash risk — its > also not deprecated. While we protect ourselves by checksumming the > compressed data but that doesn’t mean we should leave deprecated code that > can segfault the jvm (providing a potential DDOS vector among other things) > in crucial places like io.compress. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15560) Change io.compressor.LZ4Compressor to LZ4SafeDecompressor
Jordan West created CASSANDRA-15560: --- Summary: Change io.compressor.LZ4Compressor to LZ4SafeDecompressor Key: CASSANDRA-15560 URL: https://issues.apache.org/jira/browse/CASSANDRA-15560 Project: Cassandra Issue Type: Improvement Components: Feature/Compression Reporter: Jordan West Assignee: Jordan West CASSANDRA-15556 and related tickets showed that LZ4FastDecompressor can crash the JVM and that LZ4SafeDecompressor performs better w/o the crash risk — its also not deprecated. While we protect ourselves by checksumming the compressed data but that doesn’t mean we should leave deprecated code that can segfault the jvm (providing a potential DDOS vector among other things) in crucial places like io.compress. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
