[jira] [Updated] (CASSANDRA-14968) Investigate GPG signing of deb and rpm repositories via bintray
[ https://issues.apache.org/jira/browse/CASSANDRA-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14968: --- Description: Currently, the release manager uploads debian packages and built/signed metadata to a generic bintray repository. Perhaps we could utilize the GPG signing feature of the repository, post-upload, via the bintray GPG signing feature. https://www.jfrog.com/confluence/display/BT/Managing+Uploaded+Content#ManagingUploadedContent-GPGSigning Depends on CASSANDRA-14967 was: Currently, the release manager uploads debian packages and built/signed metadata to a generic bintray repository. Perhaps we could utilize the GPG signing feature of the repository, post-upload, via the bintray GPG signing feature. Depends on CASSANDRA-14967 > Investigate GPG signing of deb and rpm repositories via bintray > --- > > Key: CASSANDRA-14968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14968 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Shuler >Priority: Major > Labels: packaging > > Currently, the release manager uploads debian packages and built/signed > metadata to a generic bintray repository. Perhaps we could utilize the GPG > signing feature of the repository, post-upload, via the bintray GPG signing > feature. > https://www.jfrog.com/confluence/display/BT/Managing+Uploaded+Content#ManagingUploadedContent-GPGSigning > Depends on CASSANDRA-14967 -- 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-14967) Work with INFRA to migrate to "Debian" type repo at bintray
[ https://issues.apache.org/jira/browse/CASSANDRA-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14967: --- Summary: Work with INFRA to migrate to "Debian" type repo at bintray (was: Migrate to "Debian" type repo at bintray) > Work with INFRA to migrate to "Debian" type repo at bintray > --- > > Key: CASSANDRA-14967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14967 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Shuler >Priority: Major > Labels: packaging > > Currently, the deb package repo at bintray is configured as a generic one. > Let's migrate to a new "Debian" type repository, which should allow us to > possibly configure GPG signing. -- 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-14966) Work with INFRA to create RPM repository at bintray
Michael Shuler created CASSANDRA-14966: -- Summary: Work with INFRA to create RPM repository at bintray Key: CASSANDRA-14966 URL: https://issues.apache.org/jira/browse/CASSANDRA-14966 Project: Cassandra Issue Type: Bug Reporter: Michael Shuler Similar to the current deb package repo at bintray, let's migrate to an rpm repo at bintray. Currently the rpm repo is in-tree. -- 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-14967) Migrate to "Debian" type repo at bintray
[ https://issues.apache.org/jira/browse/CASSANDRA-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14967: --- Description: Currently, the deb package repo at bintray is configured as a generic one. Let's migrate to a new "Debian" type repository, which should allow us to possibly configure GPG signing. (was: Currently, the deb package repo at bintray is configured as a generic one. Let's migrate to a "Debian" type repository.) > Migrate to "Debian" type repo at bintray > > > Key: CASSANDRA-14967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14967 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Shuler >Priority: Major > Labels: packaging > > Currently, the deb package repo at bintray is configured as a generic one. > Let's migrate to a new "Debian" type repository, which should allow us to > possibly configure GPG signing. -- 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-14968) Investigate GPG signing of deb and rpm repositories via bintray
Michael Shuler created CASSANDRA-14968: -- Summary: Investigate GPG signing of deb and rpm repositories via bintray Key: CASSANDRA-14968 URL: https://issues.apache.org/jira/browse/CASSANDRA-14968 Project: Cassandra Issue Type: Bug Reporter: Michael Shuler Currently, the release manager uploads debian packages and built/signed metadata to a generic bintray repository. Perhaps we could utilize the GPG signing feature of the repository, post-upload, via the bintray GPG signing feature. Depends on CASSANDRA-14967 -- 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-14967) Migrate to "Debian" type repo at bintray
Michael Shuler created CASSANDRA-14967: -- Summary: Migrate to "Debian" type repo at bintray Key: CASSANDRA-14967 URL: https://issues.apache.org/jira/browse/CASSANDRA-14967 Project: Cassandra Issue Type: Bug Reporter: Michael Shuler Currently, the deb package repo at bintray is configured as a generic one. Let's migrate to a "Debian" type repository. -- 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-14966) Work with INFRA to create RPM repository at bintray
[ https://issues.apache.org/jira/browse/CASSANDRA-14966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14966: --- Labels: packaging (was: ) > Work with INFRA to create RPM repository at bintray > --- > > Key: CASSANDRA-14966 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14966 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Shuler >Priority: Major > Labels: packaging > > Similar to the current deb package repo at bintray, let's migrate to an rpm > repo at bintray. Currently the rpm repo is in-tree. -- 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] [Issue Comment Deleted] (CASSANDRA-14959) ReadCommandVerbHandler validateTransientStatus class cast exception
[ https://issues.apache.org/jira/browse/CASSANDRA-14959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-14959: --- Comment: was deleted (was: Uh, this appear to be failing quite hard now. I removed the commit for now until I can figure out what is going on.) > ReadCommandVerbHandler validateTransientStatus class cast exception > > > Key: CASSANDRA-14959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14959 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Causes a test failure, looks like it should just use instanceof. > {noformat} > Exception in thread Thread-1: > Traceback (most recent call last): > File > "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", > line 917, in _bootstrap_inner > self.run() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 189, in run > self.scan_and_report() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 182, 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.7/site-packages/_pytest/outcomes.py", > line 97, in fail > raise Failed(msg=msg, pytrace=pytrace) > Failed: Error details: > Errors seen in logs for: node1 > node1: ERROR [ReadStage-2] 2019-01-03 14:02:43,704 > AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread > Thread[ReadStage-2,5,main] > java.lang.ClassCastException: > org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to > org.apache.cassandra.db.SinglePartitionReadCommand > at > org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:85) > 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:115) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > FAILED > upgrade_tests/cql_tests.py:2869 > (TestCQLNodes3RF3_Upgrade_indev_3_11_x_To_indev_trunk.test_edge_2i_on_complex_pk) > {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
cassandra git commit: ReadCommandVerbHandler validateTransientStatus class cast exception
Repository: cassandra Updated Branches: refs/heads/trunk ef1817a75 -> f04948891 ReadCommandVerbHandler validateTransientStatus class cast exception Patch by Ariel Weisberg; Reviewed by Alex Petrov for CASSANDRA-14959 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f0494889 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f0494889 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f0494889 Branch: refs/heads/trunk Commit: f0494889176873b3f68ae14cc5f1d9dcbc189da9 Parents: ef1817a Author: Ariel Weisberg Authored: Thu Jan 3 14:12:59 2019 -0500 Committer: Ariel Weisberg Committed: Mon Jan 7 17:24:28 2019 -0500 -- src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0494889/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java -- diff --git a/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java b/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java index 2759e78..e39e8a8 100644 --- a/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java +++ b/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java @@ -81,7 +81,7 @@ public class ReadCommandVerbHandler implements IVerbHandler ReadCommand command = message.payload; Token token; -if (command.isLimitedToOnePartition()) +if (command instanceof SinglePartitionReadCommand) token = ((SinglePartitionReadCommand) command).partitionKey().getToken(); else token = ((PartitionRangeReadCommand) command).dataRange().keyRange().right.getToken(); - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14871) Severe concurrency issues in STCS,DTCS,TWCS,TMD.Topology,TypeParser
[ https://issues.apache.org/jira/browse/CASSANDRA-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736454#comment-16736454 ] Blake Eggleston commented on CASSANDRA-14871: - [~snazy] is this ready to commit? > Severe concurrency issues in STCS,DTCS,TWCS,TMD.Topology,TypeParser > --- > > Key: CASSANDRA-14871 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14871 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Robert Stupp >Assignee: Robert Stupp >Priority: Critical > Fix For: 4.0, 3.0.x, 3.11.x > > > There are a couple of places in the code base that do not respect that > j.u.HashMap + related classes are not thread safe and some parts rely on > internals of the implementation of HM, which can change. > We have observed failures like {{NullPointerException}} and > {{ConcurrentModificationException}} as well as wrong behavior. > Affected areas in the code base: > * {{SizeTieredCompactionStrategy}} > * {{DateTieredCompactionStrategy}} > * {{TimeWindowCompactionStrategy}} > * {{TokenMetadata.Topology}} > * {{TypeParser}} > * streaming / concurrent access to {{LifecycleTransaction}} (handled in > CASSANDRA-14554) > While the patches for the compaction strategies + {{TypeParser}} are pretty > straight forward, the patch for {{TokenMetadata.Topology}} requires it to be > made immutable. -- 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-14959) ReadCommandVerbHandler validateTransientStatus class cast exception
[ https://issues.apache.org/jira/browse/CASSANDRA-14959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736453#comment-16736453 ] Ariel Weisberg commented on CASSANDRA-14959: Uh, this appear to be failing quite hard now. I removed the commit for now until I can figure out what is going on. > ReadCommandVerbHandler validateTransientStatus class cast exception > > > Key: CASSANDRA-14959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14959 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Causes a test failure, looks like it should just use instanceof. > {noformat} > Exception in thread Thread-1: > Traceback (most recent call last): > File > "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", > line 917, in _bootstrap_inner > self.run() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 189, in run > self.scan_and_report() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 182, 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.7/site-packages/_pytest/outcomes.py", > line 97, in fail > raise Failed(msg=msg, pytrace=pytrace) > Failed: Error details: > Errors seen in logs for: node1 > node1: ERROR [ReadStage-2] 2019-01-03 14:02:43,704 > AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread > Thread[ReadStage-2,5,main] > java.lang.ClassCastException: > org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to > org.apache.cassandra.db.SinglePartitionReadCommand > at > org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:85) > 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:115) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > FAILED > upgrade_tests/cql_tests.py:2869 > (TestCQLNodes3RF3_Upgrade_indev_3_11_x_To_indev_trunk.test_edge_2i_on_complex_pk) > {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
[cassandra] Git Push Summary [forced push!] [Forced Update!]
Repository: cassandra Updated Branches: refs/heads/trunk f04948891 -> ef1817a75 (forced update) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14965) Write the Data Modeling Documentation Section
[ https://issues.apache.org/jira/browse/CASSANDRA-14965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella reassigned CASSANDRA-14965: Assignee: Joseph Lynch > Write the Data Modeling Documentation Section > - > > Key: CASSANDRA-14965 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14965 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Minor > > It would be good to fill out the data modeling > [section|http://cassandra.apache.org/doc/latest/data_modeling/index.html?highlight=todo] > of the website. I plan to fill it out with a discussion of the following: > 1. CQL Query Modeling == Data Model > 2. Enough storage explanation to justify partition/clustering column choices > 3. Data modeling best practices (theoretical and practical limits, partition > sizes, column sizes, etc ... > 4. Examples of different common data models (e.g. forward index, reverse > index, time series, json blob storage, etc ...) -- 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-14965) Write the Data Modeling Documentation Section
Joseph Lynch created CASSANDRA-14965: Summary: Write the Data Modeling Documentation Section Key: CASSANDRA-14965 URL: https://issues.apache.org/jira/browse/CASSANDRA-14965 Project: Cassandra Issue Type: Improvement Components: Documentation/Website Reporter: Joseph Lynch It would be good to fill out the data modeling [section|http://cassandra.apache.org/doc/latest/data_modeling/index.html?highlight=todo] of the website. I plan to fill it out with a discussion of the following: 1. CQL Query Modeling == Data Model 2. Enough storage explanation to justify partition/clustering column choices 3. Data modeling best practices (theoretical and practical limits, partition sizes, column sizes, etc ... 4. Examples of different common data models (e.g. forward index, reverse index, time series, json blob storage, etc ...) -- 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-14959) ReadCommandVerbHandler validateTransientStatus class cast exception
[ https://issues.apache.org/jira/browse/CASSANDRA-14959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-14959: --- Resolution: Fixed Reviewers: Alex Petrov Status: Resolved (was: Ready to Commit) > ReadCommandVerbHandler validateTransientStatus class cast exception > > > Key: CASSANDRA-14959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14959 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Causes a test failure, looks like it should just use instanceof. > {noformat} > Exception in thread Thread-1: > Traceback (most recent call last): > File > "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", > line 917, in _bootstrap_inner > self.run() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 189, in run > self.scan_and_report() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 182, 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.7/site-packages/_pytest/outcomes.py", > line 97, in fail > raise Failed(msg=msg, pytrace=pytrace) > Failed: Error details: > Errors seen in logs for: node1 > node1: ERROR [ReadStage-2] 2019-01-03 14:02:43,704 > AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread > Thread[ReadStage-2,5,main] > java.lang.ClassCastException: > org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to > org.apache.cassandra.db.SinglePartitionReadCommand > at > org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:85) > 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:115) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > FAILED > upgrade_tests/cql_tests.py:2869 > (TestCQLNodes3RF3_Upgrade_indev_3_11_x_To_indev_trunk.test_edge_2i_on_complex_pk) > {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] [Created] (CASSANDRA-14964) ReadCommandVerbHandler.validateTransient status could better validate range reads cover acceptably replicated ranges
Ariel Weisberg created CASSANDRA-14964: -- Summary: ReadCommandVerbHandler.validateTransient status could better validate range reads cover acceptably replicated ranges Key: CASSANDRA-14964 URL: https://issues.apache.org/jira/browse/CASSANDRA-14964 Project: Cassandra Issue Type: Improvement Components: Consistency/Coordination Reporter: Ariel Weisberg Fix For: 4.0 Right now it's just checking the end of the range is correctly replicated. It really seems like we should check the entire range that is being scanned is correctly replicated. -- 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-14959) ReadCommandVerbHandler validateTransientStatus class cast exception
[ https://issues.apache.org/jira/browse/CASSANDRA-14959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736447#comment-16736447 ] Ariel Weisberg commented on CASSANDRA-14959: Thanks! Committed as [f0494889176873b3f68ae14cc5f1d9dcbc189da9|https://github.com/apache/cassandra/commit/f0494889176873b3f68ae14cc5f1d9dcbc189da9]. > ReadCommandVerbHandler validateTransientStatus class cast exception > > > Key: CASSANDRA-14959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14959 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Causes a test failure, looks like it should just use instanceof. > {noformat} > Exception in thread Thread-1: > Traceback (most recent call last): > File > "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", > line 917, in _bootstrap_inner > self.run() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 189, in run > self.scan_and_report() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 182, 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.7/site-packages/_pytest/outcomes.py", > line 97, in fail > raise Failed(msg=msg, pytrace=pytrace) > Failed: Error details: > Errors seen in logs for: node1 > node1: ERROR [ReadStage-2] 2019-01-03 14:02:43,704 > AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread > Thread[ReadStage-2,5,main] > java.lang.ClassCastException: > org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to > org.apache.cassandra.db.SinglePartitionReadCommand > at > org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:85) > 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:115) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > FAILED > upgrade_tests/cql_tests.py:2869 > (TestCQLNodes3RF3_Upgrade_indev_3_11_x_To_indev_trunk.test_edge_2i_on_complex_pk) > {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
cassandra git commit: ReadCommandVerbHandler validateTransientStatus class cast exception
Repository: cassandra Updated Branches: refs/heads/trunk ef1817a75 -> f04948891 ReadCommandVerbHandler validateTransientStatus class cast exception Patch by Ariel Weisberg; Reviewed by Alex Petrov for CASSANDRA-14959 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/f0494889 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/f0494889 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/f0494889 Branch: refs/heads/trunk Commit: f0494889176873b3f68ae14cc5f1d9dcbc189da9 Parents: ef1817a Author: Ariel Weisberg Authored: Thu Jan 3 14:12:59 2019 -0500 Committer: Ariel Weisberg Committed: Mon Jan 7 17:24:28 2019 -0500 -- src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/f0494889/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java -- diff --git a/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java b/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java index 2759e78..e39e8a8 100644 --- a/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java +++ b/src/java/org/apache/cassandra/db/ReadCommandVerbHandler.java @@ -81,7 +81,7 @@ public class ReadCommandVerbHandler implements IVerbHandler ReadCommand command = message.payload; Token token; -if (command.isLimitedToOnePartition()) +if (command instanceof SinglePartitionReadCommand) token = ((SinglePartitionReadCommand) command).partitionKey().getToken(); else token = ((PartitionRangeReadCommand) command).dataRange().keyRange().right.getToken(); - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14962) Package builds should use source tar artifact as "orig"
[ https://issues.apache.org/jira/browse/CASSANDRA-14962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14962: --- Labels: packaging (was: ) > Package builds should use source tar artifact as "orig" > --- > > Key: CASSANDRA-14962 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14962 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Shuler >Priority: Major > Labels: packaging > > Currently deb and rpm packages build from git, with new builds of original > tarballs. This is incorrect. The ordering should be to build the tar > artifacts, then use the src.tar.gz as the "original" to build the packages > from. -- 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-14963) Release artifacts should be able to be built without being release manager
[ https://issues.apache.org/jira/browse/CASSANDRA-14963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-14963: --- Labels: packaging (was: ) > Release artifacts should be able to be built without being release manager > -- > > Key: CASSANDRA-14963 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14963 > Project: Cassandra > Issue Type: Bug >Reporter: Michael Shuler >Priority: Major > Labels: packaging > > Currently, the release artifact build process does full maven upload of > gpg-signed artifacts and package builds with repo signing. It would be > helpful to be able to build and tag as a committer, then have the gpg signing > as a separate event/process. The builds could be local and staged somewhere, > then a release manager could verify and gpg sign the artifacts. -- 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-14963) Release artifacts should be able to be built without being release manager
Michael Shuler created CASSANDRA-14963: -- Summary: Release artifacts should be able to be built without being release manager Key: CASSANDRA-14963 URL: https://issues.apache.org/jira/browse/CASSANDRA-14963 Project: Cassandra Issue Type: Bug Reporter: Michael Shuler Currently, the release artifact build process does full maven upload of gpg-signed artifacts and package builds with repo signing. It would be helpful to be able to build and tag as a committer, then have the gpg signing as a separate event/process. The builds could be local and staged somewhere, then a release manager could verify and gpg sign the artifacts. -- 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-14962) Package builds should use source tar artifact as "orig"
Michael Shuler created CASSANDRA-14962: -- Summary: Package builds should use source tar artifact as "orig" Key: CASSANDRA-14962 URL: https://issues.apache.org/jira/browse/CASSANDRA-14962 Project: Cassandra Issue Type: Bug Reporter: Michael Shuler Currently deb and rpm packages build from git, with new builds of original tarballs. This is incorrect. The ordering should be to build the tar artifacts, then use the src.tar.gz as the "original" to build the packages from. -- 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-14914) Deserialization Error
[ https://issues.apache.org/jira/browse/CASSANDRA-14914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736249#comment-16736249 ] Jeff Jirsa commented on CASSANDRA-14914: Are you providing a custom timestamp when you issue deletes (USING TIMESTAMP in your insert/update/delete statements)? > Deserialization Error > - > > Key: CASSANDRA-14914 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14914 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core > Environment: I use cassandra 3.9, but I tried to upgrade to 3.11 and > nothing has changed. >Reporter: EDSON VICENTE CARLI JUNIOR >Priority: Critical > Fix For: 3.11.x > > Attachments: mutation4465429258841992355dat > > > > I have a single cassandra, now this error appears when I start the server: > {code:java} > ERROR 11:18:45 Exiting due to error while processing commit log during > initialization. > org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException: > Unexpected error deserializing mutation; saved to > /tmp/mutation4787806670239768067dat. This may be caused by replaying a > mutation against a table with the same name but incompatible schema. > Exception follows: org.apache.cassandra.serializers.MarshalException: A local > deletion time should not be negative > {code} > If I delete all the commitlog and saved_cached files the server goes up, but > the next day when I reboot the cassandra, the error occurs again. > The file mutationDDdat change name for each restart. I attachament a > example mutation file . > What's wrong? How to make cassandra stable again? > -- 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] [Assigned] (CASSANDRA-14958) Counters fail to increment on 2.1/2.2 to 3.X mixed version clusters
[ https://issues.apache.org/jira/browse/CASSANDRA-14958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko reassigned CASSANDRA-14958: - Assignee: Aleksey Yeschenko > Counters fail to increment on 2.1/2.2 to 3.X mixed version clusters > --- > > Key: CASSANDRA-14958 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14958 > Project: Cassandra > Issue Type: Bug > Components: Feature/Counters >Reporter: Ariel Weisberg >Assignee: Aleksey Yeschenko >Priority: Critical > Fix For: 3.0.x, 2.0.x > > > The upgrade test for this is failing > https://circleci.com/gh/aweisberg/cassandra/2362#tests/containers/1 > I confirmed that this is occurring manually using cqlsh against the cluster > constructed by the dtest. > {noformat} > cqlsh> describe schema; > CREATE KEYSPACE ks WITH replication = {'class': 'SimpleStrategy', > 'replication_factor': '1'} AND durable_writes = true; > CREATE TABLE ks.clicks ( > userid int, > url text, > total counter, > PRIMARY KEY (userid, url) > ) WITH COMPACT STORAGE > AND CLUSTERING ORDER BY (url ASC) > AND bloom_filter_fp_chance = 0.01 > AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} > AND comment = '' > AND compaction = {'class': > 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', > 'max_threshold': '32', 'min_threshold': '4'} > AND compression = {'chunk_length_in_kb': '64', 'class': > 'org.apache.cassandra.io.compress.LZ4Compressor'} > AND crc_check_chance = 1.0 > AND dclocal_read_repair_chance = 0.1 > AND default_time_to_live = 0 > AND gc_grace_seconds = 864000 > AND max_index_interval = 2048 > AND memtable_flush_period_in_ms = 0 > AND min_index_interval = 128 > AND read_repair_chance = 0.0 > AND speculative_retry = '99PERCENTILE'; > cqlsh> use ks; > cqlsh:ks> UPDATE clicks SET total = total + 1 WHERE userid = 1 AND url = > 'http://foo.com'; > cqlsh:ks> SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com' > ... ; > total > --- > 0 > (1 rows) > {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-14958) Counters fail to increment on 2.1/2.2 to 3.X mixed version clusters
[ https://issues.apache.org/jira/browse/CASSANDRA-14958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-14958: --- Summary: Counters fail to increment on 2.1/2.2 to 3.X mixed version clusters (was: Counters fail to increment on 2.X to 3.X mixed version clusters) > Counters fail to increment on 2.1/2.2 to 3.X mixed version clusters > --- > > Key: CASSANDRA-14958 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14958 > Project: Cassandra > Issue Type: Bug > Components: Feature/Counters >Reporter: Ariel Weisberg >Priority: Critical > Fix For: 3.0.x, 2.0.x > > > The upgrade test for this is failing > https://circleci.com/gh/aweisberg/cassandra/2362#tests/containers/1 > I confirmed that this is occurring manually using cqlsh against the cluster > constructed by the dtest. > {noformat} > cqlsh> describe schema; > CREATE KEYSPACE ks WITH replication = {'class': 'SimpleStrategy', > 'replication_factor': '1'} AND durable_writes = true; > CREATE TABLE ks.clicks ( > userid int, > url text, > total counter, > PRIMARY KEY (userid, url) > ) WITH COMPACT STORAGE > AND CLUSTERING ORDER BY (url ASC) > AND bloom_filter_fp_chance = 0.01 > AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} > AND comment = '' > AND compaction = {'class': > 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', > 'max_threshold': '32', 'min_threshold': '4'} > AND compression = {'chunk_length_in_kb': '64', 'class': > 'org.apache.cassandra.io.compress.LZ4Compressor'} > AND crc_check_chance = 1.0 > AND dclocal_read_repair_chance = 0.1 > AND default_time_to_live = 0 > AND gc_grace_seconds = 864000 > AND max_index_interval = 2048 > AND memtable_flush_period_in_ms = 0 > AND min_index_interval = 128 > AND read_repair_chance = 0.0 > AND speculative_retry = '99PERCENTILE'; > cqlsh> use ks; > cqlsh:ks> UPDATE clicks SET total = total + 1 WHERE userid = 1 AND url = > 'http://foo.com'; > cqlsh:ks> SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com' > ... ; > total > --- > 0 > (1 rows) > {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-14959) ReadCommandVerbHandler validateTransientStatus class cast exception
[ https://issues.apache.org/jira/browse/CASSANDRA-14959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-14959: Reviewer: Alex Petrov > ReadCommandVerbHandler validateTransientStatus class cast exception > > > Key: CASSANDRA-14959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14959 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Causes a test failure, looks like it should just use instanceof. > {noformat} > Exception in thread Thread-1: > Traceback (most recent call last): > File > "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", > line 917, in _bootstrap_inner > self.run() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 189, in run > self.scan_and_report() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 182, 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.7/site-packages/_pytest/outcomes.py", > line 97, in fail > raise Failed(msg=msg, pytrace=pytrace) > Failed: Error details: > Errors seen in logs for: node1 > node1: ERROR [ReadStage-2] 2019-01-03 14:02:43,704 > AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread > Thread[ReadStage-2,5,main] > java.lang.ClassCastException: > org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to > org.apache.cassandra.db.SinglePartitionReadCommand > at > org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:85) > 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:115) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > FAILED > upgrade_tests/cql_tests.py:2869 > (TestCQLNodes3RF3_Upgrade_indev_3_11_x_To_indev_trunk.test_edge_2i_on_complex_pk) > {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-14959) ReadCommandVerbHandler validateTransientStatus class cast exception
[ https://issues.apache.org/jira/browse/CASSANDRA-14959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-14959: Status: Ready to Commit (was: Patch Available) > ReadCommandVerbHandler validateTransientStatus class cast exception > > > Key: CASSANDRA-14959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14959 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Causes a test failure, looks like it should just use instanceof. > {noformat} > Exception in thread Thread-1: > Traceback (most recent call last): > File > "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", > line 917, in _bootstrap_inner > self.run() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 189, in run > self.scan_and_report() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 182, 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.7/site-packages/_pytest/outcomes.py", > line 97, in fail > raise Failed(msg=msg, pytrace=pytrace) > Failed: Error details: > Errors seen in logs for: node1 > node1: ERROR [ReadStage-2] 2019-01-03 14:02:43,704 > AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread > Thread[ReadStage-2,5,main] > java.lang.ClassCastException: > org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to > org.apache.cassandra.db.SinglePartitionReadCommand > at > org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:85) > 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:115) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > FAILED > upgrade_tests/cql_tests.py:2869 > (TestCQLNodes3RF3_Upgrade_indev_3_11_x_To_indev_trunk.test_edge_2i_on_complex_pk) > {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-14959) ReadCommandVerbHandler validateTransientStatus class cast exception
[ https://issues.apache.org/jira/browse/CASSANDRA-14959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736061#comment-16736061 ] Alex Petrov commented on CASSANDRA-14959: - +1, looks good! Since this is already caught by dtests, we should be good without adding any new tests, too. > ReadCommandVerbHandler validateTransientStatus class cast exception > > > Key: CASSANDRA-14959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14959 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Causes a test failure, looks like it should just use instanceof. > {noformat} > Exception in thread Thread-1: > Traceback (most recent call last): > File > "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", > line 917, in _bootstrap_inner > self.run() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 189, in run > self.scan_and_report() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 182, 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.7/site-packages/_pytest/outcomes.py", > line 97, in fail > raise Failed(msg=msg, pytrace=pytrace) > Failed: Error details: > Errors seen in logs for: node1 > node1: ERROR [ReadStage-2] 2019-01-03 14:02:43,704 > AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread > Thread[ReadStage-2,5,main] > java.lang.ClassCastException: > org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to > org.apache.cassandra.db.SinglePartitionReadCommand > at > org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:85) > 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:115) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > FAILED > upgrade_tests/cql_tests.py:2869 > (TestCQLNodes3RF3_Upgrade_indev_3_11_x_To_indev_trunk.test_edge_2i_on_complex_pk) > {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-14959) ReadCommandVerbHandler validateTransientStatus class cast exception
[ https://issues.apache.org/jira/browse/CASSANDRA-14959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-14959: --- Status: Patch Available (was: Open) Proposed fix https://github.com/aweisberg/cassandra/commit/290f6dc2e79ff2d265fb2b232799bab0ba3a94cb CircleCI: https://circleci.com/gh/aweisberg/cassandra/tree/14959-trunk > ReadCommandVerbHandler validateTransientStatus class cast exception > > > Key: CASSANDRA-14959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14959 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > Causes a test failure, looks like it should just use instanceof. > {noformat} > Exception in thread Thread-1: > Traceback (most recent call last): > File > "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", > line 917, in _bootstrap_inner > self.run() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 189, in run > self.scan_and_report() > File > "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line > 182, 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.7/site-packages/_pytest/outcomes.py", > line 97, in fail > raise Failed(msg=msg, pytrace=pytrace) > Failed: Error details: > Errors seen in logs for: node1 > node1: ERROR [ReadStage-2] 2019-01-03 14:02:43,704 > AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread > Thread[ReadStage-2,5,main] > java.lang.ClassCastException: > org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to > org.apache.cassandra.db.SinglePartitionReadCommand > at > org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:85) > 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:115) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > FAILED > upgrade_tests/cql_tests.py:2869 > (TestCQLNodes3RF3_Upgrade_indev_3_11_x_To_indev_trunk.test_edge_2i_on_complex_pk) > {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-14961) upgrade_tests/cql-tests.py test_secondary_index_query fails because OHC logs a warning loading the java 8 extensions
[ https://issues.apache.org/jira/browse/CASSANDRA-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16736020#comment-16736020 ] Ariel Weisberg commented on CASSANDRA-14961: [~snazy] do you want to take this? > upgrade_tests/cql-tests.py test_secondary_index_query fails because OHC logs > a warning loading the java 8 extensions > > > Key: CASSANDRA-14961 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14961 > Project: Cassandra > Issue Type: Test > Components: Dependencies, Local/Caching >Reporter: Ariel Weisberg >Priority: Major > Fix For: 3.0.x, 3.11.x > > > I think it means it is always using JNA instead. > WARN [MemtableFlushWriter:1] 2019-01-04 16:22:27,438 Uns.java:169 - Failed > to load Java8 implementation ohc-core-j8 : java.lang.NoSuchMethodException: > org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class) -- 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-14961) upgrade_tests/cql-tests.py test_secondary_index_query fails because OHC logs a warning loading the java 8 extensions
Ariel Weisberg created CASSANDRA-14961: -- Summary: upgrade_tests/cql-tests.py test_secondary_index_query fails because OHC logs a warning loading the java 8 extensions Key: CASSANDRA-14961 URL: https://issues.apache.org/jira/browse/CASSANDRA-14961 Project: Cassandra Issue Type: Test Components: Dependencies, Local/Caching Reporter: Ariel Weisberg Fix For: 3.0.x, 3.11.x I think it means it is always using JNA instead. WARN [MemtableFlushWriter:1] 2019-01-04 16:22:27,438 Uns.java:169 - Failed to load Java8 implementation ohc-core-j8 : java.lang.NoSuchMethodException: org.caffinitas.ohc.linked.UnsExt8.(java.lang.Class) -- 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-14960) upgrade_tests/cql_tests.py test_invalid_string_literals fails because it can't send a corrupt string to the server
Ariel Weisberg created CASSANDRA-14960: -- Summary: upgrade_tests/cql_tests.py test_invalid_string_literals fails because it can't send a corrupt string to the server Key: CASSANDRA-14960 URL: https://issues.apache.org/jira/browse/CASSANDRA-14960 Project: Cassandra Issue Type: Test Components: Test/dtest Reporter: Ariel Weisberg This is a test bug. I checked at the server and the server isn't receiving a corrupt string it is supposed to recieve 0xC201 as the corrupt character and instead it receives 0x8201. -- 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-14959) ReadCommandVerbHandler validateTransientStatus class cast exception
Ariel Weisberg created CASSANDRA-14959: -- Summary: ReadCommandVerbHandler validateTransientStatus class cast exception Key: CASSANDRA-14959 URL: https://issues.apache.org/jira/browse/CASSANDRA-14959 Project: Cassandra Issue Type: Bug Components: Consistency/Coordination Reporter: Ariel Weisberg Assignee: Ariel Weisberg Fix For: 4.0 Causes a test failure, looks like it should just use instanceof. {noformat} Exception in thread Thread-1: Traceback (most recent call last): File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 917, in _bootstrap_inner self.run() File "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line 189, in run self.scan_and_report() File "/Users/aweisberg/repos/cassandra-dtest/venv/src/ccm/ccmlib/cluster.py", line 182, 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.7/site-packages/_pytest/outcomes.py", line 97, in fail raise Failed(msg=msg, pytrace=pytrace) Failed: Error details: Errors seen in logs for: node1 node1: ERROR [ReadStage-2] 2019-01-03 14:02:43,704 AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread Thread[ReadStage-2,5,main] java.lang.ClassCastException: org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to org.apache.cassandra.db.SinglePartitionReadCommand at org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:85) 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:115) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) FAILED upgrade_tests/cql_tests.py:2869 (TestCQLNodes3RF3_Upgrade_indev_3_11_x_To_indev_trunk.test_edge_2i_on_complex_pk) {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] [Created] (CASSANDRA-14958) Counters fail to increment on 2.X to 3.X mixed version clusters
Ariel Weisberg created CASSANDRA-14958: -- Summary: Counters fail to increment on 2.X to 3.X mixed version clusters Key: CASSANDRA-14958 URL: https://issues.apache.org/jira/browse/CASSANDRA-14958 Project: Cassandra Issue Type: Bug Components: Feature/Counters Reporter: Ariel Weisberg Fix For: 2.0.x, 3.0.x The upgrade test for this is failing https://circleci.com/gh/aweisberg/cassandra/2362#tests/containers/1 I confirmed that this is occurring manually using cqlsh against the cluster constructed by the dtest. {noformat} cqlsh> describe schema; CREATE KEYSPACE ks WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'} AND durable_writes = true; CREATE TABLE ks.clicks ( userid int, url text, total counter, PRIMARY KEY (userid, url) ) WITH COMPACT STORAGE AND CLUSTERING ORDER BY (url ASC) AND bloom_filter_fp_chance = 0.01 AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} AND comment = '' AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'} AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'} AND crc_check_chance = 1.0 AND dclocal_read_repair_chance = 0.1 AND default_time_to_live = 0 AND gc_grace_seconds = 864000 AND max_index_interval = 2048 AND memtable_flush_period_in_ms = 0 AND min_index_interval = 128 AND read_repair_chance = 0.0 AND speculative_retry = '99PERCENTILE'; cqlsh> use ks; cqlsh:ks> UPDATE clicks SET total = total + 1 WHERE userid = 1 AND url = 'http://foo.com'; cqlsh:ks> SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com' ... ; total --- 0 (1 rows) {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] [Created] (CASSANDRA-14957) Rolling Restart Of Nodes Cause Dataloss Due To Schema Collision
Avraham Kalvo created CASSANDRA-14957: - Summary: Rolling Restart Of Nodes Cause Dataloss Due To Schema Collision Key: CASSANDRA-14957 URL: https://issues.apache.org/jira/browse/CASSANDRA-14957 Project: Cassandra Issue Type: Bug Components: Cluster/Schema Reporter: Avraham Kalvo We were issuing a rolling restart on a mission-critical five node C* cluster. The first node which was restarted got the following messages in its system.log: ``` January 2nd 2019, 12:06:37.310 - INFO 12:06:35 Initializing tasks_scheduler_external.tasks ``` ``` WARN 12:06:39 UnknownColumnFamilyException reading from socket; closing org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find table for cfId bd7200a0-1567-11e8-8974-855d74ee356f. If a table was just created, this is likely due to the schema not being fully propagated. Please wait for schema agreement on table creation. at org.apache.cassandra.config.CFMetaData$Serializer.deserialize(CFMetaData.java:1336) ~[apache-cassandra-3.0.10.jar:3.0.10] at org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize30(PartitionUpdate.java:660) ~[apache-cassandra-3.0.10.jar:3.0.10] at org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize(PartitionUpdate.java:635) ~[apache-cassandra-3.0.10.jar:3.0.10] at org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:330) ~[apache-cassandra-3.0.10.jar:3.0.10] at org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:349) ~[apache-cassandra-3.0.10.jar:3.0.10] at org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:286) ~[apache-cassandra-3.0.10.jar:3.0.10] at org.apache.cassandra.net.MessageIn.read(MessageIn.java:98) ~[apache-cassandra-3.0.10.jar:3.0.10] at org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:201) ~[apache-cassandra-3.0.10.jar:3.0.10] at org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:178) ~[apache-cassandra-3.0.10.jar:3.0.10] at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:92) ~[apache-cassandra-3.0.10.jar:3.0.10] ``` The latter was then repeated several times across the cluster. It was then found out that the table in question `tasks_scheduler_external.tasks` was created with a new schema version after the entire cluster was restarted consecutively and schema agreement settled, which started taking requests leaving the previous version of the schema unavailable for any request, thus generating a data loss to our online system. Data loss was recovered by manually copying SSTables from the previous version directory of the schema to the new one followed by `nodetool refresh` to the relevant table. The above has repeated itself for several tables across various keyspaces. One other thing to mention is that a repair was in place for the first node to be restarted, which was obviously stopped as the daemon was shut down, but this doesn't seem to do with the above at first glance. Seems somewhat related to: https://issues.apache.org/jira/browse/CASSANDRA-13559 -- 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-10857) Allow dropping COMPACT STORAGE flag from tables in 3.X
[ https://issues.apache.org/jira/browse/CASSANDRA-10857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-10857: Fix Version/s: (was: 4.0) > Allow dropping COMPACT STORAGE flag from tables in 3.X > -- > > Key: CASSANDRA-10857 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10857 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL, Legacy/Distributed Metadata >Reporter: Aleksey Yeschenko >Assignee: Alex Petrov >Priority: Blocker > Labels: client-impacting > Fix For: 3.0.16, 3.11.2 > > > Thrift allows users to define flexible mixed column families - where certain > columns would have explicitly pre-defined names, potentially non-default > validation types, and be indexed. > Example: > {code} > create column family foo > and default_validation_class = UTF8Type > and column_metadata = [ > {column_name: bar, validation_class: Int32Type, index_type: KEYS}, > {column_name: baz, validation_class: UUIDType, index_type: KEYS} > ]; > {code} > Columns named {{bar}} and {{baz}} will be validated as {{Int32Type}} and > {{UUIDType}}, respectively, and be indexed. Columns with any other name will > be validated by {{UTF8Type}} and will not be indexed. > With CASSANDRA-8099, {{bar}} and {{baz}} would be mapped to static columns > internally. However, being {{WITH COMPACT STORAGE}}, the table will only > expose {{bar}} and {{baz}} columns. Accessing any dynamic columns (any column > not named {{bar}} and {{baz}}) right now requires going through Thrift. > This is blocking Thrift -> CQL migration for users who have mixed > dynamic/static column families. That said, it *shouldn't* be hard to allow > users to drop the {{compact}} flag to expose the table as it is internally > now, and be able to access all columns. -- 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-14956) Paged Range Slice queries with DISTINCT can drop rows from results
[ https://issues.apache.org/jira/browse/CASSANDRA-14956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-14956: Status: Patch Available (was: Open) Patch to change the page trimming for DISTINCT range queries to simply remove the first row from the page. ||branch||CI|| |[14956-2.2|https://github.com/beobal/cassandra/tree/14956-2.2]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/cci%2F14956-2.2]| > Paged Range Slice queries with DISTINCT can drop rows from results > -- > > Key: CASSANDRA-14956 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14956 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Major > Fix For: 2.2.14 > > > If we have a partition where the first CQL row is fully deleted (possibly via > TTLs), and that partition happens to fall on the page boundary of a paged > range query which is using SELECT DISTINCT, the next live partition *after* > it is omitted from the result set. This is due to over fetching of the pages > and a bug in trimming those pages where overlap occurs. > This does not affect 3.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] [Created] (CASSANDRA-14956) Paged Range Slice queries with DISTINCT can drop rows from results
Sam Tunnicliffe created CASSANDRA-14956: --- Summary: Paged Range Slice queries with DISTINCT can drop rows from results Key: CASSANDRA-14956 URL: https://issues.apache.org/jira/browse/CASSANDRA-14956 Project: Cassandra Issue Type: Bug Components: CQL/Interpreter Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe Fix For: 2.2.14 If we have a partition where the first CQL row is fully deleted (possibly via TTLs), and that partition happens to fall on the page boundary of a paged range query which is using SELECT DISTINCT, the next live partition *after* it is omitted from the result set. This is due to over fetching of the pages and a bug in trimming those pages where overlap occurs. This does not affect 3.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
cassandra git commit: Ninja: Move NO_COMPACT to 'Changes from v4' section
Repository: cassandra Updated Branches: refs/heads/trunk 55b47b8bd -> ef1817a75 Ninja: Move NO_COMPACT to 'Changes from v4' section Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ef1817a7 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ef1817a7 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ef1817a7 Branch: refs/heads/trunk Commit: ef1817a75ceeaa5f8eb11cd4acd0bcbe5f1ed14d Parents: 55b47b8 Author: Alex Petrov Authored: Mon Jan 7 12:05:13 2019 +0100 Committer: Alex Petrov Committed: Mon Jan 7 12:05:13 2019 +0100 -- doc/native_protocol_v5.spec | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/ef1817a7/doc/native_protocol_v5.spec -- diff --git a/doc/native_protocol_v5.spec b/doc/native_protocol_v5.spec index ad2fd7a..d1b3915 100644 --- a/doc/native_protocol_v5.spec +++ b/doc/native_protocol_v5.spec @@ -298,10 +298,6 @@ Table of Contents different from the protocol version. - "COMPRESSION": the compression algorithm to use for frames (See section 5). This is optional; if not specified no compression will be used. -- "NO_COMPACT": whether or not connection has to be established in compatibility - mode. This mode will make all Thrift and Compact Tables to be exposed as if - they were CQL Tables. This is optional; if not specified, the option will - not be used. 4.1.2. AUTH_RESPONSE @@ -1268,3 +1264,4 @@ Table of Contents * Added keyspace field in QUERY, PREPARE, and BATCH messages (Sections 4.1.4, 4.1.5, and 4.1.7). * Added now_in_seconds field in QUERY, EXECUTE, and BATCH messages (Sections 4.1.4, 4.1.6, and 4.1.7). * Added [int] flags field in PREPARE message (Section 4.1.5). + * Removed NO_COMPACT startup option (Section 4.1.1.) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13304) Add checksumming to the native protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735615#comment-16735615 ] Alex Petrov edited comment on CASSANDRA-13304 at 1/7/19 9:43 AM: - It looks like this patch has introduced protocol changes that are not documented in [v5 doc|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L299]: {{STARTUP}} protocol option, frame format etc. It'd be great to have it updated, especially since we're post 4.0 code freeze and driver implementers will probably want to catch up any time soon so that there was a corresponding driver for the release. UPD: Looks like [~beobal] was way ahead of me: https://issues.apache.org/jira/browse/CASSANDRA-14688 thanks Sam! was (Author: ifesdjeen): It looks like this patch has introduced protocol changes that are not documented in [v5 doc|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L299]: {{STARTUP}} protocol option, frame format etc. It'd be great to have it updated, especially since we're post 4.0 code freeze and driver implementers will probably want to catch up any time soon so that there was a corresponding driver for the release. > Add checksumming to the native protocol > --- > > Key: CASSANDRA-13304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13304 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Michael Kjellman >Assignee: Sam Tunnicliffe >Priority: Blocker > Labels: client-impacting > Fix For: 4.0 > > Attachments: 13304_v1.diff, boxplot-read-throughput.png, > boxplot-write-throughput.png > > > The native binary transport implementation doesn't include checksums. This > makes it highly susceptible to silently inserting corrupted data either due > to hardware issues causing bit flips on the sender/client side, C*/receiver > side, or network in between. > Attaching an implementation that makes checksum'ing mandatory (assuming both > client and server know about a protocol version that supports checksums) -- > and also adds checksumming to clients that request compression. > The serialized format looks something like this: > {noformat} > * 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Number of Compressed Chunks | Compressed Length (e1)/ > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * / Compressed Length cont. (e1) |Uncompressed Length (e1) / > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Uncompressed Length cont. (e1)| CRC32 Checksum of Lengths (e1)| > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Checksum of Lengths cont. (e1)|Compressed Bytes (e1)+// > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | CRC32 Checksum (e1) || > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * |Compressed Length (e2) | > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Uncompressed Length (e2)| > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * |CRC32 Checksum of Lengths (e2) | > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Compressed Bytes (e2) +// > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | CRC32 Checksum (e2) || > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * |Compressed Length (en) | > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Uncompressed Length (en)| > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * |CRC32 Checksum of Lengths (en) | > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Compressed Bytes (en) +// > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | CRC32 Checksum (en) || > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > {noformat} > The first pass here adds checksums only to the actual contents of the frame > body itself (and doesn't actually checksum lengths and headers). While it > would be great to fully add checksuming
cassandra git commit: Ninja: merge protocol changes that were made in v4 forward to v5
Repository: cassandra Updated Branches: refs/heads/trunk c68b0fec6 -> 55b47b8bd Ninja: merge protocol changes that were made in v4 forward to v5 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/55b47b8b Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/55b47b8b Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/55b47b8b Branch: refs/heads/trunk Commit: 55b47b8bd245fc89f91f00bd495386d43bdd1a74 Parents: c68b0fe Author: Alex Petrov Authored: Mon Jan 7 10:39:34 2019 +0100 Committer: Alex Petrov Committed: Mon Jan 7 10:39:34 2019 +0100 -- doc/native_protocol_v5.spec | 4 1 file changed, 4 insertions(+) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/55b47b8b/doc/native_protocol_v5.spec -- diff --git a/doc/native_protocol_v5.spec b/doc/native_protocol_v5.spec index 8091775..ad2fd7a 100644 --- a/doc/native_protocol_v5.spec +++ b/doc/native_protocol_v5.spec @@ -298,6 +298,10 @@ Table of Contents different from the protocol version. - "COMPRESSION": the compression algorithm to use for frames (See section 5). This is optional; if not specified no compression will be used. +- "NO_COMPACT": whether or not connection has to be established in compatibility + mode. This mode will make all Thrift and Compact Tables to be exposed as if + they were CQL Tables. This is optional; if not specified, the option will + not be used. 4.1.2. AUTH_RESPONSE - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13304) Add checksumming to the native protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-13304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735615#comment-16735615 ] Alex Petrov commented on CASSANDRA-13304: - It looks like this patch has introduced protocol changes that are not documented in [v5 doc|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L299]: {{STARTUP}} protocol option, frame format etc. It'd be great to have it updated, especially since we're post 4.0 code freeze and driver implementers will probably want to catch up any time soon so that there was a corresponding driver for the release. > Add checksumming to the native protocol > --- > > Key: CASSANDRA-13304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13304 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Michael Kjellman >Assignee: Sam Tunnicliffe >Priority: Blocker > Labels: client-impacting > Fix For: 4.0 > > Attachments: 13304_v1.diff, boxplot-read-throughput.png, > boxplot-write-throughput.png > > > The native binary transport implementation doesn't include checksums. This > makes it highly susceptible to silently inserting corrupted data either due > to hardware issues causing bit flips on the sender/client side, C*/receiver > side, or network in between. > Attaching an implementation that makes checksum'ing mandatory (assuming both > client and server know about a protocol version that supports checksums) -- > and also adds checksumming to clients that request compression. > The serialized format looks something like this: > {noformat} > * 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Number of Compressed Chunks | Compressed Length (e1)/ > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * / Compressed Length cont. (e1) |Uncompressed Length (e1) / > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Uncompressed Length cont. (e1)| CRC32 Checksum of Lengths (e1)| > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Checksum of Lengths cont. (e1)|Compressed Bytes (e1)+// > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | CRC32 Checksum (e1) || > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * |Compressed Length (e2) | > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Uncompressed Length (e2)| > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * |CRC32 Checksum of Lengths (e2) | > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Compressed Bytes (e2) +// > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | CRC32 Checksum (e2) || > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * |Compressed Length (en) | > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Uncompressed Length (en)| > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * |CRC32 Checksum of Lengths (en) | > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | Compressed Bytes (en) +// > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > * | CRC32 Checksum (en) || > * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > {noformat} > The first pass here adds checksums only to the actual contents of the frame > body itself (and doesn't actually checksum lengths and headers). While it > would be great to fully add checksuming across the entire protocol, the > proposed implementation will ensure we at least catch corrupted data and > likely protect ourselves pretty well anyways. > I didn't go to the trouble of implementing a Snappy Checksum'ed Compressor > implementation as it's been deprecated for a while -- is really slow and > crappy compared to LZ4 -- and we should do everything in our power to make > sure no one in the community is still using it. I left it in (for obvious > backwards compatibility aspects) old for clients that don't know about the > new protocol. > The current protocol has a 256MB (max) frame body -- where