[jira] [Created] (CASSANDRA-15647) Missmatching dependencies between cassandra dist and cassandra-all pom
Marvin Froeder created CASSANDRA-15647: -- Summary: Missmatching dependencies between cassandra dist and cassandra-all pom Key: CASSANDRA-15647 URL: https://issues.apache.org/jira/browse/CASSANDRA-15647 Project: Cassandra Issue Type: Bug Components: Build, Dependencies Reporter: Marvin Froeder I noticed that the cassandra distribution (tar.gz) dependencies doesn't match the dependency list for the cassandra-all that is available at maven central. Cassandra distribution only includes jna 4.2.2. But, the maven dependency also include jna-platform 4.4.0 Breakdown of relevant maven dependencies: ``` [INFO] +- org.apache.cassandra:cassandra-all:jar:4.0-alpha3:provided [INFO] | +- net.java.dev.jna:jna:jar:4.2.2:provided [INFO] | +- net.openhft:chronicle-threads:jar:1.16.0:provided [INFO] | | \- net.openhft:affinity:jar:3.1.7:provided [INFO] | | \- net.java.dev.jna:jna-platform:jar:4.4.0:provided ``` As you can see, jna is a direct dependency and jna-platform is a transitive dependency from chronicle-threads. I expected this issue to had been fixed by https://github.com/apache/cassandra/pull/240/, but this change seem to have being reverted, as no longer in trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13994) Remove COMPACT STORAGE internals before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-13994:
---
Assignee: Ekaterina Dimitrova (was: Alex Petrov)
> Remove COMPACT STORAGE internals before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-rc
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko reassigned CASSANDRA-15299:
-
Assignee: Sam Tunnicliffe (was: Aleksey Yeschenko)
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15299:
--
Authors: Sam Tunnicliffe (was: Aleksey Yeschenko, Sam Tunnicliffe)
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> particular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15646) running cassandra source code in eclipse
[ https://issues.apache.org/jira/browse/CASSANDRA-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15646: - Resolution: Invalid Status: Resolved (was: Triage Needed) Jira is not a support system, I recommend posting on the user list or the ASF slack: http://cassandra.apache.org/community/ > running cassandra source code in eclipse > > > Key: CASSANDRA-15646 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15646 > Project: Cassandra > Issue Type: Bug >Reporter: nasimm >Priority: Normal > Attachments: CaptureDotNetRes.dll.png > > > Hi . I installed cassandra on ubuntu and worked with it, i want to build and > compile and run source code of cassandra in eclipse ,now. > my problem is this error : r: Could not find or load main class > org.apache.cassandra.thrift.CassandraDaemon error > and i cant run source code of cassandra in eclipse , I dont know my previous > steps for running source code of cassandra in eclipse is correct or not. > please , please , please , please, please help me and tell me steps of > building , compiling , running cassandra source code in eclipse . > > my email : [nnasi...@gmail.com|mailto:nnasi...@gmail.com] > > please help me :(( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15646) running cassandra source code in eclipse
nasimm created CASSANDRA-15646: -- Summary: running cassandra source code in eclipse Key: CASSANDRA-15646 URL: https://issues.apache.org/jira/browse/CASSANDRA-15646 Project: Cassandra Issue Type: Bug Reporter: nasimm Attachments: CaptureDotNetRes.dll.png Hi . I installed cassandra on ubuntu and worked with it, i want to build and compile and run source code of cassandra in eclipse ,now. my problem is this error : r: Could not find or load main class org.apache.cassandra.thrift.CassandraDaemon error and i cant run source code of cassandra in eclipse , I dont know my previous steps for running source code of cassandra in eclipse is correct or not. please , please , please , please, please help me and tell me steps of building , compiling , running cassandra source code in eclipse . my email : [nnasi...@gmail.com|mailto:nnasi...@gmail.com] please help me :(( -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15639) Jenkins build for jvm test should use testclasslist to support parameterized tests
[
https://issues.apache.org/jira/browse/CASSANDRA-15639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060390#comment-17060390
]
David Capwell commented on CASSANDRA-15639:
---
teehee its all good =)
> Jenkins build for jvm test should use testclasslist to support parameterized
> tests
> --
>
> Key: CASSANDRA-15639
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15639
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> We switched Circle CI to use testclasslist in CASSANDRA-15508 this was to
> solve the following exception
> {code}
> ava.lang.Exception: No tests found matching Method
> testFailingMessage(org.apache.cassandra.distributed.test.FailingRepairTest)
> from org.junit.internal.requests.ClassRequest@551aa95a
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> {code}
> The core issue is that the test locating logic in
> org.apache.cassandra.distributed.test.TestLocator does not handle
> parameterized tests so fails to find any tests for those classes.
> I think it is better to switch to testclasslist as it helps make way for
> running tests concurrently.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15645) Can't send schema pull request: node /A.B.C.D is down
Pierre Belanger apache.org created CASSANDRA-15645:
--
Summary: Can't send schema pull request: node /A.B.C.D is down
Key: CASSANDRA-15645
URL: https://issues.apache.org/jira/browse/CASSANDRA-15645
Project: Cassandra
Issue Type: Bug
Components: Cluster/Schema
Reporter: Pierre Belanger apache.org
On a new cluster with Cassandra 3.11.5, each time a node joins the cluster the
schema pull request happens before at least 1 node is confirmed up. On the
first node it's fine but node #2 and following are all complaining with below
WARN.
{noformat}
INFO [MigrationStage:1] 2020-03-16 16:49:32,355 ColumnFamilyStore.java:426 -
Initializing system_auth.roles
WARN [MigrationStage:1] 2020-03-16 16:49:32,368 MigrationTask.java:67 - Can't
send schema pull request: node /A.B.C.D is down.
WARN [MigrationStage:1] 2020-03-16 16:49:32,369 MigrationTask.java:67 - Can't
send schema pull request: node /A.B.C.D is down.
INFO [main] 2020-03-16 16:49:32,371 Gossiper.java:1780 - Waiting for gossip to
settle...
INFO [GossipStage:1] 2020-03-16 16:49:32,493 Gossiper.java:1089 - InetAddress
/A.B.C.D is now UP
INFO [HANDSHAKE-/10.205.45.19] 2020-03-16 16:49:32,545
OutboundTcpConnection.java:561 - Handshaking version with /A.B.C.D
{noformat}
It's not urgent to fix but the WARN create noise for no reason. Before trying
to pull the schema, shouldn't the process wait for gossip to have at least 1
node "up"?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15557) Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest testDropListAndAddListWithSameName
[
https://issues.apache.org/jira/browse/CASSANDRA-15557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15557:
---
Since Version: 4.0-alpha
Source Control Link:
https://github.com/apache/cassandra/commit/61b8a14a59e824854f87b54afc08289a3278942c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed in trunk at 61b8a14a59e824854f87b54afc08289a3278942c
> Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest
> testDropListAndAddListWithSameName
> ---
>
> Key: CASSANDRA-15557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15557
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ryan Svihla
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/jobs/github/dcapwell/cassandra/482/tests
> {code}
> junit.framework.AssertionFailedError: Invalid value for row 0 column 2
> (mycollection of type list), expected but got <[first element]>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1070)
> at
> org.apache.cassandra.cql3.validation.operations.AlterTest.testDropListAndAddListWithSameName(AlterTest.java:91)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15557) Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest testDropListAndAddListWithSameName
[
https://issues.apache.org/jira/browse/CASSANDRA-15557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15557:
---
Reviewers: Aleksey Yeschenko, Benjamin Lerer, Benjamin Lerer (was: Aleksey
Yeschenko, Benjamin Lerer)
Aleksey Yeschenko, Benjamin Lerer, Benjamin Lerer (was: Aleksey
Yeschenko, Benjamin Lerer)
Status: Review In Progress (was: Patch Available)
> Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest
> testDropListAndAddListWithSameName
> ---
>
> Key: CASSANDRA-15557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15557
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ryan Svihla
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/jobs/github/dcapwell/cassandra/482/tests
> {code}
> junit.framework.AssertionFailedError: Invalid value for row 0 column 2
> (mycollection of type list), expected but got <[first element]>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1070)
> at
> org.apache.cassandra.cql3.validation.operations.AlterTest.testDropListAndAddListWithSameName(AlterTest.java:91)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15557) Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest testDropListAndAddListWithSameName
[
https://issues.apache.org/jira/browse/CASSANDRA-15557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15557:
---
Status: Ready to Commit (was: Review In Progress)
> Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest
> testDropListAndAddListWithSameName
> ---
>
> Key: CASSANDRA-15557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15557
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Ryan Svihla
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/jobs/github/dcapwell/cassandra/482/tests
> {code}
> junit.framework.AssertionFailedError: Invalid value for row 0 column 2
> (mycollection of type list), expected but got <[first element]>
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1070)
> at
> org.apache.cassandra.cql3.validation.operations.AlterTest.testDropListAndAddListWithSameName(AlterTest.java:91)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Use ClientState timestamp for when dropping columns
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 61b8a14 Use ClientState timestamp for when dropping columns
61b8a14 is described below
commit 61b8a14a59e824854f87b54afc08289a3278942c
Author: Ryan Svihla <43972+rssvi...@users.noreply.github.com>
AuthorDate: Mon Mar 16 17:55:59 2020 +0100
Use ClientState timestamp for when dropping columns
patch by Ryan Svihla; reviewed by Benjamin Lerer for CASSANDRA-15557
---
.../apache/cassandra/cql3/statements/schema/AlterTableStatement.java| 2 +-
src/java/org/apache/cassandra/service/ClientState.java | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
a/src/java/org/apache/cassandra/cql3/statements/schema/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/schema/AlterTableStatement.java
index d784796..b269762 100644
---
a/src/java/org/apache/cassandra/cql3/statements/schema/AlterTableStatement.java
+++
b/src/java/org/apache/cassandra/cql3/statements/schema/AlterTableStatement.java
@@ -270,7 +270,7 @@ public abstract class AlterTableStatement extends
AlterSchemaStatement
*/
private long getTimestamp()
{
-return timestamp == null ? FBUtilities.timestampMicros() :
timestamp;
+return timestamp == null ? ClientState.getTimestamp() : timestamp;
}
}
diff --git a/src/java/org/apache/cassandra/service/ClientState.java
b/src/java/org/apache/cassandra/service/ClientState.java
index 81574e6..496cabd 100644
--- a/src/java/org/apache/cassandra/service/ClientState.java
+++ b/src/java/org/apache/cassandra/service/ClientState.java
@@ -194,7 +194,7 @@ public class ClientState
* This clock guarantees that updates for the same ClientState will be
ordered
* in the sequence seen, even if multiple updates happen in the same
millisecond.
*/
-public long getTimestamp()
+public static long getTimestamp()
{
while (true)
{
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15643) Add java.rmi.server.randomID and JAVA_HOME to system properties vtable (follow up on CASSANDRA-15616)
[
https://issues.apache.org/jira/browse/CASSANDRA-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15643:
---
Fix Version/s: 4.x
> Add java.rmi.server.randomID and JAVA_HOME to system properties vtable
> (follow up on CASSANDRA-15616)
> --
>
> Key: CASSANDRA-15643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15643
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> Add {{java.rmi.server.randomID}} to the systems_table
> System.getProperty("java.home")
> to be switched to
> System.getenv("JAVA_HOME")
>
> Oracle JVM might use the JRE which do not contain jmap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15643) Add java.rmi.server.randomID and JAVA_HOME to system properties vtable (follow up on CASSANDRA-15616)
[
https://issues.apache.org/jira/browse/CASSANDRA-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15643:
---
Summary: Add java.rmi.server.randomID and JAVA_HOME to system properties
vtable (follow up on CASSANDRA-15616) (was: Follow up on CASSANDRA-15616 )
> Add java.rmi.server.randomID and JAVA_HOME to system properties vtable
> (follow up on CASSANDRA-15616)
> --
>
> Key: CASSANDRA-15643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15643
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Add {{java.rmi.server.randomID}} to the systems_table
> System.getProperty("java.home")
> to be switched to
> System.getenv("JAVA_HOME")
>
> Oracle JVM might use the JRE which do not contain jmap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15643) Follow up on CASSANDRA-15616
[
https://issues.apache.org/jira/browse/CASSANDRA-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15643:
---
Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Michael Semb Wever, Michael Semb Wever
Status: Review In Progress (was: Patch Available)
> Follow up on CASSANDRA-15616
> -
>
> Key: CASSANDRA-15643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15643
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Add {{java.rmi.server.randomID}} to the systems_table
> System.getProperty("java.home")
> to be switched to
> System.getenv("JAVA_HOME")
>
> Oracle JVM might use the JRE which do not contain jmap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15303:
---
Fix Version/s: (was: 4.x)
4.0
Since Version: 4.0
Source Control Link:
https://github.com/apache/cassandra/commit/722d10b2c5999f19f3a912dc2fbaeb71cef65a07
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into trunk at 722d10b2c5999f19f3a912dc2fbaeb71cef65a07
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0
>
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15303:
---
Status: Ready to Commit (was: Review In Progress)
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15303:
---
Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Status: Review In Progress (was: Patch Available)
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Use execution timestamp in ALTER TABLE DROP column
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 722d10b Use execution timestamp in ALTER TABLE DROP column
722d10b is described below
commit 722d10b2c5999f19f3a912dc2fbaeb71cef65a07
Author: Zhao Yang
AuthorDate: Fri Sep 6 11:11:23 2019 +0800
Use execution timestamp in ALTER TABLE DROP column
patch by Zhao Yang; reviewed by Benjamin Lerer for CASSANDRA-15303
---
.../apache/cassandra/cql3/MultiColumnRelation.java | 1 +
.../cassandra/cql3/SingleColumnRelation.java | 1 +
.../org/apache/cassandra/cql3/TokenRelation.java | 2 +-
.../statements/schema/AlterTableStatement.java | 16 +-
test/unit/org/apache/cassandra/cql3/CQLTester.java | 14 ++
.../cql3/validation/operations/AlterTest.java | 181 -
6 files changed, 136 insertions(+), 79 deletions(-)
diff --git a/src/java/org/apache/cassandra/cql3/MultiColumnRelation.java
b/src/java/org/apache/cassandra/cql3/MultiColumnRelation.java
index 2d239fb..89d69ed 100644
--- a/src/java/org/apache/cassandra/cql3/MultiColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/MultiColumnRelation.java
@@ -259,6 +259,7 @@ public class MultiColumnRelation extends Relation
MultiColumnRelation mcr = (MultiColumnRelation) o;
return Objects.equals(entities, mcr.entities)
+&& Objects.equals(relationType, mcr.relationType)
&& Objects.equals(valuesOrMarker, mcr.valuesOrMarker)
&& Objects.equals(inValues, mcr.inValues)
&& Objects.equals(inMarker, mcr.inMarker);
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index d9c5b26..bf453d7 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -172,6 +172,7 @@ public final class SingleColumnRelation extends Relation
SingleColumnRelation scr = (SingleColumnRelation) o;
return Objects.equals(entity, scr.entity)
+&& Objects.equals(relationType, scr.relationType)
&& Objects.equals(mapKey, scr.mapKey)
&& Objects.equals(value, scr.value)
&& Objects.equals(inValues, scr.inValues);
diff --git a/src/java/org/apache/cassandra/cql3/TokenRelation.java
b/src/java/org/apache/cassandra/cql3/TokenRelation.java
index 4e3313d..0919c50 100644
--- a/src/java/org/apache/cassandra/cql3/TokenRelation.java
+++ b/src/java/org/apache/cassandra/cql3/TokenRelation.java
@@ -160,7 +160,7 @@ public final class TokenRelation extends Relation
return false;
TokenRelation tr = (TokenRelation) o;
-return entities.equals(tr.entities) && value.equals(tr.value);
+return relationType.equals(tr.relationType) &&
entities.equals(tr.entities) && value.equals(tr.value);
}
/**
diff --git
a/src/java/org/apache/cassandra/cql3/statements/schema/AlterTableStatement.java
b/src/java/org/apache/cassandra/cql3/statements/schema/AlterTableStatement.java
index 6410e67..d784796 100644
---
a/src/java/org/apache/cassandra/cql3/statements/schema/AlterTableStatement.java
+++
b/src/java/org/apache/cassandra/cql3/statements/schema/AlterTableStatement.java
@@ -214,9 +214,9 @@ public abstract class AlterTableStatement extends
AlterSchemaStatement
private static class DropColumns extends AlterTableStatement
{
private final Collection removedColumns;
-private final long timestamp;
+private final Long timestamp;
-private DropColumns(String keyspaceName, String tableName,
Collection removedColumns, long timestamp)
+private DropColumns(String keyspaceName, String tableName,
Collection removedColumns, Long timestamp)
{
super(keyspaceName, tableName);
this.removedColumns = removedColumns;
@@ -262,7 +262,15 @@ public abstract class AlterTableStatement extends
AlterSchemaStatement
throw ire("Cannot drop column %s on base table %s with
materialized views", currentColumn, table.name);
builder.removeRegularOrStaticColumn(name);
-builder.recordColumnDrop(currentColumn, timestamp);
+builder.recordColumnDrop(currentColumn, getTimestamp());
+}
+
+/**
+ * @return timestamp from query, otherwise return current time in
micros
+ */
+private long getTimestamp()
+{
+return timestamp == null ? FBUtilities.timestampMicros() :
timestamp;
}
}
@@ -395,7 +403,7 @@ public abstract class AlterTableStatement extends
AlterSchemaStatement
// DROP
private final List droppedColumns = new
ArrayList<>();
-private long timestamp =
[jira] [Updated] (CASSANDRA-15644) Schema/Query analyzer
[ https://issues.apache.org/jira/browse/CASSANDRA-15644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-15644: Change Category: Operability Complexity: Challenging Component/s: Legacy/Tools CQL/Syntax Fix Version/s: 4.x Status: Open (was: Triage Needed) > Schema/Query analyzer > - > > Key: CASSANDRA-15644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15644 > Project: Cassandra > Issue Type: New Feature > Components: CQL/Syntax, Legacy/Tools >Reporter: Venkata Harikrishna Nukala >Assignee: Venkata Harikrishna Nukala >Priority: Normal > Fix For: 4.x > > > This proposal is to build schema/cql analyser which can help users to analyze > their queries before it is too late. > > User may create stability issues by > - Running expensive queries against cluster like , SELECT * or query without > where clause or IN clause with many values etc. > - Creating not so optimal schemas > - Leaving scope for data loss or schema with performance issue (keyspace > with durable writes set to false or table with many secondary indexes etc...). > > Most of the times these Dos & Don'ts go into some knowledge > base/documentation as best practices. Having rules for best practices (which > user can execute against statements) can help to avoid bad schema/queries > getting executed in cluster. The main idea is to enable the users to take > corrective actions, by > 1) Allowing a user to validate a DDL/DML statements before it is > applied/executed. > 2) Allowing a user to validate existing schema/queries. > > Imo, a validation result should: > 1. Have severity > 2. Tell where it hurts like instance/replica set/cluster. > 3. Tell if it causes data loss. > 4. Tell the strategy to recover. > > Few approaches I can think of: > 1. Write validation rules at server side + have a new type of statement to > run validations (something like MySQL's EXPLAIN) and return validation > results/errors. > 2. Keep validation rules in sidecar + expose a service to run validations. > In this case user can submit his statements to this API and get validation > results. > 3. Expose a UI in sidecar which accepts statements and run validations. > Validation rules can be with UI or UI can make either of above options. > > Open for any other approach. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15641) No error if consistency_level = SERIAL and unqualified select
[
https://issues.apache.org/jira/browse/CASSANDRA-15641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15641:
Bug Category: Parent values: Correctness(12982)Level 1 values:
Consistency(12989)
Complexity: Low Hanging Fruit
Discovered By: User Report
Fix Version/s: 4.0-rc
Severity: Normal
Status: Open (was: Triage Needed)
> No error if consistency_level = SERIAL and unqualified select
> -
>
> Key: CASSANDRA-15641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15641
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Konstantin
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: test.py
>
>
> The attached test program produces no errors, while doesn't provide serial
> consistency. There is no exception that the consistency level is incorrect.
> It's simply silently downgraded. The issue is not documented either.
> kostja@atlas ~ % python test.py
> Row(a=1, b=1)
> Row(a=0, b=0)
> Row(a=2, b=2)
> Row(a=3, b=3)
> Row(a=1, b=1)
> Row(a=2, b=2)
> The behavior is contrary to the original intent by LWT author, since the code
> has the following check:
>if (group.queries.size() > 1)
> throw new InvalidRequestException("SERIAL/LOCAL_SERIAL
> consistency may only be requested for one partition at a time");
> https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/StorageProxy.java#L1593
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15644) Schema/Query analyzer
[ https://issues.apache.org/jira/browse/CASSANDRA-15644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkata Harikrishna Nukala updated CASSANDRA-15644: --- Description: This proposal is to build schema/cql analyser which can help users to analyze their queries before it is too late. User may create stability issues by - Running expensive queries against cluster like , SELECT * or query without where clause or IN clause with many values etc. - Creating not so optimal schemas - Leaving scope for data loss or schema with performance issue (keyspace with durable writes set to false or table with many secondary indexes etc...). Most of the times these Dos & Don'ts go into some knowledge base/documentation as best practices. Having rules for best practices (which user can execute against statements) can help to avoid bad schema/queries getting executed in cluster. The main idea is to enable the users to take corrective actions, by 1) Allowing a user to validate a DDL/DML statements before it is applied/executed. 2) Allowing a user to validate existing schema/queries. Imo, a validation result should: 1. Have severity 2. Tell where it hurts like instance/replica set/cluster. 3. Tell if it causes data loss. 4. Tell the strategy to recover. Few approaches I can think of: 1. Write validation rules at server side + have a new type of statement to run validations (something like MySQL's EXPLAIN) and return validation results/errors. 2. Keep validation rules in sidecar + expose a service to run validations. In this case user can submit his statements to this API and get validation results. 3. Expose a UI in sidecar which accepts statements and run validations. Validation rules can be with UI or UI can make either of above options. Open for any other approach. was: This proposal is to build schema/cql analyser which can help users to analyze their queries before it is too late. User may create stability issues by - Running expensive queries against cluster like , SELECT * or query without where clause or IN clause with many values etc. - Creating not so optimal schemas - Leaving scope for data loss (keyspace with durable writes set to false or table with many secondary indexes etc...). Most of the times these Dos & Don'ts go into some knowledge base/documentation as best practices. Having rules for best practices (which user can execute against statements) can help to avoid bad schema/queries getting executed in cluster. The main idea is to enable the users to take corrective actions, by 1) Allowing a user to validate a DDL/DML statements before it is applied/executed. 2) Allowing a user to validate existing schema/queries. Imo, a validation result should: 1. Have severity 2. Tell where it hurts like instance/replica set/cluster. 3. Tell if it causes data loss. 4. Tell the strategy to recover. Few approaches I can think of: 1. Write validation rules at server side + have a new type of statement to run validations (something like MySQL's EXPLAIN) and return validation results/errors. 2. Keep validation rules in sidecar + expose a service to run validations. In this case user can submit his statements to this API and get validation results. 3. Expose a UI in sidecar which accepts statements and run validations. Validation rules can be with UI or UI can make either of above options. Open for any other approach. > Schema/Query analyzer > - > > Key: CASSANDRA-15644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15644 > Project: Cassandra > Issue Type: New Feature >Reporter: Venkata Harikrishna Nukala >Assignee: Venkata Harikrishna Nukala >Priority: Normal > > This proposal is to build schema/cql analyser which can help users to analyze > their queries before it is too late. > > User may create stability issues by > - Running expensive queries against cluster like , SELECT * or query without > where clause or IN clause with many values etc. > - Creating not so optimal schemas > - Leaving scope for data loss or schema with performance issue (keyspace > with durable writes set to false or table with many secondary indexes etc...). > > Most of the times these Dos & Don'ts go into some knowledge > base/documentation as best practices. Having rules for best practices (which > user can execute against statements) can help to avoid bad schema/queries > getting executed in cluster. The main idea is to enable the users to take > corrective actions, by > 1) Allowing a user to validate a DDL/DML statements before it is > applied/executed. > 2) Allowing a user to validate existing schema/queries. > > Imo, a validation result should: > 1. Have severity > 2. Tell where it hurts like instance/replica set/cluster. > 3. Tell if it causes data
[jira] [Commented] (CASSANDRA-15644) Schema/Query analyzer
[ https://issues.apache.org/jira/browse/CASSANDRA-15644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060246#comment-17060246 ] Venkata Harikrishna Nukala commented on CASSANDRA-15644: As it is a new feature, I am not expecting it to be picked up for 4.0 release. > Schema/Query analyzer > - > > Key: CASSANDRA-15644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15644 > Project: Cassandra > Issue Type: New Feature >Reporter: Venkata Harikrishna Nukala >Assignee: Venkata Harikrishna Nukala >Priority: Normal > > This proposal is to build schema/cql analyser which can help users to analyze > their queries before it is too late. > > User may create stability issues by > - Running expensive queries against cluster like , SELECT * or query without > where clause or IN clause with many values etc. > - Creating not so optimal schemas > - Leaving scope for data loss (keyspace with durable writes set to false or > table with many secondary indexes etc...). > > Most of the times these Dos & Don'ts go into some knowledge > base/documentation as best practices. Having rules for best practices (which > user can execute against statements) can help to avoid bad schema/queries > getting executed in cluster. The main idea is to enable the users to take > corrective actions, by > 1) Allowing a user to validate a DDL/DML statements before it is > applied/executed. > 2) Allowing a user to validate existing schema/queries. > > Imo, a validation result should: > 1. Have severity > 2. Tell where it hurts like instance/replica set/cluster. > 3. Tell if it causes data loss. > 4. Tell the strategy to recover. > > Few approaches I can think of: > 1. Write validation rules at server side + have a new type of statement to > run validations (something like MySQL's EXPLAIN) and return validation > results/errors. > 2. Keep validation rules in sidecar + expose a service to run validations. In > this case user can submit his statements to this API and get validation > results. > 3. Expose a UI in sidecar which accepts statements and run validations. > Validation rules can be with UI or UI can make either of above options. > > Open for any other approach. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15644) Schema/Query analyzer
Venkata Harikrishna Nukala created CASSANDRA-15644: -- Summary: Schema/Query analyzer Key: CASSANDRA-15644 URL: https://issues.apache.org/jira/browse/CASSANDRA-15644 Project: Cassandra Issue Type: New Feature Reporter: Venkata Harikrishna Nukala Assignee: Venkata Harikrishna Nukala This proposal is to build schema/cql analyser which can help users to analyze their queries before it is too late. User may create stability issues by - Running expensive queries against cluster like , SELECT * or query without where clause or IN clause with many values etc. - Creating not so optimal schemas - Leaving scope for data loss (keyspace with durable writes set to false or table with many secondary indexes etc...). Most of the times these Dos & Don'ts go into some knowledge base/documentation as best practices. Having rules for best practices (which user can execute against statements) can help to avoid bad schema/queries getting executed in cluster. The main idea is to enable the users to take corrective actions, by 1) Allowing a user to validate a DDL/DML statements before it is applied/executed. 2) Allowing a user to validate existing schema/queries. Imo, a validation result should: 1. Have severity 2. Tell where it hurts like instance/replica set/cluster. 3. Tell if it causes data loss. 4. Tell the strategy to recover. Few approaches I can think of: 1. Write validation rules at server side + have a new type of statement to run validations (something like MySQL's EXPLAIN) and return validation results/errors. 2. Keep validation rules in sidecar + expose a service to run validations. In this case user can submit his statements to this API and get validation results. 3. Expose a UI in sidecar which accepts statements and run validations. Validation rules can be with UI or UI can make either of above options. Open for any other approach. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15643) Follow up on CASSANDRA-15616
[
https://issues.apache.org/jira/browse/CASSANDRA-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060233#comment-17060233
]
Ekaterina Dimitrova commented on CASSANDRA-15643:
-
[Pull request|https://github.com/apache/cassandra/pull/474]
[Branch|https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15643]
[~mck], can you, please, review when you have some time?
Thanks
> Follow up on CASSANDRA-15616
> -
>
> Key: CASSANDRA-15643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15643
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Add {{java.rmi.server.randomID}} to the systems_table
> System.getProperty("java.home")
> to be switched to
> System.getenv("JAVA_HOME")
>
> Oracle JVM might use the JRE which do not contain jmap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15643) Follow up on CASSANDRA-15616
[
https://issues.apache.org/jira/browse/CASSANDRA-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15643:
Test and Documentation Plan: Nit, no need of CI or documentation for now
Status: Patch Available (was: In Progress)
> Follow up on CASSANDRA-15616
> -
>
> Key: CASSANDRA-15643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15643
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Add {{java.rmi.server.randomID}} to the systems_table
> System.getProperty("java.home")
> to be switched to
> System.getenv("JAVA_HOME")
>
> Oracle JVM might use the JRE which do not contain jmap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15212) CassandraInputStream Bugs
[
https://issues.apache.org/jira/browse/CASSANDRA-15212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060212#comment-17060212
]
ZhaoYang commented on CASSANDRA-15212:
--
is it already fixed in CASSANDRA-13938?
> CassandraInputStream Bugs
> -
>
> Key: CASSANDRA-15212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15212
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/SSTable
>Reporter: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0
>
>
> Unexpected EOF locks up executing thread forever (no timeout), and seemingly
> cannot successfully stream partitions that cross compressed chunk boundaries
> (per currently disabled \{{RepairTest}} migrated from pydtests)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14517) Short read protection can cause partial updates to be read
[ https://issues.apache.org/jira/browse/CASSANDRA-14517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhaoYang updated CASSANDRA-14517: - Fix Version/s: (was: 4.0) 4.x Changed fix version to 4.x ..Please let me know if you think differently.. > Short read protection can cause partial updates to be read > -- > > Key: CASSANDRA-14517 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14517 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Blake Eggleston >Priority: Normal > Fix For: 4.x > > > If a read is performed in two parts due to short read protection, and the > data being read is written to between reads, the coordinator will return a > partial update. Specifically, this will occur if a single partition batch > updates clustering values on both sides of the SRP break, or if a range > tombstone is written that deletes data on both sides of the break. At the > coordinator level, this breaks the expectation that updates to a partition > are atomic, and that you can’t see partial updates. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
[
https://issues.apache.org/jira/browse/CASSANDRA-15369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060161#comment-17060161
]
ZhaoYang edited comment on CASSANDRA-15369 at 3/16/20, 12:18 PM:
-
Changes in [trunk patch|https://github.com/apache/cassandra/pull/473/files]:
1. Return row range tombstone (aka, covering 1 row) instead row deletion when
doing single partition named query(aka. with full clustering keys) on a range
tombstone in memtable.
* The reason I chose row RT instead row deletion is that I am trying to make
named query consistent with slice query where fake RT are created for slice
clustering bound.
* For example, in a table with pk, ck1, ck2, ck3, there is existing deletion
pk=1 & ck=1 with timestamp 10. After the patch:
** query with pk=1 should return the RT as it is, as query covers origin RT.
** query with pk=1 & ck1=1 should return the RT as it is, as query covers
origin RT.
** query with pk=1 & ck1=1 & ck2=1 should return fake RT with ClusteringBound
ck1=1 & ck2=1.
** query with pk=1 & ck1=1 & ck2=1 & ck3=1 should return fake RT with
ClusteringBound ck1=1 & ck2=1 & ck3=1.
2. When partition deletion timestamp ties with range tombstone or row deletion,
it will remove RT or row deletion when creating responses.
* Prior to the patch, partition deletion will only remove row deletion with
same timestamp during compaction, via {{Row.Merger.merge()}}
During testing, I found another issues related to SPRC skipping older sstables
causing digest mismatch: CASSANDRA-15640
[~benedict] WDYT?
was (Author: jasonstack):
Changes in [trunk patch|https://github.com/apache/cassandra/pull/473/files]:
1. Return row range tombstone (aka, covering 1 row) instead row deletion when
doing single partition named query(aka. with full clustering keys) on a range
tombstone in memtable.
* The reason I chose row RT instead row deletion is that I am trying to make
named query consistent with slice query where fake RT are created for slice
clustering bound.
* For example, in a table with pk, ck1, ck2, ck3, there is existing deletion
pk=1 & ck=1 with timestamp 10. After the patch:
** query with pk=1 should return the RT as it is, as query covers origin RT.
** query with pk=1 & ck1=1 should return the RT as it is, as query covers
origin RT.
** query with pk=1 & ck1=1 & ck2=1 should return fake RT with ClusteringBound
ck1=1 & ck2=1.
** query with pk=1 & ck1=1 & ck2=1 & ck3=1 should return fake RT with
ClusteringBound ck1=1 & ck2=1 & ck3=1.
2. When partition deletion timestamp ties with range tombstone or row deletion,
it will remove RT or row deletion when creating responses.
* Prior to the patch, partition deletion will only remove row deletion with
same timestamp during compaction, via {{Row.Merger.merge()}}
During testing, I found another issues related to SPRC skipping older sstables
causing digest mismatch: CASSANDRA-15640
> Fake row deletions and range tombstones, causing digest mismatch and sstable
> growth
> ---
>
> Key: CASSANDRA-15369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Benedict Elliott Smith
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> As assessed in CASSANDRA-15363, we generate fake row deletions and fake
> tombstone markers under various circumstances:
> * If we perform a clustering key query (or select a compact column):
> * Serving from a {{Memtable}}, we will generate fake row deletions
> * Serving from an sstable, we will generate fake row tombstone markers
> * If we perform a slice query, we will generate only fake row tombstone
> markers for any range tombstone that begins or ends outside of the limit of
> the requested slice
> * If we perform a multi-slice or IN query, this will occur for each
> slice/clustering
> Unfortunately, these different behaviours can lead to very different data
> stored in sstables until a full repair is run. When we read-repair, we only
> send these fake deletions or range tombstones. A fake row deletion,
> clustering RT and slice RT, each produces a different digest. So for each
> single point lookup we can produce a digest mismatch twice, and until a full
> repair is run we can encounter an unlimited number of digest mismatches
> across different overlapping queries.
> Relatedly, this seems a more problematic variant of our atomicity failures
> caused by our monotonic reads, since RTs can have an atomic effect across (up
> to) the entire partition, whereas the propagation may happen on an
> arbitrarily small portion. If the RT exists on only one
[jira] [Updated] (CASSANDRA-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
[
https://issues.apache.org/jira/browse/CASSANDRA-15369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15369:
-
Test and Documentation Plan:
Added unit tests to read RT with named queries and slice queries.
[CIrcle
CI|https://circleci.com/gh/jasonstack/cassandra/820?utm_campaign=vcs-integration-link_medium=referral_source=github-build-link]
looks good.
Status: Patch Available (was: In Progress)
> Fake row deletions and range tombstones, causing digest mismatch and sstable
> growth
> ---
>
> Key: CASSANDRA-15369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Benedict Elliott Smith
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> As assessed in CASSANDRA-15363, we generate fake row deletions and fake
> tombstone markers under various circumstances:
> * If we perform a clustering key query (or select a compact column):
> * Serving from a {{Memtable}}, we will generate fake row deletions
> * Serving from an sstable, we will generate fake row tombstone markers
> * If we perform a slice query, we will generate only fake row tombstone
> markers for any range tombstone that begins or ends outside of the limit of
> the requested slice
> * If we perform a multi-slice or IN query, this will occur for each
> slice/clustering
> Unfortunately, these different behaviours can lead to very different data
> stored in sstables until a full repair is run. When we read-repair, we only
> send these fake deletions or range tombstones. A fake row deletion,
> clustering RT and slice RT, each produces a different digest. So for each
> single point lookup we can produce a digest mismatch twice, and until a full
> repair is run we can encounter an unlimited number of digest mismatches
> across different overlapping queries.
> Relatedly, this seems a more problematic variant of our atomicity failures
> caused by our monotonic reads, since RTs can have an atomic effect across (up
> to) the entire partition, whereas the propagation may happen on an
> arbitrarily small portion. If the RT exists on only one node, this could
> plausibly lead to fairly problematic scenario if that node fails before the
> range can be repaired.
> At the very least, this behaviour can lead to an almost unlimited amount of
> extraneous data being stored until the range is repaired and compaction
> happens to overwrite the sub-range RTs and row deletions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
[
https://issues.apache.org/jira/browse/CASSANDRA-15369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060161#comment-17060161
]
ZhaoYang commented on CASSANDRA-15369:
--
Changes in [trunk patch|https://github.com/apache/cassandra/pull/473/files]:
1. Return row range tombstone (aka, covering 1 row) instead row deletion when
doing single partition named query(aka. with full clustering keys) on a range
tombstone in memtable.
* The reason I chose row RT instead row deletion is that I am trying to make
named query consistent with slice query where fake RT are created for slice
clustering bound.
* For example, in a table with pk, ck1, ck2, ck3, there is existing deletion
pk=1 & ck=1 with timestamp 10. After the patch:
** query with pk=1 should return the RT as it is, as query covers origin RT.
** query with pk=1 & ck1=1 should return the RT as it is, as query covers
origin RT.
** query with pk=1 & ck1=1 & ck2=1 should return fake RT with ClusteringBound
ck1=1 & ck2=1.
** query with pk=1 & ck1=1 & ck2=1 & ck3=1 should return fake RT with
ClusteringBound ck1=1 & ck2=1 & ck3=1.
2. When partition deletion timestamp ties with range tombstone or row deletion,
it will remove RT or row deletion when creating responses.
* Prior to the patch, partition deletion will only remove row deletion with
same timestamp during compaction, via {{Row.Merger.merge()}}
During testing, I found another issues related to SPRC skipping older sstables
causing digest mismatch: CASSANDRA-15640
> Fake row deletions and range tombstones, causing digest mismatch and sstable
> growth
> ---
>
> Key: CASSANDRA-15369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Benedict Elliott Smith
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> As assessed in CASSANDRA-15363, we generate fake row deletions and fake
> tombstone markers under various circumstances:
> * If we perform a clustering key query (or select a compact column):
> * Serving from a {{Memtable}}, we will generate fake row deletions
> * Serving from an sstable, we will generate fake row tombstone markers
> * If we perform a slice query, we will generate only fake row tombstone
> markers for any range tombstone that begins or ends outside of the limit of
> the requested slice
> * If we perform a multi-slice or IN query, this will occur for each
> slice/clustering
> Unfortunately, these different behaviours can lead to very different data
> stored in sstables until a full repair is run. When we read-repair, we only
> send these fake deletions or range tombstones. A fake row deletion,
> clustering RT and slice RT, each produces a different digest. So for each
> single point lookup we can produce a digest mismatch twice, and until a full
> repair is run we can encounter an unlimited number of digest mismatches
> across different overlapping queries.
> Relatedly, this seems a more problematic variant of our atomicity failures
> caused by our monotonic reads, since RTs can have an atomic effect across (up
> to) the entire partition, whereas the propagation may happen on an
> arbitrarily small portion. If the RT exists on only one node, this could
> plausibly lead to fairly problematic scenario if that node fails before the
> range can be repaired.
> At the very least, this behaviour can lead to an almost unlimited amount of
> extraneous data being stored until the range is repaired and compaction
> happens to overwrite the sub-range RTs and row deletions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060138#comment-17060138
]
ZhaoYang commented on CASSANDRA-15303:
--
[~blerer] the commit looks good to me!
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15303:
---
Test and Documentation Plan: Verified by unit test
Status: Patch Available (was: Open)
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15303:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: Unit Test
Severity: Normal
Status: Open (was: Triage Needed)
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15303) drop column statement should not initialize timestamp because of statement cache
[
https://issues.apache.org/jira/browse/CASSANDRA-15303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060130#comment-17060130
]
Benjamin Lerer commented on CASSANDRA-15303:
The fix looks good. I just believe that we should fix the {{AlterTest}} test to
not use prepared statements for schema changes by default. I pushed a patch for
that
[here|https://github.com/apache/cassandra/commit/56c1b0538e344f030cec622f05b9bb220d93ef9f].
[~jasonstack] If my change looks good to you, I think we should push it at the
same time as your fix.
> drop column statement should not initialize timestamp because of statement
> cache
>
>
> Key: CASSANDRA-15303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15303
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> When executing drop-column query without timestamp,
> {{AlterTableStatement#Raw}} initializes a default timestamp and then the
> prepared statement is cached. The same timestamp will be reused for the same
> drop-column query. (related to CASSANDRA-13426)
>
> The fix is to use NULL timestamp to indicate: using statement execution time
> instead.
>
> patch:
> [https://github.com/jasonstack/cassandra/commits/fix-drop-column-timestamp]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14296) Fix eclipse-warnings introduced by 7544 parameter handling
[
https://issues.apache.org/jira/browse/CASSANDRA-14296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060129#comment-17060129
]
Ryan Svihla edited comment on CASSANDRA-14296 at 3/16/20, 11:23 AM:
I would say it's likely it got fixed somewhere else long ago. I just ran
eclipse-warnings from the latest trunk and the output generates no warnings.
{{eclipse-warnings:}}
{{ [echo] Running Eclipse Code Analysis. Output logged to
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}{{BUILD
SUCCESSFUL}}
{{Total time: 16 seconds}}
{{➜ cassandra git:(trunk) ✗ cat
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}
{{# 16/03/20 12:17:03 CET}}
{{# Eclipse Compiler for Java(TM) v20160829-0950, 3.12.1, Copyright IBM Corp
2000, 2015. All rights reserved.}}
{{➜ cassandra git:(trunk) ✗}}
was (Author: rssvihla):
I would say it's likely it got fixed somewhere else long ago. I just ran
eclipse-warnings from the latest trunk and the output generates no warnings.
{{eclipse-warnings:}}
{{ [echo] Running Eclipse Code Analysis. Output logged to
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}{{BUILD
SUCCESSFUL}}
{{Total time: 16 seconds}}
{{➜ cassandra git:(trunk) ✗ vim
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}
{{➜ cassandra git:(trunk) ✗ vim
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}
{{➜ cassandra git:(trunk) ✗ cat
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}
{{# 16/03/20 12:17:03 CET}}
{{# Eclipse Compiler for Java(TM) v20160829-0950, 3.12.1, Copyright IBM Corp
2000, 2015. All rights reserved.}}
{{➜ cassandra git:(trunk) ✗}}
> Fix eclipse-warnings introduced by 7544 parameter handling
> --
>
> Key: CASSANDRA-14296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14296
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0
>
>
> There are some Closables that aren't being closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14296) Fix eclipse-warnings introduced by 7544 parameter handling
[ https://issues.apache.org/jira/browse/CASSANDRA-14296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060129#comment-17060129 ] Ryan Svihla commented on CASSANDRA-14296: - I would say it's likely it got fixed somewhere else long ago. I just ran eclipse-warnings from the latest trunk and the output generates no warnings. eclipse-warnings: [echo] Running Eclipse Code Analysis. Output logged to /Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt BUILD SUCCESSFUL Total time: 16 seconds ➜ cassandra git:(trunk) ✗ cat /Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt # 16/03/20 12:17:03 CET # Eclipse Compiler for Java(TM) v20160829-0950, 3.12.1, Copyright IBM Corp 2000, 2015. All rights reserved. ➜ cassandra git:(trunk) ✗ > Fix eclipse-warnings introduced by 7544 parameter handling > -- > > Key: CASSANDRA-14296 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14296 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Streaming and Messaging >Reporter: Ariel Weisberg >Priority: Normal > Fix For: 4.0 > > > There are some Closables that aren't being closed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14296) Fix eclipse-warnings introduced by 7544 parameter handling
[
https://issues.apache.org/jira/browse/CASSANDRA-14296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060129#comment-17060129
]
Ryan Svihla edited comment on CASSANDRA-14296 at 3/16/20, 11:23 AM:
I would say it's likely it got fixed somewhere else long ago. I just ran
eclipse-warnings from the latest trunk and the output generates no warnings.
{{eclipse-warnings:}}
{{ [echo] Running Eclipse Code Analysis. Output logged to
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}{{BUILD
SUCCESSFUL}}
{{Total time: 16 seconds}}
{{➜ cassandra git:(trunk) ✗ vim
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}
{{➜ cassandra git:(trunk) ✗ vim
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}
{{➜ cassandra git:(trunk) ✗ cat
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt}}
{{# 16/03/20 12:17:03 CET}}
{{# Eclipse Compiler for Java(TM) v20160829-0950, 3.12.1, Copyright IBM Corp
2000, 2015. All rights reserved.}}
{{➜ cassandra git:(trunk) ✗}}
was (Author: rssvihla):
I would say it's likely it got fixed somewhere else long ago. I just ran
eclipse-warnings from the latest trunk and the output generates no warnings.
eclipse-warnings:
[echo] Running Eclipse Code Analysis. Output logged to
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt
BUILD SUCCESSFUL
Total time: 16 seconds
➜ cassandra git:(trunk) ✗ cat
/Users/ryansvihla/code/cassandra/build/ecj/eclipse_compiler_checks.txt
# 16/03/20 12:17:03 CET
# Eclipse Compiler for Java(TM) v20160829-0950, 3.12.1, Copyright IBM Corp
2000, 2015. All rights reserved.
➜ cassandra git:(trunk) ✗
> Fix eclipse-warnings introduced by 7544 parameter handling
> --
>
> Key: CASSANDRA-14296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14296
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0
>
>
> There are some Closables that aren't being closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
[
https://issues.apache.org/jira/browse/CASSANDRA-15369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15369:
-
Source Control Link: trunk: https://github.com/apache/cassandra/pull/473
(was: trunkL https://github.com/apache/cassandra/pull/473)
> Fake row deletions and range tombstones, causing digest mismatch and sstable
> growth
> ---
>
> Key: CASSANDRA-15369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Benedict Elliott Smith
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> As assessed in CASSANDRA-15363, we generate fake row deletions and fake
> tombstone markers under various circumstances:
> * If we perform a clustering key query (or select a compact column):
> * Serving from a {{Memtable}}, we will generate fake row deletions
> * Serving from an sstable, we will generate fake row tombstone markers
> * If we perform a slice query, we will generate only fake row tombstone
> markers for any range tombstone that begins or ends outside of the limit of
> the requested slice
> * If we perform a multi-slice or IN query, this will occur for each
> slice/clustering
> Unfortunately, these different behaviours can lead to very different data
> stored in sstables until a full repair is run. When we read-repair, we only
> send these fake deletions or range tombstones. A fake row deletion,
> clustering RT and slice RT, each produces a different digest. So for each
> single point lookup we can produce a digest mismatch twice, and until a full
> repair is run we can encounter an unlimited number of digest mismatches
> across different overlapping queries.
> Relatedly, this seems a more problematic variant of our atomicity failures
> caused by our monotonic reads, since RTs can have an atomic effect across (up
> to) the entire partition, whereas the propagation may happen on an
> arbitrarily small portion. If the RT exists on only one node, this could
> plausibly lead to fairly problematic scenario if that node fails before the
> range can be repaired.
> At the very least, this behaviour can lead to an almost unlimited amount of
> extraneous data being stored until the range is repaired and compaction
> happens to overwrite the sub-range RTs and row deletions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
[
https://issues.apache.org/jira/browse/CASSANDRA-15369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15369:
-
Source Control Link: trunkL https://github.com/apache/cassandra/pull/473
(was: https://github.com/apache/cassandra/pull/473)
> Fake row deletions and range tombstones, causing digest mismatch and sstable
> growth
> ---
>
> Key: CASSANDRA-15369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Benedict Elliott Smith
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> As assessed in CASSANDRA-15363, we generate fake row deletions and fake
> tombstone markers under various circumstances:
> * If we perform a clustering key query (or select a compact column):
> * Serving from a {{Memtable}}, we will generate fake row deletions
> * Serving from an sstable, we will generate fake row tombstone markers
> * If we perform a slice query, we will generate only fake row tombstone
> markers for any range tombstone that begins or ends outside of the limit of
> the requested slice
> * If we perform a multi-slice or IN query, this will occur for each
> slice/clustering
> Unfortunately, these different behaviours can lead to very different data
> stored in sstables until a full repair is run. When we read-repair, we only
> send these fake deletions or range tombstones. A fake row deletion,
> clustering RT and slice RT, each produces a different digest. So for each
> single point lookup we can produce a digest mismatch twice, and until a full
> repair is run we can encounter an unlimited number of digest mismatches
> across different overlapping queries.
> Relatedly, this seems a more problematic variant of our atomicity failures
> caused by our monotonic reads, since RTs can have an atomic effect across (up
> to) the entire partition, whereas the propagation may happen on an
> arbitrarily small portion. If the RT exists on only one node, this could
> plausibly lead to fairly problematic scenario if that node fails before the
> range can be repaired.
> At the very least, this behaviour can lead to an almost unlimited amount of
> extraneous data being stored until the range is repaired and compaction
> happens to overwrite the sub-range RTs and row deletions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch master updated: ninja-fix: build-scripts/cassandra-jvm-dtest.sh can't `exit 1` only because of test failures (CASSANDRA-15639)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new c90f969 ninja-fix: build-scripts/cassandra-jvm-dtest.sh can't `exit
1` only because of test failures (CASSANDRA-15639)
c90f969 is described below
commit c90f96911e0f3c4d093e1e2e8e16c7c28adf7b42
Author: mck
AuthorDate: Mon Mar 16 09:19:18 2020 +0100
ninja-fix: build-scripts/cassandra-jvm-dtest.sh can't `exit 1` only because
of test failures (CASSANDRA-15639)
---
build-scripts/cassandra-jvm-dtest.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/build-scripts/cassandra-jvm-dtest.sh
b/build-scripts/cassandra-jvm-dtest.sh
index 1304a82..0b41323 100755
--- a/build-scripts/cassandra-jvm-dtest.sh
+++ b/build-scripts/cassandra-jvm-dtest.sh
@@ -26,7 +26,7 @@ _main() {
local test_timeout
test_timeout=$(grep 'name="test.distributed.timeout"' build.xml | awk -F'"'
'{print $4}')
- ant testclasslist -Dtest.timeout="$test_timeout" -Dtest.classlistfile=<(
_list_tests_no_upgrade ) -Dtest.classlistprefix=distributed
+ ant testclasslist -Dtest.timeout="$test_timeout" -Dtest.classlistfile=<(
_list_tests_no_upgrade ) -Dtest.classlistprefix=distributed || echo "ant
testclasslist failed"
}
_main "$@"
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15369) Fake row deletions and range tombstones, causing digest mismatch and sstable growth
[
https://issues.apache.org/jira/browse/CASSANDRA-15369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15369:
-
Source Control Link: https://github.com/apache/cassandra/pull/473
> Fake row deletions and range tombstones, causing digest mismatch and sstable
> growth
> ---
>
> Key: CASSANDRA-15369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15369
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Benedict Elliott Smith
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> As assessed in CASSANDRA-15363, we generate fake row deletions and fake
> tombstone markers under various circumstances:
> * If we perform a clustering key query (or select a compact column):
> * Serving from a {{Memtable}}, we will generate fake row deletions
> * Serving from an sstable, we will generate fake row tombstone markers
> * If we perform a slice query, we will generate only fake row tombstone
> markers for any range tombstone that begins or ends outside of the limit of
> the requested slice
> * If we perform a multi-slice or IN query, this will occur for each
> slice/clustering
> Unfortunately, these different behaviours can lead to very different data
> stored in sstables until a full repair is run. When we read-repair, we only
> send these fake deletions or range tombstones. A fake row deletion,
> clustering RT and slice RT, each produces a different digest. So for each
> single point lookup we can produce a digest mismatch twice, and until a full
> repair is run we can encounter an unlimited number of digest mismatches
> across different overlapping queries.
> Relatedly, this seems a more problematic variant of our atomicity failures
> caused by our monotonic reads, since RTs can have an atomic effect across (up
> to) the entire partition, whereas the propagation may happen on an
> arbitrarily small portion. If the RT exists on only one node, this could
> plausibly lead to fairly problematic scenario if that node fails before the
> range can be repaired.
> At the very least, this behaviour can lead to an almost unlimited amount of
> extraneous data being stored until the range is repaired and compaction
> happens to overwrite the sub-range RTs and row deletions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
