[jira] [Updated] (CASSANDRA-14792) skip TestRepair.test_dead_coordinator dtest in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-14792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-14792: Reviewer: Alex Petrov Status: Patch Available (was: Open) [dtest|https://github.com/bdeggleston/cassandra-dtest/tree/14792] [circle|https://circleci.com/workflow-run/bfc92bc4-5d31-4303-865b-b27515f0de00] > skip TestRepair.test_dead_coordinator dtest in 4.0 > -- > > Key: CASSANDRA-14792 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14792 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Minor > Fix For: 4.0 > > > CASSANDRA-14763 changed the coordinator behavior to not cleanup old repair > sessions, so this test doesn't really make sense anymore. We should just skip > it in 4.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14726) ReplicaCollection follow-up
[
https://issues.apache.org/jira/browse/CASSANDRA-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628027#comment-16628027
]
Ariel Weisberg commented on CASSANDRA-14726:
I think getting this into 4.0 would reduce the differences between 4.0 and
4.next and that makes it worth it in terms of avoiding future merge pain.
> ReplicaCollection follow-up
> ---
>
> Key: CASSANDRA-14726
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14726
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Benedict
>Assignee: Benedict
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We introduced \{{ReplicaCollection}} as part of CASSANDRA-14404, but while it
> improves readability, we could do more to ensure it minimises extra garbage,
> and does not otherwise unnecessarily waste cycles.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14792) skip TestRepair.test_dead_coordinator dtest in 4.0
Blake Eggleston created CASSANDRA-14792: --- Summary: skip TestRepair.test_dead_coordinator dtest in 4.0 Key: CASSANDRA-14792 URL: https://issues.apache.org/jira/browse/CASSANDRA-14792 Project: Cassandra Issue Type: Bug Reporter: Blake Eggleston Assignee: Blake Eggleston Fix For: 4.0 CASSANDRA-14763 changed the coordinator behavior to not cleanup old repair sessions, so this test doesn't really make sense anymore. We should just skip it in 4.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14770) Introduce RangesAtEndpoint.unwrap to simplify StreamSession.addTransferRanges
[
https://issues.apache.org/jira/browse/CASSANDRA-14770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-14770:
---
Reviewers: Ariel Weisberg
Reviewer: Ariel Weisberg
> Introduce RangesAtEndpoint.unwrap to simplify StreamSession.addTransferRanges
> -
>
> Key: CASSANDRA-14770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14770
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
>Reporter: Benedict
>Assignee: Benedict
>Priority: Trivial
> Fix For: 4.0
>
>
> Arguably, since this is only performed in one place, we could leave it in
> {{addTransferRanges}}, but it should be a helper method anyway, and given
> {{unwrap()}} is a feature of {{Range}}, we should implement that in
> {{RangesAtEndpoint}} IMO. I have introduced this method, which avoids
> allocating a new collection unnecessarily, corroborates we have at most one
> wrap-around range, and introduced unit tests for the method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14770) Introduce RangesAtEndpoint.unwrap to simplify StreamSession.addTransferRanges
[
https://issues.apache.org/jira/browse/CASSANDRA-14770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628019#comment-16628019
]
Ariel Weisberg commented on CASSANDRA-14770:
+1
> Introduce RangesAtEndpoint.unwrap to simplify StreamSession.addTransferRanges
> -
>
> Key: CASSANDRA-14770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14770
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
>Reporter: Benedict
>Assignee: Benedict
>Priority: Trivial
> Fix For: 4.0
>
>
> Arguably, since this is only performed in one place, we could leave it in
> {{addTransferRanges}}, but it should be a helper method anyway, and given
> {{unwrap()}} is a feature of {{Range}}, we should implement that in
> {{RangesAtEndpoint}} IMO. I have introduced this method, which avoids
> allocating a new collection unnecessarily, corroborates we have at most one
> wrap-around range, and introduced unit tests for the method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14791) [utest] tests unable to write system tmp directory
Jay Zhuang created CASSANDRA-14791:
--
Summary: [utest] tests unable to write system tmp directory
Key: CASSANDRA-14791
URL: https://issues.apache.org/jira/browse/CASSANDRA-14791
Project: Cassandra
Issue Type: Task
Components: Testing
Reporter: Jay Zhuang
Some tests are failing from time to time because it cannot write to directory
{{/tmp/}}:
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-test/lastCompletedBuild/testReport/org.apache.cassandra.streaming.compression/CompressedInputStreamTest/testException/
{noformat}
java.lang.RuntimeException: java.nio.file.AccessDeniedException:
/tmp/na-1-big-Data.db
at
org.apache.cassandra.io.util.SequentialWriter.openChannel(SequentialWriter.java:119)
at
org.apache.cassandra.io.util.SequentialWriter.(SequentialWriter.java:152)
at
org.apache.cassandra.io.util.SequentialWriter.(SequentialWriter.java:141)
at
org.apache.cassandra.io.compress.CompressedSequentialWriter.(CompressedSequentialWriter.java:82)
at
org.apache.cassandra.streaming.compression.CompressedInputStreamTest.testCompressedReadWith(CompressedInputStreamTest.java:119)
at
org.apache.cassandra.streaming.compression.CompressedInputStreamTest.testException(CompressedInputStreamTest.java:78)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.nio.file.AccessDeniedException: /tmp/na-1-big-Data.db
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
at java.nio.channels.FileChannel.open(FileChannel.java:287)
at java.nio.channels.FileChannel.open(FileChannel.java:335)
at
org.apache.cassandra.io.util.SequentialWriter.openChannel(SequentialWriter.java:100)
{noformat}
I guess it's because some Jenkins slaves don't have proper permission set. For
slave {{cassandra16}}, the tests are fine:
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-test/723/testReport/junit/org.apache.cassandra.streaming.compression/CompressedInputStreamTest/testException/history/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14762) Transient node receives full data requests in dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628006#comment-16628006
]
Ariel Weisberg commented on CASSANDRA-14762:
[Is this just a
clarification?|https://github.com/belliottsmith/cassandra/commit/0f8a736316feded871231e2ad571d53182d33ee2#diff-0920d7430e98bf3c6a3c4cb88056f8f5R293]
Maybe [~bdeggleston] should do a quick review as well since it is a small
change. I just want to sanity check that we should be reading from transient
replicas in both these cases.
It seems to me we use read repair to assemble the read after digest mismatch
between full replicas and that is why we it might send messages to transient
replicas? That is what it seems like to me. A minor out of scope improvement
would be to use the existing response and not repeat the read?
It seems to me also that we would read from transients as part of short read
protection (they are just another member of the group), and they aren't special
so we should issue them the query.
> Transient node receives full data requests in dtests
>
>
> Key: CASSANDRA-14762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14762
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Ariel Weisberg
>Assignee: Benedict
>Priority: Major
> Fix For: 4.0
>
>
> I saw this running them on my laptop with rapid write protection disabled.
> Attached is a patch for disabling rapid write protection in the transient
> dtests.
> {noformat}
> .Exception in thread Thread-19:
> Traceback (most recent call last):
> File
> "/usr/local/Cellar/python/3.6.4_4/Frameworks/Python.framework/Versions/3.6/lib/python3.6/threading.py",
> line 916, in _bootstrap_inner
> self.run()
> File
> "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line
> 180, in run
> self.scan_and_report()
> File
> "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line
> 173, in scan_and_report
> on_error_call(errordata)
> File "/Users/aweisberg/repos/cassandra-dtest/dtest_setup.py", line 137, in
> _log_error_handler
> pytest.fail("Error details: \n{message}".format(message=message))
> File
> "/Users/aweisberg/repos/cassandra-dtest/venv/lib/python3.6/site-packages/_pytest/outcomes.py",
> line 96, in fail
> raise Failed(msg=msg, pytrace=pytrace)
> Failed: Error details:
> Errors seen in logs for: node3
> node3: ERROR [ReadStage-1] 2018-09-18 12:28:48,344
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]
> org.apache.cassandra.exceptions.InvalidRequestException: Attempted to serve
> transient data request from full node in
> org.apache.cassandra.db.ReadCommandVerbHandler@3c55e0ff
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:104)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:53)
> at
> org.apache.cassandra.net.MessageDeliveryTask.process(MessageDeliveryTask.java:92)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:54)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:110)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14725) calculatePendingRanges does not handle full<->transient transition implied by add/remove another node
[ https://issues.apache.org/jira/browse/CASSANDRA-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-14725: - Status: Open (was: Patch Available) > calculatePendingRanges does not handle full<->transient transition implied by > add/remove another node > - > > Key: CASSANDRA-14725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14725 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Benedict >Priority: Major > Labels: correctness, transient-replication > Fix For: 4.0 > > > We only implemented handling those implied directly by a node changing its > own status, but a node entering or leaving the ring can imply such a movement > on another node, and these need to be handled. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14725) calculatePendingRanges does not handle full<->transient transition implied by add/remove another node
[ https://issues.apache.org/jira/browse/CASSANDRA-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-14725: --- Reviewers: Ariel Weisberg Reviewer: Ariel Weisberg > calculatePendingRanges does not handle full<->transient transition implied by > add/remove another node > - > > Key: CASSANDRA-14725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14725 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Benedict >Priority: Major > Labels: correctness, transient-replication > Fix For: 4.0 > > > We only implemented handling those implied directly by a node changing its > own status, but a node entering or leaving the ring can imply such a movement > on another node, and these need to be handled. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14762) Transient node receives full data requests in dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-14762:
---
Reviewers: Ariel Weisberg
Reviewer: Ariel Weisberg
> Transient node receives full data requests in dtests
>
>
> Key: CASSANDRA-14762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14762
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Ariel Weisberg
>Assignee: Benedict
>Priority: Major
> Fix For: 4.0
>
>
> I saw this running them on my laptop with rapid write protection disabled.
> Attached is a patch for disabling rapid write protection in the transient
> dtests.
> {noformat}
> .Exception in thread Thread-19:
> Traceback (most recent call last):
> File
> "/usr/local/Cellar/python/3.6.4_4/Frameworks/Python.framework/Versions/3.6/lib/python3.6/threading.py",
> line 916, in _bootstrap_inner
> self.run()
> File
> "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line
> 180, in run
> self.scan_and_report()
> File
> "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line
> 173, in scan_and_report
> on_error_call(errordata)
> File "/Users/aweisberg/repos/cassandra-dtest/dtest_setup.py", line 137, in
> _log_error_handler
> pytest.fail("Error details: \n{message}".format(message=message))
> File
> "/Users/aweisberg/repos/cassandra-dtest/venv/lib/python3.6/site-packages/_pytest/outcomes.py",
> line 96, in fail
> raise Failed(msg=msg, pytrace=pytrace)
> Failed: Error details:
> Errors seen in logs for: node3
> node3: ERROR [ReadStage-1] 2018-09-18 12:28:48,344
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-1,5,main]
> org.apache.cassandra.exceptions.InvalidRequestException: Attempted to serve
> transient data request from full node in
> org.apache.cassandra.db.ReadCommandVerbHandler@3c55e0ff
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:104)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:53)
> at
> org.apache.cassandra.net.MessageDeliveryTask.process(MessageDeliveryTask.java:92)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:54)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:110)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14725) calculatePendingRanges does not handle full<->transient transition implied by add/remove another node
[
https://issues.apache.org/jira/browse/CASSANDRA-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627982#comment-16627982
]
Benedict commented on CASSANDRA-14725:
--
Ach, yes, I'm not sure what I was smoking. I'm currently working on a follow
up ticket with more inadequacies with {{calculatePendingRanges}}, in which I'm
putting together unit tests for other failure cases. So perhaps shelve review
of this ticket for now, and I'll let you know when I have both ready with
associated unit tests.
> calculatePendingRanges does not handle full<->transient transition implied by
> add/remove another node
> -
>
> Key: CASSANDRA-14725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14725
> Project: Cassandra
> Issue Type: Bug
>Reporter: Benedict
>Assignee: Benedict
>Priority: Major
> Labels: correctness, transient-replication
> Fix For: 4.0
>
>
> We only implemented handling those implied directly by a node changing its
> own status, but a node entering or leaving the ring can imply such a movement
> on another node, and these need to be handled.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14725) calculatePendingRanges does not handle full<->transient transition implied by add/remove another node
[ https://issues.apache.org/jira/browse/CASSANDRA-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627970#comment-16627970 ] Ariel Weisberg edited comment on CASSANDRA-14725 at 9/25/18 9:54 PM: - We at least need a regression test for what this fixes. Especially because I don't think this does what it aims to do yet. [This is calling get() by range on a collection keyed on endpoint|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR882]. Curse java.util.Map's lack of type checking on get! [I think this comment may be wrong?|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR875] Take a ring with 3/1 and four tokens, remove one token. This will trigger a null -> full and transient -> full transition I think. It can't produce full -> transient or full -> null though because we are forcing more nodes to replicate more data and not taking data away from any node. Similarly when adding a node we create transitions from a more replicated state to a less replicated state and we have to impact two other nodes. There will be a full or transient to null transition and a full -> transient transition I think. [So this comment seems off.|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR900] was (Author: aweisberg): We at least need a regression test for what this fixes. Especially because I don't think this does what it aims to do yet. [This is calling get() by range on a collection keyed on endpoint|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR882]. Curse java.util.Map's lack of type checking on get! [I think this comment may be wrong?|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR875] Take a ring with 3/1 and four tokens, remove one token. This will trigger a null -> full and transient -> full transition I think. It can't produce full -> transient or full -> null though because we are forcing more nodes to replicate more data and not taking data away from any node. Similarly when adding a node we create transitions from a more replicated state to a less replicated state and we have to impact two other nodes. There will be a full or transient to null transition and a full -> transient transition I think. [So this comment seems off.|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR900] > calculatePendingRanges does not handle full<->transient transition implied by > add/remove another node > - > > Key: CASSANDRA-14725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14725 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Benedict >Priority: Major > Labels: correctness, transient-replication > Fix For: 4.0 > > > We only implemented handling those implied directly by a node changing its > own status, but a node entering or leaving the ring can imply such a movement > on another node, and these need to be handled. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14725) calculatePendingRanges does not handle full<->transient transition implied by add/remove another node
[ https://issues.apache.org/jira/browse/CASSANDRA-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627970#comment-16627970 ] Ariel Weisberg edited comment on CASSANDRA-14725 at 9/25/18 9:54 PM: - We at least need a regression test for what this fixes. Especially because I don't think this does what it aims to do yet. [This is calling get() by range on a collection keyed on endpoint|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR882]. Curse java.util.Map's lack of type checking on get! [I think this comment may be wrong?|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR875] Take a ring with 3/1 and four tokens, remove one token. This will trigger a null -> full and transient -> full transition I think. It can't produce full -> transient or full -> null though because we are forcing more nodes to replicate more data and not taking data away from any node. Similarly when adding a node we create transitions from a more replicated state to a less replicated state and we have to impact two other nodes. There will be a full or transient to null transition and a full -> transient transition I think. [So this comment seems off.|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR900] was (Author: aweisberg): We at least need a regression test for what this fixes. Especially because I don't think this does what it aims to do yet. [This is calling get() by range on a collection keyed on endpoint|][https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR882].] Curse java.util.Map's lack of type checking on get! [I think this comment may be wrong?|[https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR875]] Take a ring with 3/1 and four tokens, remove one token. This will trigger a null -> full and transient -> full transition I think. It can't produce full -> transient or full -> null though because we are forcing more nodes to replicate more data and not taking data away from any node. Similarly when adding a node we create transitions from a more replicated state to a less replicated state and we have to impact two other nodes. There will be a full or transient to null transition and a full -> transient transition I think. [So this comment seems off.|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR900] > calculatePendingRanges does not handle full<->transient transition implied by > add/remove another node > - > > Key: CASSANDRA-14725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14725 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Benedict >Priority: Major > Labels: correctness, transient-replication > Fix For: 4.0 > > > We only implemented handling those implied directly by a node changing its > own status, but a node entering or leaving the ring can imply such a movement > on another node, and these need to be handled. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14725) calculatePendingRanges does not handle full<->transient transition implied by add/remove another node
[ https://issues.apache.org/jira/browse/CASSANDRA-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627970#comment-16627970 ] Ariel Weisberg commented on CASSANDRA-14725: We at least need a regression test for what this fixes. Especially because I don't think this does what it aims to do yet. [This is calling get() by range on a collection keyed on endpoint|][https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR882].] Curse java.util.Map's lack of type checking on get! [I think this comment may be wrong?|[https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR875]] Take a ring with 3/1 and four tokens, remove one token. This will trigger a null -> full and transient -> full transition I think. It can't produce full -> transient or full -> null though because we are forcing more nodes to replicate more data and not taking data away from any node. Similarly when adding a node we create transitions from a more replicated state to a less replicated state and we have to impact two other nodes. There will be a full or transient to null transition and a full -> transient transition I think. [So this comment seems off.|https://github.com/belliottsmith/cassandra/commit/99796da2117b2d4f29f1d08e93badb81994e12b9#diff-b9ead760fa9628889810dd64e6507d9cR900] > calculatePendingRanges does not handle full<->transient transition implied by > add/remove another node > - > > Key: CASSANDRA-14725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14725 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict >Assignee: Benedict >Priority: Major > Labels: correctness, transient-replication > Fix For: 4.0 > > > We only implemented handling those implied directly by a node changing its > own status, but a node entering or leaving the ring can imply such a movement > on another node, and these need to be handled. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14790) LongBufferPoolTest burn test fails assertion
[
https://issues.apache.org/jira/browse/CASSANDRA-14790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-14790:
-
Description:
The LongBufferPoolTest from the burn tests fails with an assertion error. I
added a build target to run individual burn tests, and \{jasobrown} gave a fix
for the uninitialized test setup (attached), however the test now fails on an
assertion about recycling buffers.
To reproduce (with patch applied)
{{ant burn-testsome
-Dtest.name=org.apache.cassandra.utils.memory.LongBufferPoolTest
-Dtest.methods=testAllocate}}
Output
{{ [junit] Testcase:
testAllocate(org.apache.cassandra.utils.memory.LongBufferPoolTest): FAILED}}
{{ [junit] null}}
{{ [junit] junit.framework.AssertionFailedError}}
{{ [junit] at
org.apache.cassandra.utils.memory.BufferPool$Debug.check(BufferPool.java:204)}}
{{ [junit] at
org.apache.cassandra.utils.memory.BufferPool.assertAllRecycled(BufferPool.java:181)}}
{{ [junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:350)}}
{{ [junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:54)}}
All major branches from 3.0 and later have issues, however the trunk branch
also warns about references not being released before the reference is garbage
collected.
{{[junit] ERROR [Reference-Reaper:1] 2018-09-25 13:59:54,089 Ref.java:224 -
LEAK DETECTED: a reference
(org.apache.cassandra.utils.concurrent.Ref$State@7f58d19a) to @623704362 was
not released before the reference was garbage collected}}
{{ [junit] ERROR [Reference-Reaper:1] 2018-09-25 13:59:54,089 Ref.java:255 -
Allocate trace org.apache.cassandra.utils.concurrent.Ref$State@7f58d19a:}}
{{ [junit] Thread[pool-2-thread-24,5,main]}}
{{ [junit] at java.lang.Thread.getStackTrace(Thread.java:1559)}}
{{ [junit] at
org.apache.cassandra.utils.concurrent.Ref$Debug.(Ref.java:245)}}
{{ [junit] at
org.apache.cassandra.utils.concurrent.Ref$State.(Ref.java:175)}}
{{ [junit] at org.apache.cassandra.utils.concurrent.Ref.(Ref.java:97)}}
{{ [junit] at
org.apache.cassandra.utils.memory.BufferPool$Chunk.setAttachment(BufferPool.java:663)}}
{{ [junit] at
org.apache.cassandra.utils.memory.BufferPool$Chunk.get(BufferPool.java:803)}}
{{ [junit] at
org.apache.cassandra.utils.memory.BufferPool$Chunk.get(BufferPool.java:793)}}
{{ [junit] at
org.apache.cassandra.utils.memory.BufferPool$LocalPool.get(BufferPool.java:388)}}
{{ [junit] at
org.apache.cassandra.utils.memory.BufferPool.maybeTakeFromPool(BufferPool.java:143)}}
{{ [junit] at
org.apache.cassandra.utils.memory.BufferPool.takeFromPool(BufferPool.java:115)}}
{{ [junit] at
org.apache.cassandra.utils.memory.BufferPool.get(BufferPool.java:85)}}
{{ [junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$3.allocate(LongBufferPoolTest.java:296)}}
{{ [junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$3.testOne(LongBufferPoolTest.java:246)}}
{{ [junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$TestUntil.call(LongBufferPoolTest.java:399)}}
{{ [junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$TestUntil.call(LongBufferPoolTest.java:379)}}
{{ [junit] at java.util.concurrent.FutureTask.run(FutureTask.java:266)}}
{{ [junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)}}
{{ [junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)}}
{{ [junit] at java.lang.Thread.run(Thread.java:748)}}
Perhaps the environment is not being set up correctly for the tests.
was:
The LongBufferPoolTest from the burn tests fails with an assertion error. I
added a build target to run individual burn tests, and \{jasobrown} gave a fix
for the uninitialized test setup (attached), however the test now fails on an
assertion about recycling buffers.
To reproduce (with patch applied)
{{ ant burn-testsome
-Dtest.name=org.apache.cassandra.utils.memory.LongBufferPoolTest
-Dtest.methods=testAllocate}}
Output
{{ [junit] Testcase:
testAllocate(org.apache.cassandra.utils.memory.LongBufferPoolTest): FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Debug.check(BufferPool.java:204)
[junit] at
org.apache.cassandra.utils.memory.BufferPool.assertAllRecycled(BufferPool.java:181)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:350)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:54)}}
All major branches from 3.0 and later have issues, however the trunk branch
also warns about references not being released before the reference is garbage
collected.
{{ [junit] ERROR [Reference-Reaper:1] 2018-09-25 13:59:54,089 Ref.java:224 -
LEAK DETECTED: a
[jira] [Updated] (CASSANDRA-14790) LongBufferPoolTest burn test fails assertion
[
https://issues.apache.org/jira/browse/CASSANDRA-14790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-14790:
-
Description:
The LongBufferPoolTest from the burn tests fails with an assertion error. I
added a build target to run individual burn tests, and \{jasobrown} gave a fix
for the uninitialized test setup (attached), however the test now fails on an
assertion about recycling buffers.
To reproduce (with patch applied)
{{ ant burn-testsome
-Dtest.name=org.apache.cassandra.utils.memory.LongBufferPoolTest
-Dtest.methods=testAllocate}}
Output
{{ [junit] Testcase:
testAllocate(org.apache.cassandra.utils.memory.LongBufferPoolTest): FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Debug.check(BufferPool.java:204)
[junit] at
org.apache.cassandra.utils.memory.BufferPool.assertAllRecycled(BufferPool.java:181)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:350)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:54)}}
All major branches from 3.0 and later have issues, however the trunk branch
also warns about references not being released before the reference is garbage
collected.
{{ [junit] ERROR [Reference-Reaper:1] 2018-09-25 13:59:54,089 Ref.java:224 -
LEAK DETECTED: a reference
(org.apache.cassandra.utils.concurrent.Ref$State@7f58d19a) to @623704362 was
not released before the reference was garbage collected
[junit] ERROR [Reference-Reaper:1] 2018-09-25 13:59:54,089 Ref.java:255 -
Allocate trace org.apache.cassandra.utils.concurrent.Ref$State@7f58d19a:
[junit] Thread[pool-2-thread-24,5,main]
[junit] at java.lang.Thread.getStackTrace(Thread.java:1559)
[junit] at org.apache.cassandra.utils.concurrent.Ref$Debug.(Ref.java:245)
[junit] at org.apache.cassandra.utils.concurrent.Ref$State.(Ref.java:175)
[junit] at org.apache.cassandra.utils.concurrent.Ref.(Ref.java:97)
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Chunk.setAttachment(BufferPool.java:663)
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Chunk.get(BufferPool.java:803)
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Chunk.get(BufferPool.java:793)
[junit] at
org.apache.cassandra.utils.memory.BufferPool$LocalPool.get(BufferPool.java:388)
[junit] at
org.apache.cassandra.utils.memory.BufferPool.maybeTakeFromPool(BufferPool.java:143)
[junit] at
org.apache.cassandra.utils.memory.BufferPool.takeFromPool(BufferPool.java:115)
[junit] at org.apache.cassandra.utils.memory.BufferPool.get(BufferPool.java:85)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$3.allocate(LongBufferPoolTest.java:296)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$3.testOne(LongBufferPoolTest.java:246)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$TestUntil.call(LongBufferPoolTest.java:399)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$TestUntil.call(LongBufferPoolTest.java:379)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit] at java.lang.Thread.run(Thread.java:748)
}}
Perhaps the environment is not being set up correctly for the tests.
was:
The LongBufferPoolTest from the burn tests fails with an assertion error. I
added a build target to run individual burn tests, and \{jasobrown} gave a fix
for the uninitialized test setup (attached), however the test now fails on an
assertion about recycling buffers.
To reproduce (with patch applied)
{{
ant burn-testsome
-Dtest.name=org.apache.cassandra.utils.memory.LongBufferPoolTest
-Dtest.methods=testAllocate
}}
Output
{{
[junit] Testcase:
testAllocate(org.apache.cassandra.utils.memory.LongBufferPoolTest): FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Debug.check(BufferPool.java:204)
[junit] at
org.apache.cassandra.utils.memory.BufferPool.assertAllRecycled(BufferPool.java:181)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:350)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:54)}}
All major branches from 3.0 and later have issues, however the trunk branch
also warns about references not being released before the reference is garbage
collected.
{{
[junit] ERROR [Reference-Reaper:1] 2018-09-25 13:59:54,089 Ref.java:224 -
LEAK DETECTED: a reference
(org.apache.cassandra.utils.concurrent.Ref$State@7f58d19a) to @623704362 was
not released
[jira] [Created] (CASSANDRA-14790) LongBufferPoolTest burn test fails assertion
Jon Meredith created CASSANDRA-14790:
Summary: LongBufferPoolTest burn test fails assertion
Key: CASSANDRA-14790
URL: https://issues.apache.org/jira/browse/CASSANDRA-14790
Project: Cassandra
Issue Type: Test
Components: Testing
Environment: Run under macOS 10.13.6, with patch (attached, but also
https://github.com/jonmeredith/cassandra/tree/failing-burn-test)
Reporter: Jon Meredith
Attachments: 0001-Add-burn-testsome-target-to-build.xml.patch,
0002-Initialize-before-running-LongBufferPoolTest.patch
The LongBufferPoolTest from the burn tests fails with an assertion error. I
added a build target to run individual burn tests, and \{jasobrown} gave a fix
for the uninitialized test setup (attached), however the test now fails on an
assertion about recycling buffers.
To reproduce (with patch applied)
{{
ant burn-testsome
-Dtest.name=org.apache.cassandra.utils.memory.LongBufferPoolTest
-Dtest.methods=testAllocate
}}
Output
{{
[junit] Testcase:
testAllocate(org.apache.cassandra.utils.memory.LongBufferPoolTest): FAILED
[junit] null
[junit] junit.framework.AssertionFailedError
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Debug.check(BufferPool.java:204)
[junit] at
org.apache.cassandra.utils.memory.BufferPool.assertAllRecycled(BufferPool.java:181)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:350)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest.testAllocate(LongBufferPoolTest.java:54)}}
All major branches from 3.0 and later have issues, however the trunk branch
also warns about references not being released before the reference is garbage
collected.
{{
[junit] ERROR [Reference-Reaper:1] 2018-09-25 13:59:54,089 Ref.java:224 -
LEAK DETECTED: a reference
(org.apache.cassandra.utils.concurrent.Ref$State@7f58d19a) to @623704362 was
not released before the reference was garbage collected
[junit] ERROR [Reference-Reaper:1] 2018-09-25 13:59:54,089 Ref.java:255 -
Allocate trace org.apache.cassandra.utils.concurrent.Ref$State@7f58d19a:
[junit] Thread[pool-2-thread-24,5,main]
[junit] at java.lang.Thread.getStackTrace(Thread.java:1559)
[junit] at
org.apache.cassandra.utils.concurrent.Ref$Debug.(Ref.java:245)
[junit] at
org.apache.cassandra.utils.concurrent.Ref$State.(Ref.java:175)
[junit] at org.apache.cassandra.utils.concurrent.Ref.(Ref.java:97)
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Chunk.setAttachment(BufferPool.java:663)
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Chunk.get(BufferPool.java:803)
[junit] at
org.apache.cassandra.utils.memory.BufferPool$Chunk.get(BufferPool.java:793)
[junit] at
org.apache.cassandra.utils.memory.BufferPool$LocalPool.get(BufferPool.java:388)
[junit] at
org.apache.cassandra.utils.memory.BufferPool.maybeTakeFromPool(BufferPool.java:143)
[junit] at
org.apache.cassandra.utils.memory.BufferPool.takeFromPool(BufferPool.java:115)
[junit] at
org.apache.cassandra.utils.memory.BufferPool.get(BufferPool.java:85)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$3.allocate(LongBufferPoolTest.java:296)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$3.testOne(LongBufferPoolTest.java:246)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$TestUntil.call(LongBufferPoolTest.java:399)
[junit] at
org.apache.cassandra.utils.memory.LongBufferPoolTest$TestUntil.call(LongBufferPoolTest.java:379)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[junit] at java.lang.Thread.run(Thread.java:748)
}}
Perhaps the environment is not being set up correctly for the tests.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14727) Transient Replication: EACH_QUORUM not implemented
[ https://issues.apache.org/jira/browse/CASSANDRA-14727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627923#comment-16627923 ] Ariel Weisberg commented on CASSANDRA-14727: +1 > Transient Replication: EACH_QUORUM not implemented > -- > > Key: CASSANDRA-14727 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14727 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Benedict >Priority: Major > Fix For: 4.0 > > > Transient replication cannot presently handle EACH_QUORUM consistency; reads > and writes should currently fail, though without good error messages. Not > clear if this is acceptable for GA, since we cannot impose this limitation at > Keyspace declaration time. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14674) Repair Validation message request could get stuck forever at sender side
[
https://issues.apache.org/jira/browse/CASSANDRA-14674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627890#comment-16627890
]
Blake Eggleston commented on CASSANDRA-14674:
-
Can you give some more details about how this impacts your operation?
As far as I can tell, the impact is that we can occasionally leak a hung
thread. This isn’t great, but unless you’re doing something unusual, the actual
impact on the database should be negligible, assuming it’s detectable at all.
The provided patch, however, makes some non-trivial changes to the way repair
messaging works, which is risky, and something that shouldn't go into a bugfix
release unless it's really needed.
Since the fix seems riskier than not fixing the issue, I’d lean towards not
fixing it. Especially since it’s fixed in trunk.
Thoughts?
> Repair Validation message request could get stuck forever at sender side
>
>
> Key: CASSANDRA-14674
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14674
> Project: Cassandra
> Issue Type: Bug
> Components: Repair
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Major
>
> Validation request message as part of repair are currently sent as
> [sendOneWay|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/repair/ValidationTask.java#L56]
> and then it waits at
> [Futures.getUnchecked|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/repair/RepairJob.java#L160].
> If sender doesn’t hear back from receiver for whatever reason then thread is
> blocked forever. I’ve reproduced following stack trace at sender side by
> deliberately ignoring
> [VALIDATION_REQUST|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/repair/RepairMessageVerbHandler.java#L114]
> at receiver side.
> {quote}"Repair#1:1" #301 daemon prio=5 os_prio=0 tid=0x7f5a62060800
> nid=0x13198 waiting on condition [0x7f5a5cc6c000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> parking to wait for <0x0005c6ba9630> (a
> com.google.common.util.concurrent.AbstractFuture$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:285)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> at
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)
> at com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)
> at org.apache.cassandra.repair.RepairJob.run(RepairJob.java:160)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$3/1858015030.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
> {quote}
> AFAIK we should be using {{sendRR}} for this instead of {{sendOneWay}}.
> Please let me know if my understanding is correct or not.
> I am working on a fix to make it {{sendRR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14756) Transient Replication - range movement improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627869#comment-16627869 ] Ariel Weisberg commented on CASSANDRA-14756: +1 modulo tests passing and the one thing I just pointed out where the assertion now occurs after filtering and should be before. > Transient Replication - range movement improvements > --- > > Key: CASSANDRA-14756 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14756 > Project: Cassandra > Issue Type: Improvement >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > * Simplify iteration in calculateRangesToFetchWithPreferredEndpoints > * Minor changes to calculateRangesToFetchWithPreferredEndpoints to improve > readability: > * Simplify RangeRelocator code > * Fix range relocation > * Simplify calculateStreamAndFetchRanges > * Unify request/transfer ranges interface (Added benefit of this change is > that we have a check for non-intersecting ranges) > * Simplify iteration in calculateRangesToFetchWithPreferredEndpoints > * Improve error messages -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14672) After deleting data in 3.11.3, reads fail with "open marker and close marker have different deletion times"
[
https://issues.apache.org/jira/browse/CASSANDRA-14672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627633#comment-16627633
]
Aleksey Yeschenko commented on CASSANDRA-14672:
---
Thanks, committed to 3.0 as
[d496dca6729853ece49d68c4837fed35149c95d0|https://github.com/apache/cassandra/commit/d496dca6729853ece49d68c4837fed35149c95d0]
and merged upwards with 3.11 and 4.0.
> After deleting data in 3.11.3, reads fail with "open marker and close marker
> have different deletion times"
> ---
>
> Key: CASSANDRA-14672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14672
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Environment: CentOS 7, GCE, 9 nodes, 4TB disk/~2TB full each, level
> compaction, timeseries data
>Reporter: Spiros Ioannou
>Assignee: Aleksey Yeschenko
>Priority: Blocker
> Fix For: 3.0.18, 3.11.4, 4.0
>
>
> We had 3.11.0, then we upgraded to 3.11.3 last week. We routinely perform
> deletions as the one described below. After upgrading we run the following
> deletion query:
>
> {code:java}
> DELETE FROM measurement_events_dbl WHERE measurement_source_id IN (
> 9df798a2-6337-11e8-b52b-42010afa015a, 9df7717e-6337-11e8-b52b-42010afa015a,
> a08b8042-6337-11e8-b52b-42010afa015a, a08e52cc-6337-11e8-b52b-42010afa015a,
> a08e6654-6337-11e8-b52b-42010afa015a, a08e6104-6337-11e8-b52b-42010afa015a,
> a08e6c76-6337-11e8-b52b-42010afa015a, a08e5a9c-6337-11e8-b52b-42010afa015a,
> a08bcc50-6337-11e8-b52b-42010afa015a) AND year IN (2018) AND measurement_time
> >= '2018-07-19 04:00:00'{code}
>
> Immediately after that, trying to read the last value produces an error:
> {code:java}
> select * FROM measurement_events_dbl WHERE measurement_source_id =
> a08b8042-6337-11e8-b52b-42010afa015a AND year IN (2018) order by
> measurement_time desc limit 1;
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
> message="Operation failed - received 0 responses and 2 failures"
> info={'failures': 2, 'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}{code}
>
> And the following exception:
> {noformat}
> WARN [ReadStage-4] 2018-08-29 06:59:53,505
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-4,5,main]: {}
> java.lang.RuntimeException: java.lang.IllegalStateException:
> UnfilteredRowIterator for pvpms_mevents.measurement_events_dbl has an illegal
> RT bounds sequence: open marker and close marker have different deletion times
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2601)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_181]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.3.jar:3.11.3]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.11.3.jar:3.11.3]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181]
> Caused by: java.lang.IllegalStateException: UnfilteredRowIterator for
> pvpms_mevents.measurement_events_dbl has an illegal RT bounds sequence: open
> marker and close marker have different deletion times
> at
> org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.ise(RTBoundValidator.java:103)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.applyToMarker(RTBoundValidator.java:81)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:148)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:136)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:187)
>
[jira] [Updated] (CASSANDRA-14672) After deleting data in 3.11.3, reads fail with "open marker and close marker have different deletion times"
[
https://issues.apache.org/jira/browse/CASSANDRA-14672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-14672:
--
Resolution: Fixed
Fix Version/s: (was: 4.0.x)
(was: 3.11.x)
(was: 3.0.x)
4.0
3.11.4
3.0.18
Reproduced In: 3.11.3, 3.0.17 (was: 3.0.17, 3.11.3)
Status: Resolved (was: Patch Available)
> After deleting data in 3.11.3, reads fail with "open marker and close marker
> have different deletion times"
> ---
>
> Key: CASSANDRA-14672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14672
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Environment: CentOS 7, GCE, 9 nodes, 4TB disk/~2TB full each, level
> compaction, timeseries data
>Reporter: Spiros Ioannou
>Assignee: Aleksey Yeschenko
>Priority: Blocker
> Fix For: 3.0.18, 3.11.4, 4.0
>
>
> We had 3.11.0, then we upgraded to 3.11.3 last week. We routinely perform
> deletions as the one described below. After upgrading we run the following
> deletion query:
>
> {code:java}
> DELETE FROM measurement_events_dbl WHERE measurement_source_id IN (
> 9df798a2-6337-11e8-b52b-42010afa015a, 9df7717e-6337-11e8-b52b-42010afa015a,
> a08b8042-6337-11e8-b52b-42010afa015a, a08e52cc-6337-11e8-b52b-42010afa015a,
> a08e6654-6337-11e8-b52b-42010afa015a, a08e6104-6337-11e8-b52b-42010afa015a,
> a08e6c76-6337-11e8-b52b-42010afa015a, a08e5a9c-6337-11e8-b52b-42010afa015a,
> a08bcc50-6337-11e8-b52b-42010afa015a) AND year IN (2018) AND measurement_time
> >= '2018-07-19 04:00:00'{code}
>
> Immediately after that, trying to read the last value produces an error:
> {code:java}
> select * FROM measurement_events_dbl WHERE measurement_source_id =
> a08b8042-6337-11e8-b52b-42010afa015a AND year IN (2018) order by
> measurement_time desc limit 1;
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
> message="Operation failed - received 0 responses and 2 failures"
> info={'failures': 2, 'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}{code}
>
> And the following exception:
> {noformat}
> WARN [ReadStage-4] 2018-08-29 06:59:53,505
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-4,5,main]: {}
> java.lang.RuntimeException: java.lang.IllegalStateException:
> UnfilteredRowIterator for pvpms_mevents.measurement_events_dbl has an illegal
> RT bounds sequence: open marker and close marker have different deletion times
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2601)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_181]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.3.jar:3.11.3]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.11.3.jar:3.11.3]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181]
> Caused by: java.lang.IllegalStateException: UnfilteredRowIterator for
> pvpms_mevents.measurement_events_dbl has an illegal RT bounds sequence: open
> marker and close marker have different deletion times
> at
> org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.ise(RTBoundValidator.java:103)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.applyToMarker(RTBoundValidator.java:81)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:148)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:136)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
>
[3/6] cassandra git commit: Fix purging semi-expired RT boundaries in reversed iterators
Fix purging semi-expired RT boundaries in reversed iterators
patch by Aleksey Yeschenko; reviewed by Blake Eggleston for
CASSANDRA-14672
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d496dca6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d496dca6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d496dca6
Branch: refs/heads/trunk
Commit: d496dca6729853ece49d68c4837fed35149c95d0
Parents: 45937de
Author: Aleksey Yeshchenko
Authored: Fri Sep 21 21:26:13 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:32:56 2018 +0100
--
CHANGES.txt | 1 +
.../db/rows/RangeTombstoneBoundaryMarker.java | 4 +-
.../db/partitions/PurgeFunctionTest.java| 294 +++
3 files changed, 297 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d496dca6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 43628b2..2c2f4f5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.18
+ * Fix purging semi-expired RT boundaries in reversed iterators
(CASSANDRA-14672)
* DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d496dca6/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
diff --git
a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
index c4bc2f2..f0f5421 100644
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
@@ -136,12 +136,12 @@ public class RangeTombstoneBoundaryMarker extends
AbstractRangeTombstoneMarker
public RangeTombstoneBoundMarker createCorrespondingCloseMarker(boolean
reversed)
{
-return new RangeTombstoneBoundMarker(closeBound(reversed),
endDeletion);
+return new RangeTombstoneBoundMarker(closeBound(reversed),
closeDeletionTime(reversed));
}
public RangeTombstoneBoundMarker createCorrespondingOpenMarker(boolean
reversed)
{
-return new RangeTombstoneBoundMarker(openBound(reversed),
startDeletion);
+return new RangeTombstoneBoundMarker(openBound(reversed),
openDeletionTime(reversed));
}
public void digest(MessageDigest digest)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d496dca6/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
--
diff --git
a/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
b/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
new file mode 100644
index 000..1dea7f3
--- /dev/null
+++ b/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
@@ -0,0 +1,294 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.db.partitions;
+
+import java.nio.ByteBuffer;
+import java.util.Iterator;
+import java.util.function.Predicate;
+
+import com.google.common.collect.Iterators;
+import org.junit.Before;
+import org.junit.Test;
+
+import org.apache.cassandra.config.CFMetaData;
+import org.apache.cassandra.db.ClusteringPrefix.Kind;
+import org.apache.cassandra.db.*;
+import org.apache.cassandra.db.marshal.AbstractType;
+import org.apache.cassandra.db.marshal.UTF8Type;
+import org.apache.cassandra.db.rows.*;
+import org.apache.cassandra.db.transform.Transformation;
+import org.apache.cassandra.dht.Murmur3Partitioner;
+import org.apache.cassandra.utils.FBUtilities;
+
+import static
[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11
Merge branch 'cassandra-3.0' into cassandra-3.11
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c34a0f52
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c34a0f52
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c34a0f52
Branch: refs/heads/cassandra-3.11
Commit: c34a0f5207d228a2b78f6295cd4ab3e0755e56c2
Parents: 4d3f5a3 d496dca
Author: Aleksey Yeshchenko
Authored: Tue Sep 25 17:41:10 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:41:10 2018 +0100
--
CHANGES.txt | 1 +
.../db/rows/RangeTombstoneBoundaryMarker.java | 4 +-
.../db/partitions/PurgeFunctionTest.java| 297 +++
3 files changed, 300 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c34a0f52/CHANGES.txt
--
diff --cc CHANGES.txt
index a4fa705,2c2f4f5..20cec87
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,5 -1,5 +1,6 @@@
-3.0.18
+3.11.4
+Merged from 3.0:
+ * Fix purging semi-expired RT boundaries in reversed iterators
(CASSANDRA-14672)
* DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c34a0f52/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c34a0f52/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
--
diff --cc test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
index 000,1dea7f3..7f85aea
mode 00,100644..100644
--- a/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
+++ b/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
@@@ -1,0 -1,294 +1,297 @@@
+ /*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+ package org.apache.cassandra.db.partitions;
+
+ import java.nio.ByteBuffer;
+ import java.util.Iterator;
+ import java.util.function.Predicate;
+
+ import com.google.common.collect.Iterators;
+ import org.junit.Before;
+ import org.junit.Test;
+
+ import org.apache.cassandra.config.CFMetaData;
++import org.apache.cassandra.config.DatabaseDescriptor;
+ import org.apache.cassandra.db.ClusteringPrefix.Kind;
+ import org.apache.cassandra.db.*;
+ import org.apache.cassandra.db.marshal.AbstractType;
+ import org.apache.cassandra.db.marshal.UTF8Type;
+ import org.apache.cassandra.db.rows.*;
+ import org.apache.cassandra.db.transform.Transformation;
+ import org.apache.cassandra.dht.Murmur3Partitioner;
+ import org.apache.cassandra.utils.FBUtilities;
+
+ import static org.junit.Assert.assertEquals;
+ import static org.junit.Assert.assertTrue;
+
+ import static org.apache.cassandra.utils.ByteBufferUtil.bytes;
+
+ public final class PurgeFunctionTest
+ {
+ private static final String KEYSPACE = "PurgeFunctionTest";
+ private static final String TABLE = "table";
+
+ private CFMetaData metadata;
+ private DecoratedKey key;
+
+ private static UnfilteredPartitionIterator
withoutPurgeableTombstones(UnfilteredPartitionIterator iterator, int gcBefore)
+ {
+ class WithoutPurgeableTombstones extends PurgeFunction
+ {
+ private WithoutPurgeableTombstones()
+ {
+ super(iterator.isForThrift(), FBUtilities.nowInSeconds(),
gcBefore, Integer.MAX_VALUE, false, false);
+ }
+
+ protected Predicate getPurgeEvaluator()
+ {
+ return time -> true;
+ }
+ }
+
+ return Transformation.apply(iterator, new
[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk
Merge branch 'cassandra-3.11' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/210da3dc Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/210da3dc Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/210da3dc Branch: refs/heads/trunk Commit: 210da3dc003a4107e125d0276476c289f2a2b97c Parents: 5069b2c c34a0f5 Author: Aleksey Yeshchenko Authored: Tue Sep 25 17:46:05 2018 +0100 Committer: Aleksey Yeshchenko Committed: Tue Sep 25 17:46:05 2018 +0100 -- CHANGES.txt | 2 + .../db/rows/RangeTombstoneBoundaryMarker.java | 4 +- .../db/partitions/PurgeFunctionTest.java| 296 +++ 3 files changed, 300 insertions(+), 2 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/210da3dc/CHANGES.txt -- diff --cc CHANGES.txt index b39fe03,20cec87..9f7958c --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,320 -1,7 +1,322 @@@ +4.0 + * Avoid creating empty compaction tasks after truncate (CASSANDRA-14780) + * Fail incremental repair prepare phase if it encounters sstables from un-finalized sessions (CASSANDRA-14763) + * Add a check for receiving digest response from transient node (CASSANDRA-14750) + * Fail query on transient replica if coordinator only expects full data (CASSANDRA-14704) + * Remove mentions of transient replication from repair path (CASSANDRA-14698) + * Fix handleRepairStatusChangedNotification to remove first then add (CASSANDRA-14720) + * Allow transient node to serve as a repair coordinator (CASSANDRA-14693) + * DecayingEstimatedHistogramReservoir.EstimatedHistogramReservoirSnapshot returns wrong value for size() and incorrectly calculates count (CASSANDRA-14696) + * AbstractReplicaCollection equals and hash code should throw due to conflict between order sensitive/insensitive uses (CASSANDRA-14700) + * Detect inconsistencies in repaired data on the read path (CASSANDRA-14145) + * Add checksumming to the native protocol (CASSANDRA-13304) + * Make AuthCache more easily extendable (CASSANDRA-14662) + * Extend RolesCache to include detailed role info (CASSANDRA-14497) + * Add fqltool compare (CASSANDRA-14619) + * Add fqltool replay (CASSANDRA-14618) + * Log keyspace in full query log (CASSANDRA-14656) + * Transient Replication and Cheap Quorums (CASSANDRA-14404) + * Log server-generated timestamp and nowInSeconds used by queries in FQL (CASSANDRA-14675) + * Add diagnostic events for read repairs (CASSANDRA-14668) + * Use consistent nowInSeconds and timestamps values within a request (CASSANDRA-14671) + * Add sampler for query time and expose with nodetool (CASSANDRA-14436) + * Clean up Message.Request implementations (CASSANDRA-14677) + * Disable old native protocol versions on demand (CASANDRA-14659) + * Allow specifying now-in-seconds in native protocol (CASSANDRA-14664) + * Improve BTree build performance by avoiding data copy (CASSANDRA-9989) + * Make monotonic read / read repair configurable (CASSANDRA-14635) + * Refactor CompactionStrategyManager (CASSANDRA-14621) + * Flush netty client messages immediately by default (CASSANDRA-13651) + * Improve read repair blocking behavior (CASSANDRA-10726) + * Add a virtual table to expose settings (CASSANDRA-14573) + * Fix up chunk cache handling of metrics (CASSANDRA-14628) + * Extend IAuthenticator to accept peer SSL certificates (CASSANDRA-14652) + * Incomplete handling of exceptions when decoding incoming messages (CASSANDRA-14574) + * Add diagnostic events for user audit logging (CASSANDRA-13668) + * Allow retrieving diagnostic events via JMX (CASSANDRA-14435) + * Add base classes for diagnostic events (CASSANDRA-13457) + * Clear view system metadata when dropping keyspace (CASSANDRA-14646) + * Allocate ReentrantLock on-demand in java11 AtomicBTreePartitionerBase (CASSANDRA-14637) + * Make all existing virtual tables use LocalPartitioner (CASSANDRA-14640) + * Revert 4.0 GC alg back to CMS (CASANDRA-14636) + * Remove hardcoded java11 jvm args in idea workspace files (CASSANDRA-14627) + * Update netty to 4.1.128 (CASSANDRA-14633) + * Add a virtual table to expose thread pools (CASSANDRA-14523) + * Add a virtual table to expose caches (CASSANDRA-14538, CASSANDRA-14626) + * Fix toDate function for timestamp arguments (CASSANDRA-14502) + * Revert running dtests by default in circleci (CASSANDRA-14614) + * Stream entire SSTables when possible (CASSANDRA-14556) + * Cell reconciliation should not depend on nowInSec (CASSANDRA-14592) + * Add experimental support for Java 11 (CASSANDRA-9608) + * Make PeriodicCommitLogService.blockWhenSyncLagsNanos configurable (CASSANDRA-14580) + * Improve logging in MessageInHandler's
[2/6] cassandra git commit: Fix purging semi-expired RT boundaries in reversed iterators
Fix purging semi-expired RT boundaries in reversed iterators
patch by Aleksey Yeschenko; reviewed by Blake Eggleston for
CASSANDRA-14672
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d496dca6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d496dca6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d496dca6
Branch: refs/heads/cassandra-3.11
Commit: d496dca6729853ece49d68c4837fed35149c95d0
Parents: 45937de
Author: Aleksey Yeshchenko
Authored: Fri Sep 21 21:26:13 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:32:56 2018 +0100
--
CHANGES.txt | 1 +
.../db/rows/RangeTombstoneBoundaryMarker.java | 4 +-
.../db/partitions/PurgeFunctionTest.java| 294 +++
3 files changed, 297 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d496dca6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 43628b2..2c2f4f5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.18
+ * Fix purging semi-expired RT boundaries in reversed iterators
(CASSANDRA-14672)
* DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d496dca6/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
diff --git
a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
index c4bc2f2..f0f5421 100644
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
@@ -136,12 +136,12 @@ public class RangeTombstoneBoundaryMarker extends
AbstractRangeTombstoneMarker
public RangeTombstoneBoundMarker createCorrespondingCloseMarker(boolean
reversed)
{
-return new RangeTombstoneBoundMarker(closeBound(reversed),
endDeletion);
+return new RangeTombstoneBoundMarker(closeBound(reversed),
closeDeletionTime(reversed));
}
public RangeTombstoneBoundMarker createCorrespondingOpenMarker(boolean
reversed)
{
-return new RangeTombstoneBoundMarker(openBound(reversed),
startDeletion);
+return new RangeTombstoneBoundMarker(openBound(reversed),
openDeletionTime(reversed));
}
public void digest(MessageDigest digest)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d496dca6/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
--
diff --git
a/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
b/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
new file mode 100644
index 000..1dea7f3
--- /dev/null
+++ b/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
@@ -0,0 +1,294 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.db.partitions;
+
+import java.nio.ByteBuffer;
+import java.util.Iterator;
+import java.util.function.Predicate;
+
+import com.google.common.collect.Iterators;
+import org.junit.Before;
+import org.junit.Test;
+
+import org.apache.cassandra.config.CFMetaData;
+import org.apache.cassandra.db.ClusteringPrefix.Kind;
+import org.apache.cassandra.db.*;
+import org.apache.cassandra.db.marshal.AbstractType;
+import org.apache.cassandra.db.marshal.UTF8Type;
+import org.apache.cassandra.db.rows.*;
+import org.apache.cassandra.db.transform.Transformation;
+import org.apache.cassandra.dht.Murmur3Partitioner;
+import org.apache.cassandra.utils.FBUtilities;
+
+import
[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11
Merge branch 'cassandra-3.0' into cassandra-3.11
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/c34a0f52
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/c34a0f52
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/c34a0f52
Branch: refs/heads/trunk
Commit: c34a0f5207d228a2b78f6295cd4ab3e0755e56c2
Parents: 4d3f5a3 d496dca
Author: Aleksey Yeshchenko
Authored: Tue Sep 25 17:41:10 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:41:10 2018 +0100
--
CHANGES.txt | 1 +
.../db/rows/RangeTombstoneBoundaryMarker.java | 4 +-
.../db/partitions/PurgeFunctionTest.java| 297 +++
3 files changed, 300 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c34a0f52/CHANGES.txt
--
diff --cc CHANGES.txt
index a4fa705,2c2f4f5..20cec87
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,5 -1,5 +1,6 @@@
-3.0.18
+3.11.4
+Merged from 3.0:
+ * Fix purging semi-expired RT boundaries in reversed iterators
(CASSANDRA-14672)
* DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c34a0f52/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/c34a0f52/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
--
diff --cc test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
index 000,1dea7f3..7f85aea
mode 00,100644..100644
--- a/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
+++ b/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
@@@ -1,0 -1,294 +1,297 @@@
+ /*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+ package org.apache.cassandra.db.partitions;
+
+ import java.nio.ByteBuffer;
+ import java.util.Iterator;
+ import java.util.function.Predicate;
+
+ import com.google.common.collect.Iterators;
+ import org.junit.Before;
+ import org.junit.Test;
+
+ import org.apache.cassandra.config.CFMetaData;
++import org.apache.cassandra.config.DatabaseDescriptor;
+ import org.apache.cassandra.db.ClusteringPrefix.Kind;
+ import org.apache.cassandra.db.*;
+ import org.apache.cassandra.db.marshal.AbstractType;
+ import org.apache.cassandra.db.marshal.UTF8Type;
+ import org.apache.cassandra.db.rows.*;
+ import org.apache.cassandra.db.transform.Transformation;
+ import org.apache.cassandra.dht.Murmur3Partitioner;
+ import org.apache.cassandra.utils.FBUtilities;
+
+ import static org.junit.Assert.assertEquals;
+ import static org.junit.Assert.assertTrue;
+
+ import static org.apache.cassandra.utils.ByteBufferUtil.bytes;
+
+ public final class PurgeFunctionTest
+ {
+ private static final String KEYSPACE = "PurgeFunctionTest";
+ private static final String TABLE = "table";
+
+ private CFMetaData metadata;
+ private DecoratedKey key;
+
+ private static UnfilteredPartitionIterator
withoutPurgeableTombstones(UnfilteredPartitionIterator iterator, int gcBefore)
+ {
+ class WithoutPurgeableTombstones extends PurgeFunction
+ {
+ private WithoutPurgeableTombstones()
+ {
+ super(iterator.isForThrift(), FBUtilities.nowInSeconds(),
gcBefore, Integer.MAX_VALUE, false, false);
+ }
+
+ protected Predicate getPurgeEvaluator()
+ {
+ return time -> true;
+ }
+ }
+
+ return Transformation.apply(iterator, new
WithoutPurgeableTombstones());
+
[1/6] cassandra git commit: Fix purging semi-expired RT boundaries in reversed iterators
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 45937def3 -> d496dca67
refs/heads/cassandra-3.11 4d3f5a32b -> c34a0f520
refs/heads/trunk 5069b2c0f -> 210da3dc0
Fix purging semi-expired RT boundaries in reversed iterators
patch by Aleksey Yeschenko; reviewed by Blake Eggleston for
CASSANDRA-14672
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/d496dca6
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/d496dca6
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/d496dca6
Branch: refs/heads/cassandra-3.0
Commit: d496dca6729853ece49d68c4837fed35149c95d0
Parents: 45937de
Author: Aleksey Yeshchenko
Authored: Fri Sep 21 21:26:13 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:32:56 2018 +0100
--
CHANGES.txt | 1 +
.../db/rows/RangeTombstoneBoundaryMarker.java | 4 +-
.../db/partitions/PurgeFunctionTest.java| 294 +++
3 files changed, 297 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d496dca6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 43628b2..2c2f4f5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.18
+ * Fix purging semi-expired RT boundaries in reversed iterators
(CASSANDRA-14672)
* DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d496dca6/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
--
diff --git
a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
index c4bc2f2..f0f5421 100644
--- a/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
+++ b/src/java/org/apache/cassandra/db/rows/RangeTombstoneBoundaryMarker.java
@@ -136,12 +136,12 @@ public class RangeTombstoneBoundaryMarker extends
AbstractRangeTombstoneMarker
public RangeTombstoneBoundMarker createCorrespondingCloseMarker(boolean
reversed)
{
-return new RangeTombstoneBoundMarker(closeBound(reversed),
endDeletion);
+return new RangeTombstoneBoundMarker(closeBound(reversed),
closeDeletionTime(reversed));
}
public RangeTombstoneBoundMarker createCorrespondingOpenMarker(boolean
reversed)
{
-return new RangeTombstoneBoundMarker(openBound(reversed),
startDeletion);
+return new RangeTombstoneBoundMarker(openBound(reversed),
openDeletionTime(reversed));
}
public void digest(MessageDigest digest)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/d496dca6/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
--
diff --git
a/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
b/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
new file mode 100644
index 000..1dea7f3
--- /dev/null
+++ b/test/unit/org/apache/cassandra/db/partitions/PurgeFunctionTest.java
@@ -0,0 +1,294 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.cassandra.db.partitions;
+
+import java.nio.ByteBuffer;
+import java.util.Iterator;
+import java.util.function.Predicate;
+
+import com.google.common.collect.Iterators;
+import org.junit.Before;
+import org.junit.Test;
+
+import org.apache.cassandra.config.CFMetaData;
+import org.apache.cassandra.db.ClusteringPrefix.Kind;
+import org.apache.cassandra.db.*;
+import org.apache.cassandra.db.marshal.AbstractType;
+import org.apache.cassandra.db.marshal.UTF8Type;
+import
[jira] [Commented] (CASSANDRA-14766) DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627573#comment-16627573
]
Aleksey Yeschenko commented on CASSANDRA-14766:
---
Thanks. Committed to 3.0 as
[45937def313bbb32024ae890f830e23bcc6ccae5|https://github.com/apache/cassandra/commit/45937def313bbb32024ae890f830e23bcc6ccae5]
and merged to 3.11, and with {{-s ours}} into trunk.
Dtest committed as
[02c1cd77439b220a09df1d53891441bb80dcf944|https://github.com/apache/cassandra-dtest/commit/02c1cd77439b220a09df1d53891441bb80dcf944].
NOTE: I did fold {{iterator.hasNext()}} check into the if-branch above on
commit, to remove one extra level of nesting from the code.
> DESC order reads can fail to return the last Unfiltered in the partition in a
> legacy sstable
>
>
> Key: CASSANDRA-14766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14766
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 3.0.18, 3.11.4
>
>
> {{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
> {{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
> But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
> If that last block, when iterating backwards, only has two {{Unfiltered}},
> the first one will be returned, and the last one won’t as the reverse
> iterator would incorrectly things that the deserisalizer is past the index
> block, despite still having one {{Unfiltered}} unreturned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14766) DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-14766:
--
Resolution: Fixed
Fix Version/s: (was: 3.11.x)
(was: 3.0.x)
3.11.4
3.0.18
Status: Resolved (was: Patch Available)
> DESC order reads can fail to return the last Unfiltered in the partition in a
> legacy sstable
>
>
> Key: CASSANDRA-14766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14766
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 3.0.18, 3.11.4
>
>
> {{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
> {{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
> But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
> If that last block, when iterating backwards, only has two {{Unfiltered}},
> the first one will be returned, and the last one won’t as the reverse
> iterator would incorrectly things that the deserisalizer is past the index
> block, despite still having one {{Unfiltered}} unreturned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
cassandra-dtest git commit: DESC order reads can fail to return the last Unfiltered in the partition
Repository: cassandra-dtest
Updated Branches:
refs/heads/master 2accd9998 -> 02c1cd774
DESC order reads can fail to return the last Unfiltered in the partition
patch by Aleksey Yeschenko; reviewed by Sam Tunnicliffe and Benedict
Elliott Smith for CASSANDRA-14766
Project: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/commit/02c1cd77
Tree: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/tree/02c1cd77
Diff: http://git-wip-us.apache.org/repos/asf/cassandra-dtest/diff/02c1cd77
Branch: refs/heads/master
Commit: 02c1cd77439b220a09df1d53891441bb80dcf944
Parents: 2accd99
Author: Aleksey Yeschenko
Authored: Tue Sep 25 14:40:59 2018 +0100
Committer: Aleksey Yeschenko
Committed: Tue Sep 25 15:09:43 2018 +0100
--
legacy_sstables_test.py | 58
1 file changed, 58 insertions(+)
--
http://git-wip-us.apache.org/repos/asf/cassandra-dtest/blob/02c1cd77/legacy_sstables_test.py
--
diff --git a/legacy_sstables_test.py b/legacy_sstables_test.py
new file mode 100644
index 000..bedfbea
--- /dev/null
+++ b/legacy_sstables_test.py
@@ -0,0 +1,58 @@
+import pytest
+
+from cassandra import ConsistencyLevel
+from dtest import Tester
+from tools.assertions import assert_all
+
+since = pytest.mark.since
+
+class TestLegacySSTables(Tester):
+
+@since('3.0', max_version='4')
+def test_14766(self):
+"""
+@jira_ticket CASSANDRA-14766
+
+A reproduction / regression test to illustrate CASSANDRA-14766: when
+reading a legacy 2.1 sstable with SSTableReversedIterator, it's
possible
+to skip and not return the last Unfiltered in the last indexed block.
+
+It would lead to a missing row, if that Unfiltered was a row, or
potentially
+resurrected data, if it's a tombstone.
+"""
+cluster = self.cluster
+
+# set column_index_size_in_kb to 1 for a small reproduction sequence
+cluster.set_configuration_options(values={'column_index_size_in_kb':
1})
+
+# start with 2.1.20 to generate a legacy sstable
+cluster.set_install_dir(version='2.1.20')
+
+cluster.populate(1).start(wait_other_notice=True)
+node1 = cluster.nodelist()[0]
+session = self.patient_cql_connection(node1)
+
+query = "CREATE KEYSPACE test WITH replication = {'class':
'NetworkTopologyStrategy', 'datacenter1': 1};"
+session.execute(query)
+
+query = 'CREATE TABLE test.test (pk int, ck int, value text, PRIMARY
KEY (pk, ck));'
+session.execute(query)
+
+# insert 4 rows to fill 2 index blocks and flush the 2.1 sstable
+stmt = session.prepare('INSERT INTO test.test (pk, ck, value) VALUES
(0, ?, ?);');
+for i in range(0, 4):
+session.execute(stmt, [i, '0' * 512])
+cluster.flush()
+
+# stop, upgrade to current version (3.0 or 3.11), start up
+node1.stop(wait_other_notice=True)
+self.set_node_to_current_version(node1)
+node1.start(wait_other_notice=True)
+session = self.patient_cql_connection(node1)
+
+# make sure all 4 rows are there when reading backwards
+# prior to the fix, this would return 3 rows (ck = 2, 1, 0), skipping
ck = 3
+assert_all(session,
+ "SELECT ck FROM test.test WHERE pk = 0 ORDER BY ck DESC;",
+ [[3], [2], [1], [0]],
+ cl=ConsistencyLevel.ONE)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[2/6] cassandra git commit: DESC order reads can fail to return the last Unfiltered in the partition
DESC order reads can fail to return the last Unfiltered in the partition
patch by Aleksey Yeschenko; reviewed by Sam Tunnicliffe and Benedict
Elliott Smith for CASSANDRA-14766
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/45937def
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/45937def
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/45937def
Branch: refs/heads/cassandra-3.11
Commit: 45937def313bbb32024ae890f830e23bcc6ccae5
Parents: 322f7e9
Author: Aleksey Yeshchenko
Authored: Tue Sep 18 13:12:11 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:02:06 2018 +0100
--
CHANGES.txt | 1 +
.../cassandra/db/UnfilteredDeserializer.java| 115 ---
...bles-legacy_ka_14766-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Data.db | Bin 0 -> 103 bytes
...gacy_tables-legacy_ka_14766-ka-1-Digest.sha1 | 1 +
...legacy_tables-legacy_ka_14766-ka-1-Filter.db | Bin 0 -> 16 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Index.db | Bin 0 -> 134 bytes
...cy_tables-legacy_ka_14766-ka-1-Statistics.db | Bin 0 -> 4450 bytes
...egacy_tables-legacy_ka_14766-ka-1-Summary.db | Bin 0 -> 92 bytes
.../legacy_tables-legacy_ka_14766-ka-1-TOC.txt | 8 ++
.../cassandra/io/sstable/LegacySSTableTest.java | 27 -
11 files changed, 112 insertions(+), 40 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/45937def/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 195c97c..43628b2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.18
+ * DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
* Handle failures in parallelAllSSTableOperation
(cleanup/upgradesstables/etc) (CASSANDRA-14657)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/45937def/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
--
diff --git a/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
b/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
index 0aa5741..62ad76a 100644
--- a/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
+++ b/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
@@ -245,10 +245,14 @@ public abstract class UnfilteredDeserializer
// The next Unfiltered to return, computed by hasNext()
private Unfiltered next;
-// A temporary storage for an unfiltered that isn't returned next but
should be looked at just afterwards
-private Unfiltered saved;
-private boolean isFirst = true;
+// Saved position in the input after the next Unfiltered that will be
consumed
+private long nextConsumedPosition;
+
+// A temporary storage for an Unfiltered that isn't returned next but
should be looked at just afterwards
+private Stash stash;
+
+private boolean couldBeStartOfPartition = true;
// The Unfiltered as read from the old format input
private final UnfilteredIterator iterator;
@@ -258,7 +262,15 @@ public abstract class UnfilteredDeserializer
// Tracks the size of the last LegacyAtom read from disk, because this
needs to be accounted
// for when marking lastConsumedPosition after readNext/skipNext
-private long bytesReadForNextAtom;
+// Reading/skipping an Unfiltered consumes LegacyAtoms from the
underlying legacy atom iterator
+// e.g. hasNext() -> iterator.hasNext() -> iterator.readRow() ->
atoms.next()
+// The stop condition of the loop which groups legacy atoms into rows
causes that AtomIterator
+// to read in the first atom which doesn't belong in the row. So by
that point, our position
+// is actually past the end of the next Unfiltered. To compensate, we
record the size of
+// the last LegacyAtom read and subtract it from the current position
when we calculate lastConsumedPosition.
+// If we don't, then when reading an indexed block, we can over
correct and may think that we've
+// exhausted the block before we actually have.
+private long bytesReadForNextAtom = 0L;
private OldFormatDeserializer(CFMetaData metadata,
DataInputPlus in,
@@ -313,27 +325,55 @@ public abstract class UnfilteredDeserializer
{
while (next == null)
{
-
[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk
Merge branch 'cassandra-3.11' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5069b2c0 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5069b2c0 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5069b2c0 Branch: refs/heads/trunk Commit: 5069b2c0ffc3aa335523e7b598cae05ee50ded8a Parents: 44cffc0 4d3f5a3 Author: Aleksey Yeshchenko Authored: Tue Sep 25 17:05:10 2018 +0100 Committer: Aleksey Yeshchenko Committed: Tue Sep 25 17:05:10 2018 +0100 -- -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[3/6] cassandra git commit: DESC order reads can fail to return the last Unfiltered in the partition
DESC order reads can fail to return the last Unfiltered in the partition
patch by Aleksey Yeschenko; reviewed by Sam Tunnicliffe and Benedict
Elliott Smith for CASSANDRA-14766
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/45937def
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/45937def
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/45937def
Branch: refs/heads/trunk
Commit: 45937def313bbb32024ae890f830e23bcc6ccae5
Parents: 322f7e9
Author: Aleksey Yeshchenko
Authored: Tue Sep 18 13:12:11 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:02:06 2018 +0100
--
CHANGES.txt | 1 +
.../cassandra/db/UnfilteredDeserializer.java| 115 ---
...bles-legacy_ka_14766-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Data.db | Bin 0 -> 103 bytes
...gacy_tables-legacy_ka_14766-ka-1-Digest.sha1 | 1 +
...legacy_tables-legacy_ka_14766-ka-1-Filter.db | Bin 0 -> 16 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Index.db | Bin 0 -> 134 bytes
...cy_tables-legacy_ka_14766-ka-1-Statistics.db | Bin 0 -> 4450 bytes
...egacy_tables-legacy_ka_14766-ka-1-Summary.db | Bin 0 -> 92 bytes
.../legacy_tables-legacy_ka_14766-ka-1-TOC.txt | 8 ++
.../cassandra/io/sstable/LegacySSTableTest.java | 27 -
11 files changed, 112 insertions(+), 40 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/45937def/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 195c97c..43628b2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.18
+ * DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
* Handle failures in parallelAllSSTableOperation
(cleanup/upgradesstables/etc) (CASSANDRA-14657)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/45937def/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
--
diff --git a/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
b/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
index 0aa5741..62ad76a 100644
--- a/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
+++ b/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
@@ -245,10 +245,14 @@ public abstract class UnfilteredDeserializer
// The next Unfiltered to return, computed by hasNext()
private Unfiltered next;
-// A temporary storage for an unfiltered that isn't returned next but
should be looked at just afterwards
-private Unfiltered saved;
-private boolean isFirst = true;
+// Saved position in the input after the next Unfiltered that will be
consumed
+private long nextConsumedPosition;
+
+// A temporary storage for an Unfiltered that isn't returned next but
should be looked at just afterwards
+private Stash stash;
+
+private boolean couldBeStartOfPartition = true;
// The Unfiltered as read from the old format input
private final UnfilteredIterator iterator;
@@ -258,7 +262,15 @@ public abstract class UnfilteredDeserializer
// Tracks the size of the last LegacyAtom read from disk, because this
needs to be accounted
// for when marking lastConsumedPosition after readNext/skipNext
-private long bytesReadForNextAtom;
+// Reading/skipping an Unfiltered consumes LegacyAtoms from the
underlying legacy atom iterator
+// e.g. hasNext() -> iterator.hasNext() -> iterator.readRow() ->
atoms.next()
+// The stop condition of the loop which groups legacy atoms into rows
causes that AtomIterator
+// to read in the first atom which doesn't belong in the row. So by
that point, our position
+// is actually past the end of the next Unfiltered. To compensate, we
record the size of
+// the last LegacyAtom read and subtract it from the current position
when we calculate lastConsumedPosition.
+// If we don't, then when reading an indexed block, we can over
correct and may think that we've
+// exhausted the block before we actually have.
+private long bytesReadForNextAtom = 0L;
private OldFormatDeserializer(CFMetaData metadata,
DataInputPlus in,
@@ -313,27 +325,55 @@ public abstract class UnfilteredDeserializer
{
while (next == null)
{
-
[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11
Merge branch 'cassandra-3.0' into cassandra-3.11
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4d3f5a32
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4d3f5a32
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4d3f5a32
Branch: refs/heads/trunk
Commit: 4d3f5a32b2cc821f74fbece183ededdd91d195bf
Parents: 4f30dae 45937de
Author: Aleksey Yeshchenko
Authored: Tue Sep 25 17:03:57 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:03:57 2018 +0100
--
CHANGES.txt | 1 +
.../cassandra/db/UnfilteredDeserializer.java| 115 ---
...bles-legacy_ka_14766-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Data.db | Bin 0 -> 103 bytes
...gacy_tables-legacy_ka_14766-ka-1-Digest.sha1 | 1 +
...legacy_tables-legacy_ka_14766-ka-1-Filter.db | Bin 0 -> 16 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Index.db | Bin 0 -> 134 bytes
...cy_tables-legacy_ka_14766-ka-1-Statistics.db | Bin 0 -> 4450 bytes
...egacy_tables-legacy_ka_14766-ka-1-Summary.db | Bin 0 -> 92 bytes
.../legacy_tables-legacy_ka_14766-ka-1-TOC.txt | 8 ++
.../cassandra/io/sstable/LegacySSTableTest.java | 27 -
11 files changed, 112 insertions(+), 40 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d3f5a32/CHANGES.txt
--
diff --cc CHANGES.txt
index f04cae1,43628b2..a4fa705
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,5 -1,5 +1,6 @@@
-3.0.18
+3.11.4
+Merged from 3.0:
+ * DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
* Handle failures in parallelAllSSTableOperation
(cleanup/upgradesstables/etc) (CASSANDRA-14657)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d3f5a32/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d3f5a32/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java
--
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[1/6] cassandra git commit: DESC order reads can fail to return the last Unfiltered in the partition
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 322f7e9bb -> 45937def3
refs/heads/cassandra-3.11 4f30dae1d -> 4d3f5a32b
refs/heads/trunk 44cffc0b1 -> 5069b2c0f
DESC order reads can fail to return the last Unfiltered in the partition
patch by Aleksey Yeschenko; reviewed by Sam Tunnicliffe and Benedict
Elliott Smith for CASSANDRA-14766
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/45937def
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/45937def
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/45937def
Branch: refs/heads/cassandra-3.0
Commit: 45937def313bbb32024ae890f830e23bcc6ccae5
Parents: 322f7e9
Author: Aleksey Yeshchenko
Authored: Tue Sep 18 13:12:11 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:02:06 2018 +0100
--
CHANGES.txt | 1 +
.../cassandra/db/UnfilteredDeserializer.java| 115 ---
...bles-legacy_ka_14766-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Data.db | Bin 0 -> 103 bytes
...gacy_tables-legacy_ka_14766-ka-1-Digest.sha1 | 1 +
...legacy_tables-legacy_ka_14766-ka-1-Filter.db | Bin 0 -> 16 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Index.db | Bin 0 -> 134 bytes
...cy_tables-legacy_ka_14766-ka-1-Statistics.db | Bin 0 -> 4450 bytes
...egacy_tables-legacy_ka_14766-ka-1-Summary.db | Bin 0 -> 92 bytes
.../legacy_tables-legacy_ka_14766-ka-1-TOC.txt | 8 ++
.../cassandra/io/sstable/LegacySSTableTest.java | 27 -
11 files changed, 112 insertions(+), 40 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/45937def/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 195c97c..43628b2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.18
+ * DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
* Handle failures in parallelAllSSTableOperation
(cleanup/upgradesstables/etc) (CASSANDRA-14657)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/45937def/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
--
diff --git a/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
b/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
index 0aa5741..62ad76a 100644
--- a/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
+++ b/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
@@ -245,10 +245,14 @@ public abstract class UnfilteredDeserializer
// The next Unfiltered to return, computed by hasNext()
private Unfiltered next;
-// A temporary storage for an unfiltered that isn't returned next but
should be looked at just afterwards
-private Unfiltered saved;
-private boolean isFirst = true;
+// Saved position in the input after the next Unfiltered that will be
consumed
+private long nextConsumedPosition;
+
+// A temporary storage for an Unfiltered that isn't returned next but
should be looked at just afterwards
+private Stash stash;
+
+private boolean couldBeStartOfPartition = true;
// The Unfiltered as read from the old format input
private final UnfilteredIterator iterator;
@@ -258,7 +262,15 @@ public abstract class UnfilteredDeserializer
// Tracks the size of the last LegacyAtom read from disk, because this
needs to be accounted
// for when marking lastConsumedPosition after readNext/skipNext
-private long bytesReadForNextAtom;
+// Reading/skipping an Unfiltered consumes LegacyAtoms from the
underlying legacy atom iterator
+// e.g. hasNext() -> iterator.hasNext() -> iterator.readRow() ->
atoms.next()
+// The stop condition of the loop which groups legacy atoms into rows
causes that AtomIterator
+// to read in the first atom which doesn't belong in the row. So by
that point, our position
+// is actually past the end of the next Unfiltered. To compensate, we
record the size of
+// the last LegacyAtom read and subtract it from the current position
when we calculate lastConsumedPosition.
+// If we don't, then when reading an indexed block, we can over
correct and may think that we've
+// exhausted the block before we actually have.
+private long bytesReadForNextAtom = 0L;
private OldFormatDeserializer(CFMetaData metadata,
[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11
Merge branch 'cassandra-3.0' into cassandra-3.11
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4d3f5a32
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4d3f5a32
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4d3f5a32
Branch: refs/heads/cassandra-3.11
Commit: 4d3f5a32b2cc821f74fbece183ededdd91d195bf
Parents: 4f30dae 45937de
Author: Aleksey Yeshchenko
Authored: Tue Sep 25 17:03:57 2018 +0100
Committer: Aleksey Yeshchenko
Committed: Tue Sep 25 17:03:57 2018 +0100
--
CHANGES.txt | 1 +
.../cassandra/db/UnfilteredDeserializer.java| 115 ---
...bles-legacy_ka_14766-ka-1-CompressionInfo.db | Bin 0 -> 43 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Data.db | Bin 0 -> 103 bytes
...gacy_tables-legacy_ka_14766-ka-1-Digest.sha1 | 1 +
...legacy_tables-legacy_ka_14766-ka-1-Filter.db | Bin 0 -> 16 bytes
.../legacy_tables-legacy_ka_14766-ka-1-Index.db | Bin 0 -> 134 bytes
...cy_tables-legacy_ka_14766-ka-1-Statistics.db | Bin 0 -> 4450 bytes
...egacy_tables-legacy_ka_14766-ka-1-Summary.db | Bin 0 -> 92 bytes
.../legacy_tables-legacy_ka_14766-ka-1-TOC.txt | 8 ++
.../cassandra/io/sstable/LegacySSTableTest.java | 27 -
11 files changed, 112 insertions(+), 40 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d3f5a32/CHANGES.txt
--
diff --cc CHANGES.txt
index f04cae1,43628b2..a4fa705
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,5 -1,5 +1,6 @@@
-3.0.18
+3.11.4
+Merged from 3.0:
+ * DESC order reads can fail to return the last Unfiltered in the partition
(CASSANDRA-14766)
* Fix corrupted collection deletions for dropped columns in 3.0 <-> 2.{1,2}
messages (CASSANDRA-14568)
* Fix corrupted static collection deletions in 3.0 <-> 2.{1,2} messages
(CASSANDRA-14568)
* Handle failures in parallelAllSSTableOperation
(cleanup/upgradesstables/etc) (CASSANDRA-14657)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d3f5a32/src/java/org/apache/cassandra/db/UnfilteredDeserializer.java
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d3f5a32/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java
--
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14672) After deleting data in 3.11.3, reads fail with "open marker and close marker have different deletion times"
[
https://issues.apache.org/jira/browse/CASSANDRA-14672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627562#comment-16627562
]
Blake Eggleston commented on CASSANDRA-14672:
-
+1
> After deleting data in 3.11.3, reads fail with "open marker and close marker
> have different deletion times"
> ---
>
> Key: CASSANDRA-14672
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14672
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Environment: CentOS 7, GCE, 9 nodes, 4TB disk/~2TB full each, level
> compaction, timeseries data
>Reporter: Spiros Ioannou
>Assignee: Aleksey Yeschenko
>Priority: Blocker
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> We had 3.11.0, then we upgraded to 3.11.3 last week. We routinely perform
> deletions as the one described below. After upgrading we run the following
> deletion query:
>
> {code:java}
> DELETE FROM measurement_events_dbl WHERE measurement_source_id IN (
> 9df798a2-6337-11e8-b52b-42010afa015a, 9df7717e-6337-11e8-b52b-42010afa015a,
> a08b8042-6337-11e8-b52b-42010afa015a, a08e52cc-6337-11e8-b52b-42010afa015a,
> a08e6654-6337-11e8-b52b-42010afa015a, a08e6104-6337-11e8-b52b-42010afa015a,
> a08e6c76-6337-11e8-b52b-42010afa015a, a08e5a9c-6337-11e8-b52b-42010afa015a,
> a08bcc50-6337-11e8-b52b-42010afa015a) AND year IN (2018) AND measurement_time
> >= '2018-07-19 04:00:00'{code}
>
> Immediately after that, trying to read the last value produces an error:
> {code:java}
> select * FROM measurement_events_dbl WHERE measurement_source_id =
> a08b8042-6337-11e8-b52b-42010afa015a AND year IN (2018) order by
> measurement_time desc limit 1;
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
> message="Operation failed - received 0 responses and 2 failures"
> info={'failures': 2, 'received_responses': 0, 'required_responses': 1,
> 'consistency': 'ONE'}{code}
>
> And the following exception:
> {noformat}
> WARN [ReadStage-4] 2018-08-29 06:59:53,505
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-4,5,main]: {}
> java.lang.RuntimeException: java.lang.IllegalStateException:
> UnfilteredRowIterator for pvpms_mevents.measurement_events_dbl has an illegal
> RT bounds sequence: open marker and close marker have different deletion times
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2601)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_181]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> [apache-cassandra-3.11.3.jar:3.11.3]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
> [apache-cassandra-3.11.3.jar:3.11.3]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_181]
> Caused by: java.lang.IllegalStateException: UnfilteredRowIterator for
> pvpms_mevents.measurement_events_dbl has an illegal RT bounds sequence: open
> marker and close marker have different deletion times
> at
> org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.ise(RTBoundValidator.java:103)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.transform.RTBoundValidator$RowsTransformation.applyToMarker(RTBoundValidator.java:81)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:148)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:136)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:187)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:180)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> at
>
[jira] [Commented] (CASSANDRA-14782) Make DatabaseDescriptor.getNativeTransportMaxFrameSize() a hotprop
[
https://issues.apache.org/jira/browse/CASSANDRA-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627536#comment-16627536
]
Chris Lohfink commented on CASSANDRA-14782:
---
bq. Is this something that an operator would like to change while the database
is running
Yes, definitely. Even if the max was lowered to 64mb.
bq. What happens when they don't match across various nodes in the cluster?
Only the coordinator would throw it away, if large request goes to a different
host it would still send the large mutation to the replicas to get thrown away
when applied to commit log. This value does not effect inter node messages,
only CQL.
> Make DatabaseDescriptor.getNativeTransportMaxFrameSize() a hotprop
> --
>
> Key: CASSANDRA-14782
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14782
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jordan West
>Priority: Major
>
> Large mutations are rejected by the commit log
> (https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L254)
> but when {{totalSize}} is significantly greater than the
> {{MAX_MUTATION_SIZE}} the damage to the node may already done. Large
> mutations cause large buffers to be allocated and can lead to GC trashing and
> generally bad node health.
> It should be possible to set a size above which the native protocol rejects
> messages without materializing them into objects and passing them downstream.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14766) DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627512#comment-16627512
]
Benedict commented on CASSANDRA-14766:
--
+1
> DESC order reads can fail to return the last Unfiltered in the partition in a
> legacy sstable
>
>
> Key: CASSANDRA-14766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14766
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> {{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
> {{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
> But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
> If that last block, when iterating backwards, only has two {{Unfiltered}},
> the first one will be returned, and the last one won’t as the reverse
> iterator would incorrectly things that the deserisalizer is past the index
> block, despite still having one {{Unfiltered}} unreturned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14766) DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627426#comment-16627426
]
Aleksey Yeschenko edited comment on CASSANDRA-14766 at 9/25/18 2:41 PM:
3.0: [code|https://github.com/iamaleksey/cassandra/commits/14766-3.0],
[CI|https://circleci.com/workflow-run/b86af556-5675-4a83-8de8-21941175608f]
3.11: [code|https://github.com/iamaleksey/cassandra/commits/14766-3.11],
[CI|https://circleci.com/workflow-run/d23b37c9-225a-4e13-85fd-484bda81c37b]
A small dtest for illustration (in addition to a regression unit test in C*
repo) can be found
[here|https://github.com/iamaleksey/cassandra-dtest/commits/14766].
was (Author: iamaleksey):
3.0: [code|https://github.com/iamaleksey/cassandra/commits/14766-3.0],
[CI|https://circleci.com/workflow-run/a0331573-f2eb-43fd-a3c0-7388bafee566]
3.11: [code|https://github.com/iamaleksey/cassandra/commits/14766-3.11],
[CI|https://circleci.com/workflow-run/1a858cdb-138d-471a-bef5-fc564a143fa4]
A small dtest for illustration (in addition to a regression unit test in C*
repo) can be found
[here|https://github.com/iamaleksey/cassandra-dtest/commits/14766].
> DESC order reads can fail to return the last Unfiltered in the partition in a
> legacy sstable
>
>
> Key: CASSANDRA-14766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14766
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> {{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
> {{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
> But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
> If that last block, when iterating backwards, only has two {{Unfiltered}},
> the first one will be returned, and the last one won’t as the reverse
> iterator would incorrectly things that the deserisalizer is past the index
> block, despite still having one {{Unfiltered}} unreturned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14766) DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627454#comment-16627454
]
Aleksey Yeschenko commented on CASSANDRA-14766:
---
Argh. You are right. Not sure how I missed it. Pushed the updates.
> DESC order reads can fail to return the last Unfiltered in the partition in a
> legacy sstable
>
>
> Key: CASSANDRA-14766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14766
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> {{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
> {{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
> But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
> If that last block, when iterating backwards, only has two {{Unfiltered}},
> the first one will be returned, and the last one won’t as the reverse
> iterator would incorrectly things that the deserisalizer is past the index
> block, despite still having one {{Unfiltered}} unreturned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14766) DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627453#comment-16627453
]
Sam Tunnicliffe commented on CASSANDRA-14766:
-
+1
The fact that we're now resetting {{couldBeStartOfPartition}} in
{{clearState}}, which wasn't done before probably fixes an overlooked edge case
in CASSANDRA-13236. We greedily read the static row in
{{AbstractSSTableIterator}}'s constructor, where {{isFirst}}
({{couldBeStartOfPartition}} as was) would trigger the swapping in the presence
of the required tombstone. {{IndexState::setToBlock}} attempts to skip past the
static row if we end up iterating backward to block 0 so we don't re-read the
static row, but without resetting this flag it would only skip past the RT,
leaving the statics to be read next which would then hit the the error from
13236.
> DESC order reads can fail to return the last Unfiltered in the partition in a
> legacy sstable
>
>
> Key: CASSANDRA-14766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14766
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> {{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
> {{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
> But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
> If that last block, when iterating backwards, only has two {{Unfiltered}},
> the first one will be returned, and the last one won’t as the reverse
> iterator would incorrectly things that the deserisalizer is past the index
> block, despite still having one {{Unfiltered}} unreturned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14766) DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627448#comment-16627448
]
Benedict commented on CASSANDRA-14766:
--
one tiny nit: should probably set {{couldBeStartOfPartition = false}} outside
of the {{if}} branch, so we don't unnecessarily perform the RT tests.
It shouldn't have any impact besides possibly some probably immeasurable
performance cost, but probably better that way.
> DESC order reads can fail to return the last Unfiltered in the partition in a
> legacy sstable
>
>
> Key: CASSANDRA-14766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14766
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> {{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
> {{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
> But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
> If that last block, when iterating backwards, only has two {{Unfiltered}},
> the first one will be returned, and the last one won’t as the reverse
> iterator would incorrectly things that the deserisalizer is past the index
> block, despite still having one {{Unfiltered}} unreturned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14766) DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-14766:
--
Description:
{{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
{{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
If that last block, when iterating backwards, only has two {{Unfiltered}}, the
first one will be returned, and the last one won’t as the reverse iterator
would incorrectly things that the deserisalizer is past the index block,
despite still having one {{Unfiltered}} unreturned.
> DESC order reads can fail to return the last Unfiltered in the partition in a
> legacy sstable
>
>
> Key: CASSANDRA-14766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14766
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> {{OldFormatDeserializer}}’s {{hasNext()}} method can and will consume two
> {{Unfiltered}} from the underlying iterator in some scenarios - intentionally.
> But in doing that it’s losing intermediate state of {{lastConsumedPosition}}.
> If that last block, when iterating backwards, only has two {{Unfiltered}},
> the first one will be returned, and the last one won’t as the reverse
> iterator would incorrectly things that the deserisalizer is past the index
> block, despite still having one {{Unfiltered}} unreturned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14766) DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-14766: -- Summary: DESC order reads can fail to return the last Unfiltered in the partition in a legacy sstable (was: TBD) > DESC order reads can fail to return the last Unfiltered in the partition in a > legacy sstable > > > Key: CASSANDRA-14766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14766 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Major > Fix For: 3.0.x, 3.11.x > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14766) TBD
[ https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-14766: -- Status: Patch Available (was: Open) > TBD > --- > > Key: CASSANDRA-14766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14766 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Major > Fix For: 3.0.x, 3.11.x > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14766) TBD
[ https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-14766: -- Reviewers: Benedict, Sam Tunnicliffe > TBD > --- > > Key: CASSANDRA-14766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14766 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Major > Fix For: 3.0.x, 3.11.x > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14766) TBD
[ https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-14766: -- Component/s: Local Write-Read Paths > TBD > --- > > Key: CASSANDRA-14766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14766 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Major > Fix For: 3.0.x, 3.11.x > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14766) TBD
[ https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627426#comment-16627426 ] Aleksey Yeschenko commented on CASSANDRA-14766: --- 3.0: [code|https://github.com/iamaleksey/cassandra/commits/14766-3.0], [CI|https://circleci.com/workflow-run/a0331573-f2eb-43fd-a3c0-7388bafee566] 3.11: [code|https://github.com/iamaleksey/cassandra/commits/14766-3.11], [CI|https://circleci.com/workflow-run/1a858cdb-138d-471a-bef5-fc564a143fa4] A small dtest for illustration (in addition to a regression unit test in C* repo) can be found [here|https://github.com/iamaleksey/cassandra-dtest/commits/14766]. > TBD > --- > > Key: CASSANDRA-14766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14766 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Major > Fix For: 3.0.x, 3.11.x > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14766) TBD
[ https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-14766: -- Fix Version/s: (was: 4.0.x) > TBD > --- > > Key: CASSANDRA-14766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14766 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Major > Fix For: 3.0.x, 3.11.x > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14766) TBD
[ https://issues.apache.org/jira/browse/CASSANDRA-14766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-14766: -- Fix Version/s: 4.0.x 3.11.x 3.0.x > TBD > --- > > Key: CASSANDRA-14766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14766 > Project: Cassandra > Issue Type: Bug > Components: Local Write-Read Paths >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Major > Fix For: 3.0.x, 3.11.x > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14789) Configuring nodetool from a file
Jan Karlsson created CASSANDRA-14789: Summary: Configuring nodetool from a file Key: CASSANDRA-14789 URL: https://issues.apache.org/jira/browse/CASSANDRA-14789 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Jan Karlsson Assignee: Jan Karlsson Fix For: 4.x Nodetool has a lot of options that can be set. SSL can be configured through a file[1], but most other parameters must be provided when running the command. It would be helpful to be able to configure its parameters through a file much like how cqlsh can be configured[2]. [1] https://issues.apache.org/jira/browse/CASSANDRA-9090 [2] [https://docs.datastax.com/en/cql/3.3/cql/cql_reference/cqlshUsingCqlshrc.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14787) nodetool status "Load" columns has wrong width
[
https://issues.apache.org/jira/browse/CASSANDRA-14787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627340#comment-16627340
]
Lapo Luchini edited comment on CASSANDRA-14787 at 9/25/18 1:55 PM:
---
The same cluster gives a "correct" answer when called from a different host
with LANG environment (and others?) are set to Italian:
{code:java}
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns (effective) Host ID ...
UN server1.andxor.it 11.11 MiB 256 39,6% ...
UN server2.andxor.it 32.04 MiB 256 41,8% ...
UN server3.andxor.it 519.3 KiB 256 40,0% ...
UN server4.andxor.it 10.95 MiB 256 40,3% ...
UN server5.andxor.it 11.03 MiB 256 38,4% ...
{code}
was (Author: l...@lapo.it):
The same cluster gives a "correct" answer when LANG environment (and others?)
are set to Italian:
{code:java}
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns (effective) Host ID ...
UN server1.andxor.it 11.11 MiB 256 39,6% ...
UN server2.andxor.it 32.04 MiB 256 41,8% ...
UN server3.andxor.it 519.3 KiB 256 40,0% ...
UN server4.andxor.it 10.95 MiB 256 40,3% ...
UN server5.andxor.it 11.03 MiB 256 38,4% ...
{code}
> nodetool status "Load" columns has wrong width
> --
>
> Key: CASSANDRA-14787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14787
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Lapo Luchini
>Priority: Trivial
>
> Using Cassandra 3.11.2 on FreeBSD, I get:
> {code:java}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID ...
> UN server1.andxor.it 11.11 MiB 256 39.6% ...
> UN server2.andxor.it 32.04 MiB 256 41.8% ...
> UN server3.andxor.it 519.33 KiB 256 40.0% ...
> UN server4.andxor.it 10.95 MiB 256 40.3% ...
> UN server5.andxor.it 11.03 MiB 256 38.4% ...
> {code}
> AFAICT this is caused by {{"%-9s"}} in
> [Status.java:292|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/tools/nodetool/Status.java#L292]
> which should be probably a 10 instead of 9.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14787) nodetool status "Load" columns has wrong width
[
https://issues.apache.org/jira/browse/CASSANDRA-14787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627340#comment-16627340
]
Lapo Luchini edited comment on CASSANDRA-14787 at 9/25/18 1:52 PM:
---
The same cluster gives a "correct" answer when LANG environment (and others?)
are set to Italian:
{code:java}
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns (effective) Host ID ...
UN server1.andxor.it 11.11 MiB 256 39,6% ...
UN server2.andxor.it 32.04 MiB 256 41,8% ...
UN server3.andxor.it 519.3 KiB 256 40,0% ...
UN server4.andxor.it 10.95 MiB 256 40,3% ...
UN server5.andxor.it 11.03 MiB 256 38,4% ...
{code}
was (Author: l...@lapo.it):
I don't know why (maybe different decimals?), but today the same cluster gives
a "correct" answer:
{code}
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns (effective) Host ID ...
UN server1.andxor.it 11.11 MiB 256 39,6% ...
UN server2.andxor.it 32.04 MiB 256 41,8% ...
UN server3.andxor.it 519.3 KiB 256 40,0% ...
UN server4.andxor.it 10.95 MiB 256 40,3% ...
UN server5.andxor.it 11.03 MiB 256 38,4% ...
{code}
Nothing was updated and no configuration changed.
> nodetool status "Load" columns has wrong width
> --
>
> Key: CASSANDRA-14787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14787
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Lapo Luchini
>Priority: Trivial
>
> Using Cassandra 3.11.2 on FreeBSD, I get:
> {code:java}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID ...
> UN server1.andxor.it 11.11 MiB 256 39.6% ...
> UN server2.andxor.it 32.04 MiB 256 41.8% ...
> UN server3.andxor.it 519.33 KiB 256 40.0% ...
> UN server4.andxor.it 10.95 MiB 256 40.3% ...
> UN server5.andxor.it 11.03 MiB 256 38.4% ...
> {code}
> AFAICT this is caused by {{"%-9s"}} in
> [Status.java:292|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/tools/nodetool/Status.java#L292]
> which should be probably a 10 instead of 9.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14787) nodetool status "Load" columns has wrong width
[
https://issues.apache.org/jira/browse/CASSANDRA-14787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627340#comment-16627340
]
Lapo Luchini commented on CASSANDRA-14787:
--
I don't know why (maybe different decimals?), but today the same cluster gives
a "correct" answer:
{code}
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns (effective) Host ID ...
UN server1.andxor.it 11.11 MiB 256 39,6% ...
UN server2.andxor.it 32.04 MiB 256 41,8% ...
UN server3.andxor.it 519.3 KiB 256 40,0% ...
UN server4.andxor.it 10.95 MiB 256 40,3% ...
UN server5.andxor.it 11.03 MiB 256 38,4% ...
{code}
Nothing was updated and no configuration changed.
> nodetool status "Load" columns has wrong width
> --
>
> Key: CASSANDRA-14787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14787
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Lapo Luchini
>Priority: Trivial
>
> Using Cassandra 3.11.2 on FreeBSD, I get:
> {code:java}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID ...
> UN server1.andxor.it 11.11 MiB 256 39.6% ...
> UN server2.andxor.it 32.04 MiB 256 41.8% ...
> UN server3.andxor.it 519.33 KiB 256 40.0% ...
> UN server4.andxor.it 10.95 MiB 256 40.3% ...
> UN server5.andxor.it 11.03 MiB 256 38.4% ...
> {code}
> AFAICT this is caused by {{"%-9s"}} in
> [Status.java:292|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/tools/nodetool/Status.java#L292]
> which should be probably a 10 instead of 9.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14634) Review Handling Crypto Rules and update ECCN page if needed
[
https://issues.apache.org/jira/browse/CASSANDRA-14634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627248#comment-16627248
]
Henri Yandell commented on CASSANDRA-14634:
---
Thanks Nate :)
> Review Handling Crypto Rules and update ECCN page if needed
> ---
>
> Key: CASSANDRA-14634
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14634
> Project: Cassandra
> Issue Type: Task
>Reporter: Henri Yandell
>Assignee: Nate McCall
>Priority: Blocker
> Labels: security
>
> It is suggested in LEGAL-358 that Cassandra is containing/using cryptographic
> functions and does not have an entry on the ECCN page (
> [http://www.apache.org/licenses/exports/] ).
> See [http://www.apache.org/dev/crypto.html] to review and confirm whether you
> should add something to the ECCN page, and if needed, please do so.
> The text in LEGAL-358 was:
>
> [~zznate] added a comment - 26/Dec/17 14:58
> Ok, I think I have this sorted. Our entry on that page will need to look like
> this:
> {noformat}
> Product Name VersionsECCNControlled Source
> Apache Cassandra development 5D002 ASF
> 0.8 and later 5D002 ASF
> {noformat}
> We first added SSL support in 0.8 via CASSANDRA-1567
> We rely solely on the JDK functionality for all encryption.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14773) Overflow of 32-bit integer during compaction.
[
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-14773:
-
Reviewer: Benedict
> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Vladimir Bukhtoyarov
>Priority: Critical
> Fix For: 4.x
>
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from
> CPU and memory perspective. Hovewer this improvement introduces the bug in
> rounding. When rounding the expriration time which is close to
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow
> happens(because in scope of -CASSANDRA-13444-) data type for point was
> changed from Long to Integer in order to reduce memory footprint), as result
> point became negative and acts as silent poison for internal structures of
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*.
> Then depending of point intervals:
> * The TombstoneHistogram produces wrong values when interval of points is
> less then binSize, it is not critical.
> * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point
> intervals is great then binSize, this case is very critical.
>
> This is pull request [https://github.com/apache/cassandra/pull/273] that
> reproduces the issue and provides the fix.
>
> The stacktrace when running(on codebase without fix)
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
> Source)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
>
> The stacktrace when running(on codebase without fix)
> *testMathOverflowDuringRoundingOfLargeTimestamp* with enabled -ea JVM
[jira] [Commented] (CASSANDRA-14773) Overflow of 32-bit integer during compaction.
[
https://issues.apache.org/jira/browse/CASSANDRA-14773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627177#comment-16627177
]
Benedict commented on CASSANDRA-14773:
--
No, thanks [~vladimir.bukhtoyarov]. I think it's complete. I just need to
find time to run it through CI and do a final review before committing.
> Overflow of 32-bit integer during compaction.
> -
>
> Key: CASSANDRA-14773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14773
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Vladimir Bukhtoyarov
>Assignee: Vladimir Bukhtoyarov
>Priority: Critical
> Fix For: 4.x
>
>
> In scope of CASSANDRA-13444 the compaction was significantly improved from
> CPU and memory perspective. Hovewer this improvement introduces the bug in
> rounding. When rounding the expriration time which is close to
> *Cell.MAX_DELETION_TIME*(it is just *Integer.MAX_VALUE*) the math overflow
> happens(because in scope of -CASSANDRA-13444-) data type for point was
> changed from Long to Integer in order to reduce memory footprint), as result
> point became negative and acts as silent poison for internal structures of
> StreamingTombstoneHistogramBuilder like *DistanceHolder* and *DataHolder*.
> Then depending of point intervals:
> * The TombstoneHistogram produces wrong values when interval of points is
> less then binSize, it is not critical.
> * Compaction crashes with ArrayIndexOutOfBoundsException if amount of point
> intervals is great then binSize, this case is very critical.
>
> This is pull request [https://github.com/apache/cassandra/pull/273] that
> reproduces the issue and provides the fix.
>
> The stacktrace when running(on codebase without fix)
> *testMathOverflowDuringRoundingOfLargeTimestamp* without -ea JVM flag
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$DistanceHolder.add(StreamingTombstoneHistogramBuilder.java:208)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushValue(StreamingTombstoneHistogramBuilder.java:140)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$$Lambda$1/1967205423.consume(Unknown
> Source)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder$Spool.forEach(StreamingTombstoneHistogramBuilder.java:574)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.flushHistogram(StreamingTombstoneHistogramBuilder.java:124)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilder.build(StreamingTombstoneHistogramBuilder.java:184)
> at
> org.apache.cassandra.utils.streamhist.StreamingTombstoneHistogramBuilderTest.testMathOverflowDuringRoundingOfLargeTimestamp(StreamingTombstoneHistogramBuilderTest.java:183)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
> at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:159)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
