[cassandra-website] branch master updated: minor fixes to make the site work with self serve, documentation fixes
This is an automated email from the ASF dual-hosted git repository. rustyrazorblade pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/master by this push: new a4aee75 minor fixes to make the site work with self serve, documentation fixes a4aee75 is described below commit a4aee756ae4d468c3516cca98b4b072e3f1b5d29 Author: Jon Haddad AuthorDate: Thu Oct 10 13:10:47 2019 -0700 minor fixes to make the site work with self serve, documentation fixes --- README.md | 6 +++--- docker-compose.yml | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index bec21f1..54ce543 100644 --- a/README.md +++ b/README.md @@ -20,7 +20,7 @@ $ cd ./cassandra-website ``` -To build the website run the following commands from within the _./cassandra-website_ directory (assuming you used the above checkout commands): +To build the website run the following commands from within the `./cassandra-website` directory (assuming you used the above clone command): ```bash $ docker-compose build cassandra-website @@ -29,7 +29,7 @@ $ docker-compose run cassandra-website Go make yourself a cup of coffee, this will take a while... -Once building has completed, the site content will be in the _./cassandra-website/publish_ directory ready to be committed. +Once building has completed, the site content will be in the `./cassandra-website/content` directory ready to be committed. Previewing the site @@ -42,4 +42,4 @@ $ docker-compose build cassandra-website $ docker-compose up cassandra-website-serve ``` -For information about the site layout see the **Layout** section of [README](src/README#layout) in the _src_ directory. \ No newline at end of file +For information about the site layout see the **Layout** section of [README](src/README#layout) in the _src_ directory. diff --git a/docker-compose.yml b/docker-compose.yml index 027ab57..261f99c 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -6,7 +6,7 @@ services: image: cassandra-website:latest volumes: - ./src:/usr/src/cassandra-site/src - - ./content:/usr/src/cassandra-site/publish + - ./content:/usr/src/cassandra-site/content cassandra-website-serve: build: . @@ -16,5 +16,5 @@ services: - 4000:4000 volumes: - ./src:/usr/src/cassandra-site/src - - ./content:/usr/src/cassandra-site/publish + - ./content:/usr/src/cassandra-site/content - ./docker-entrypoint-jekyll-serve.sh:/docker-entrypoint-jekyll-serve.sh - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15351) Allow configuring timeouts on the per-request basis
[ https://issues.apache.org/jira/browse/CASSANDRA-15351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948838#comment-16948838 ] Sankalp Kohli commented on CASSANDRA-15351: --- Dupe of https://issues.apache.org/jira/browse/CASSANDRA-2848 ?? > Allow configuring timeouts on the per-request basis > --- > > Key: CASSANDRA-15351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15351 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Priority: Normal > > Some queries need to be ran with a higher timeout value, which should be > possible without allowing _all_ requests to be above this value. -- 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-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948722#comment-16948722
]
mazhenlin commented on CASSANDRA-15169:
---
[~mck] I hava uploaded a new patch that sets checkFully=true only for RANGE
operators and only when is_literal=false. Also , new test cases are added for
blob comparison and string prefix matching. Please review.
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch, CASSANDRA-15169-v2.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
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-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mazhenlin updated CASSANDRA-15169:
--
Attachment: CASSANDRA-15169-v2.patch
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch, CASSANDRA-15169-v2.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
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-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15169:
---
Test and Documentation Plan: unit test (was: I don't know what is supposed
to write here, so I just type some words to get through the step.
It is a tiny modification and I have wrote a UT along with the fix to reproduce
the bug .)
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
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-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948391#comment-16948391
]
mazhenlin edited comment on CASSANDRA-15169 at 10/10/19 10:36 AM:
--
[~mck] Thank you for your comments. I went deeper and found that I had made
some mistakes before.
Since isSatisfiedBy will be called for every record in term later, it is
acceptable to incorrectly include a term by
isUpperSatisfiedBy/isLowerSatisfiedBy, but omitting a term incorrectly is not
acceptable.
I was wrong about isUpperSatisfiedBy. The checkFully=false is required for the
LIKE_PREFIX operator because otherwise term could be omitted by
isUpperSatisfiedBy incorrectly. But for the GT operator, checkFully need to be
true in isLowerSatisfiedBy and isUpperSatisfiedBy( for ReversedType ).
The OnDiskIndexTest.testNotEqualsQueryForStrings failed because it uses NEQ as
"not like prefix" semantic.
So I think it should work to set checkFully=true only for RANGE operators and
only when is_literal=false( to retain the "not like prefix" semantic of NEQ) .
was (Author: mazhenlin):
[~mck] Thank you for your comments. I went deeper and found that I had made
some mistakes before.
Since isSatisfiedBy will be called for every record in term later, it is
acceptable to incorrectly include a term by
isUpperSatisfiedBy/isLowerSatisfiedBy, but omitting a term incorrectly is not
acceptable.
I was wrong about isUpperSatisfiedBy. The checkFully=false is required for the
LIKE_PREFIX operator because otherwise term could be omitted by
isUpperSatisfiedBy incorrectly. But for the GT operator, checkFully need to be
true in isLowerSatisfiedBy and isUpperSatisfiedBy( for ReversedType ).
The OnDiskIndexTest.testNotEqualsQueryForStrings failed because it uses NEQ as
"not like" semantic.
So I think it should work to set checkFully=true only for RANGE operator and
only when is_literal=false( to retain the "not like" semantic of NEQ) .
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
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-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948391#comment-16948391
]
mazhenlin commented on CASSANDRA-15169:
---
[~mck] Thank you for your comments. I went deeper and found that I had made
some mistakes before.
Since isSatisfiedBy will be called for every record in term later, it is
acceptable to incorrectly include a term by
isUpperSatisfiedBy/isLowerSatisfiedBy, but omitting a term incorrectly is not
acceptable.
I was wrong about isUpperSatisfiedBy. The checkFully=false is required for the
LIKE_PREFIX operator because otherwise term could be omitted by
isUpperSatisfiedBy incorrectly. But for the GT operator, checkFully need to be
true in isLowerSatisfiedBy and isUpperSatisfiedBy( for ReversedType ).
The OnDiskIndexTest.testNotEqualsQueryForStrings failed because it uses NEQ as
"not like" semantic.
So I think it should work to set checkFully=true only for RANGE operator and
only when is_literal=false( to retain the "not like" semantic of NEQ) .
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
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-15349) Add “Going away” message to the client protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948380#comment-16948380 ] Jorge Bay commented on CASSANDRA-15349: --- Should we introduce this along a time window, between announcement and the actual close of the client connections? Currently the drivers get the protocol event from a single control connection. We should give time from the event to propagate to the rest of nodes and from there to clients. Otherwise, if the event is sent in close succession to the client connection tcp close, it won't be of much benefit. > Add “Going away” message to the client protocol > --- > > Key: CASSANDRA-15349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15349 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Priority: Normal > Labels: client-impacting > > Add “Going away” message that allows node to announce its shutdown and let > clients gracefully shutdown and not attempt further requests. -- 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-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[ https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay updated CASSANDRA-15350: -- Labels: client-impacting protocolv5 (was: protocolv5) > Add CAS “uncertainty” and “contention" messages that are currently propagated > as a WriteTimeoutException. > - > > Key: CASSANDRA-15350 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15350 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Lightweight Transactions >Reporter: Alex Petrov >Priority: Normal > Labels: client-impacting, protocolv5 > > Right now, CAS uncertainty introduced in > https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as > WriteTimeout. One of this conditions it manifests is when there’s at least > one acceptor that has accepted the value, which means that this value _may_ > still get accepted during the later round, despite the proposer failure. > Similar problem happens with CAS contention, which is also indistinguishable > from the “regular” timeout, even though it is visible in metrics correctly. -- 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-15329) in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader
[ https://issues.apache.org/jira/browse/CASSANDRA-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15329: Source Control Link: https://github.com/apache/cassandra/commit/c55d727bbe8d66e87497d6c8b6301a767b11bb4c > in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader > -- > > Key: CASSANDRA-15329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15329 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Attachments: CASSANDRA-15329.patch > > > When running the in-JVM dtests on on java 11 they fail while trying to cast > the Versions.class.getClassLoader to URLClassLoader, which is no longer the > default ClassLoader on java 11. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15329) in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader
[ https://issues.apache.org/jira/browse/CASSANDRA-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948327#comment-16948327 ] Alex Petrov commented on CASSANDRA-15329: - Thank you! Committed as [c55d727bbe8d66e87497d6c8b6301a767b11bb4c|https://github.com/apache/cassandra/commit/c55d727bbe8d66e87497d6c8b6301a767b11bb4c] to trunk. > in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader > -- > > Key: CASSANDRA-15329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15329 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Attachments: CASSANDRA-15329.patch > > > When running the in-JVM dtests on on java 11 they fail while trying to cast > the Versions.class.getClassLoader to URLClassLoader, which is no longer the > default ClassLoader on java 11. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15329) in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader
[ https://issues.apache.org/jira/browse/CASSANDRA-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-15329: Resolution: Fixed Status: Resolved (was: Triage Needed) > in-JVM dtest fails on java 11 since system ClassLoader is not a URLClassLoader > -- > > Key: CASSANDRA-15329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15329 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Attachments: CASSANDRA-15329.patch > > > When running the in-JVM dtests on on java 11 they fail while trying to cast > the Versions.class.getClassLoader to URLClassLoader, which is no longer the > default ClassLoader on java 11. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix in-JVM dtest failures on java 11 as the system ClassLoader is not a URLClassLoader as of java 9
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen 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 c55d727 Fix in-JVM dtest failures on java 11 as the system
ClassLoader is not a URLClassLoader as of java 9
c55d727 is described below
commit c55d727bbe8d66e87497d6c8b6301a767b11bb4c
Author: David Capwell
AuthorDate: Thu Sep 19 16:23:29 2019 -0700
Fix in-JVM dtest failures on java 11 as the system ClassLoader is not a
URLClassLoader as of java 9
Patch by David Capwell, reviewed by Jon Meredith and Alex Petrov for
CASSANDRA-15329.
---
.../cassandra/distributed/impl/Versions.java | 27 --
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git
a/test/distributed/org/apache/cassandra/distributed/impl/Versions.java
b/test/distributed/org/apache/cassandra/distributed/impl/Versions.java
index dba1c13..c75816b 100644
--- a/test/distributed/org/apache/cassandra/distributed/impl/Versions.java
+++ b/test/distributed/org/apache/cassandra/distributed/impl/Versions.java
@@ -21,7 +21,7 @@ package org.apache.cassandra.distributed.impl;
import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;
-import java.net.URLClassLoader;
+import java.nio.file.Paths;
import java.util.ArrayList;
import java.util.Collections;
import java.util.Comparator;
@@ -40,7 +40,30 @@ import org.apache.cassandra.utils.FBUtilities;
public class Versions
{
private static final Logger logger =
LoggerFactory.getLogger(Versions.class);
-public static Version CURRENT = new
Version(FBUtilities.getReleaseVersionString(),
((URLClassLoader)Versions.class.getClassLoader()).getURLs());
+public static Version CURRENT = new
Version(FBUtilities.getReleaseVersionString(), getClassPath());
+
+private static URL[] getClassPath()
+{
+// In Java 9 the default system ClassLoader got changed from
URLClassLoader to AppClassLoader which
+// does not extend URLClassLoader nor does it give access to the class
path array.
+// Java requires the system property 'java.class.path' to be setup
with the classpath seperated by :
+// so this logic parses that string into the URL[] needed to build
later
+String cp = System.getProperty("java.class.path");
+assert cp != null && !cp.isEmpty();
+String[] split = cp.split(File.pathSeparator);
+assert split.length > 0;
+URL[] urls = new URL[split.length];
+try
+{
+for (int i = 0; i < split.length; i++)
+urls[i] = Paths.get(split[i]).toUri().toURL();
+}
+catch (MalformedURLException e)
+{
+throw new RuntimeException(e);
+}
+return urls;
+}
public enum Major
{
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14477) The check of num_tokens against the length of inital_token in the yaml triggers unexpectedly
[
https://issues.apache.org/jira/browse/CASSANDRA-14477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948313#comment-16948313
]
Michael Semb Wever commented on CASSANDRA-14477:
[~VincentWhite],
- could you split the test method into three methods, one for each of the
configuration scenarios being tested?
- in the 3.11 branch could you return {{num_tokens}} to a boxed type,
CASSANDRA-12199 only intended primitives to be used where there was a default
value, and here you've demonstrated that there shouldn't be a default value as
{{num_tokens}} and {{initial_token}} are exclusive,
- and, could you rebase both branches please? (test currently fails for me
without rebasing)
> The check of num_tokens against the length of inital_token in the yaml
> triggers unexpectedly
>
>
> Key: CASSANDRA-14477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14477
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Vincent White
>Assignee: Vincent White
>Priority: Low
>
> In CASSANDRA-10120 we added a check that compares num_tokens against the
> number of tokens supplied in the yaml via initial_token. From my reading of
> CASSANDRA-10120 it was to prevent cassandra starting if the yaml contained
> contradictory values for num_tokens and initial_tokens which should help
> prevent misconfiguration via human error. The current behaviour appears to
> differ slightly in that it performs this comparison regardless of whether
> num_tokens is included in the yaml or not. Below are proposed patches to only
> perform the check if both options are present in the yaml.
> ||Branch||
> |[3.0.x|https://github.com/apache/cassandra/compare/cassandra-3.0...vincewhite:num_tokens_30]|
> |[3.x|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:num_tokens_test_1_311]|
--
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-14477) The check of num_tokens against the length of inital_token in the yaml triggers unexpectedly
[ https://issues.apache.org/jira/browse/CASSANDRA-14477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14477: --- Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Michael Semb Wever, Michael Semb Wever Status: Review In Progress (was: Patch Available) > The check of num_tokens against the length of inital_token in the yaml > triggers unexpectedly > > > Key: CASSANDRA-14477 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14477 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Vincent White >Assignee: Vincent White >Priority: Low > > In CASSANDRA-10120 we added a check that compares num_tokens against the > number of tokens supplied in the yaml via initial_token. From my reading of > CASSANDRA-10120 it was to prevent cassandra starting if the yaml contained > contradictory values for num_tokens and initial_tokens which should help > prevent misconfiguration via human error. The current behaviour appears to > differ slightly in that it performs this comparison regardless of whether > num_tokens is included in the yaml or not. Below are proposed patches to only > perform the check if both options are present in the yaml. > ||Branch|| > |[3.0.x|https://github.com/apache/cassandra/compare/cassandra-3.0...vincewhite:num_tokens_30]| > |[3.x|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:num_tokens_test_1_311]| -- 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-dtest] branch master updated: Add cqlsh test for protocol negotiation
This is an automated email from the ASF dual-hosted git repository.
samt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/master by this push:
new 9ca95e1 Add cqlsh test for protocol negotiation
9ca95e1 is described below
commit 9ca95e115fda079fa6e5e1f71663484f0328698a
Author: Sam Tunnicliffe
AuthorDate: Tue Jul 9 16:58:24 2019 +0100
Add cqlsh test for protocol negotiation
Also, disable automatic protocol version capping for batch_test
Patch by Sam Tunnicliffe; reviewed by Alex Petrov for CASSANDRA-15193
closes #54
---
batch_test.py | 2 +-
cqlsh_tests/test_cqlsh.py | 37 +
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/batch_test.py b/batch_test.py
index 48b6d87..586d888 100644
--- a/batch_test.py
+++ b/batch_test.py
@@ -505,4 +505,4 @@ class TestBatch(Tester):
remove_perf_disable_shared_mem(node)
# Restart nodes on new version
logger.debug('Starting {} on new version ({})'.format(node.name,
node.get_cassandra_version()))
-node.start(wait_other_notice=True, wait_for_binary_proto=True)
+node.start(wait_other_notice=True, wait_for_binary_proto=True,
jvm_args=['-Dcassandra.disable_max_protocol_auto_override=true'])
diff --git a/cqlsh_tests/test_cqlsh.py b/cqlsh_tests/test_cqlsh.py
index 5023828..ab905c5 100644
--- a/cqlsh_tests/test_cqlsh.py
+++ b/cqlsh_tests/test_cqlsh.py
@@ -1571,6 +1571,43 @@ Tracing session:""")
stdout, stderr = self.run_cqlsh(node1, cmds='USE system',
cqlsh_options=['--debug', '--connect-timeout=10'])
assert "Using connect timeout: 10 seconds" in stderr
+@since('3.0.19')
+def test_protocol_negotiation(self):
+"""
+@jira_ticket CASSANDRA-15193
+"""
+self.cluster.populate(1)
+self.cluster.start(wait_for_binary_proto=True)
+
+node1, = self.cluster.nodelist()
+stdout, stderr = self.run_cqlsh(node1, cmds='USE system',
cqlsh_options=['--tty'])
+assert "Native protocol v4" in stdout
+
+stdout, stderr = self.run_cqlsh(node1, cmds='USE systeml',
cqlsh_options=['--protocol-version=3', '--tty'])
+assert "Native protocol v3" in stdout
+
+@since('3.0.19')
+def test_protocol_version_restriction(self):
+"""
+@jira_ticket CASSANDRA-15193
+"""
+self.cluster.populate(1)
+self.cluster.set_configuration_options({
'native_transport_max_negotiable_protocol_version': str(3)})
+self.cluster.start(wait_for_binary_proto=True)
+
+node1, = self.cluster.nodelist()
+stdout, stderr = self.run_cqlsh(node1, cmds='USE system',
cqlsh_options=['--tty'])
+# yaml property is deprecated from 4.0 and has no effect
+if node1.get_cassandra_version() < '4.0':
+assert "Native protocol v3" in stdout
+
+node1, = self.cluster.nodelist()
+stdout, stderr = self.run_cqlsh(node1, cmds='USE system',
cqlsh_options=['--protocol-version=4', '--tty'])
+# yaml property is deprecated from 4.0 and has no effect
+if node1.get_cassandra_version() < '4.0':
+assert "ProtocolError returned from server while using explicitly
set client protocol_version 4" in stderr
+
+
def test_update_schema_with_down_node(self):
"""
Test that issuing a DML statement after a DDL statement will work with
a down node
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15295) Running into deadlock when do CommitLog initialization
[ https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948268#comment-16948268 ] Zephyr Guo edited comment on CASSANDRA-15295 at 10/10/19 7:49 AM: -- Hi, [~djoshi] thanks for the review. I agree with most of what you said. Your change is very minimal for this issue. But something else I have to remind you. 1. Most of the changes in my patch are to build a UT to check the exception case for CommitLog. It's worth it for Cassandra. Not only we have to fix this problem but we also need to understand the root cause of the problem (lack of exception tests). 2. Your change introduces the risk of starting twice. CommitLog was designed as a singleton and It manages lifecycle by itself. When other modules call CommitLog.instance, they expect an initialized CommitLog. You change the original initialization process. 3. The major change (move to a different class) is very simple. The change DOES NOT change any original initialization process. 4. I agree with that "I think it is important to get the correctness issue resolved first". Don't you think that moving the code to another class is the easiest? I respect your decision to incorporate my patch to get a better one. What's next? was (Author: gzh1992n): Hi, [~djoshi] thanks for the review. I agree with most of what you said. Your change is very minimal for this issue. But something else I have to remind you. 1. Most of the changes in my patch are to build a UT to check the exception case for CommitLog. It's worth it for Cassandra. Not only we have to fix this problem but we also need to understand the root cause of the problem (lack of exception tests). 2. Your change introduces the risk of starting twice. CommitLog was designed as a singleton and It manages lifecycle by itself. When other modules call CommitLog.instance, they expect an initialized CommitLog. You change the original initialization process. 3. The major change (move to a different class) is very simple. The change DOES NOT change any original initialization process. 4. I agree with that "I think it is important to get the correctness issue resolved first". Don't you think that moving the code to another class is the easiest? I respect your decision, incorporate my patch to get a better one. What's next? > Running into deadlock when do CommitLog initialization > -- > > Key: CASSANDRA-15295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15295 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: jstack.log, pstack.log, screenshot-1.png, > screenshot-2.png, screenshot-3.png > > > Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a > long time. > I used jstack to saw what happened. The main thread stuck in > *AbstractCommitLogSegmentManager.awaitAvailableSegment* > !screenshot-1.png! > The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it > was not actually running. > !screenshot-2.png! > And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on > java class initialization. > !screenshot-3.png! > This is a deadlock obviously. CommitLog waits for a CommitLogSegment when > initializing. In this moment, the CommitLog class is not initialized and the > main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a > CommitLogSegment with exception and call *CommitLog.handleCommitError*(static > method). COMMIT-LOG-ALLOCATOR will block on this line because CommitLog > class is still initializing. > > -- 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-15349) Add “Going away” message to the client protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948279#comment-16948279 ] Romain Hardouin commented on CASSANDRA-15349: - It would be really nice for smooth rolling restarts (y) > Add “Going away” message to the client protocol > --- > > Key: CASSANDRA-15349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15349 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Priority: Normal > Labels: client-impacting > > Add “Going away” message that allows node to announce its shutdown and let > clients gracefully shutdown and not attempt further requests. -- 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-15295) Running into deadlock when do CommitLog initialization
[ https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948268#comment-16948268 ] Zephyr Guo edited comment on CASSANDRA-15295 at 10/10/19 7:20 AM: -- Hi, [~djoshi] thanks for the review. I agree with most of what you said. Your change is very minimal for this issue. But something else I have to remind you. 1. Most of the changes in my patch are to build a UT to check the exception case for CommitLog. It's worth it for Cassandra. Not only we have to fix this problem but we also need to understand the root cause of the problem (lack of exception tests). 2. Your change introduces the risk of starting twice. CommitLog was designed as a singleton and It manages lifecycle by itself. When other modules call CommitLog.instance, they expect an initialized CommitLog. You change the original initialization process. 3. The major change (move to a different class) is very simple. The change DOES NOT change any original initialization process. 4. I agree with that "I think it is important to get the correctness issue resolved first". Don't you think that moving the code to another class is the easiest? I respect your decision, incorporate my patch to get a better one. What's next? was (Author: gzh1992n): Hi, [~djoshi] thanks for the review. I agree with most of what you said. Your change is very minimal for this issue. But something else I have to remind you. 1. Most of the changes in my patch are to build a UT to check the exception case for CommitLog. It's worth it for Cassandra. Not only we have to fix this problem but we also need to understand the root cause of the problem (lack of exception tests). 2. Your change introduces the risk of starting twice. CommitLog was designed to a singleton and It manages lifecycle by itself. When other modules call CommitLog.instance, they expect an initialized CommitLog. You change the original initialization process. 3. The major change (move to a different class) is very simple. The change DOES NOT change any original initialization process. 4. I agree with that "I think it is important to get the correctness issue resolved first". Don't you think that moving the code to another class is the easiest? I respect your decision, incorporate my patch to get a better one. What's next? > Running into deadlock when do CommitLog initialization > -- > > Key: CASSANDRA-15295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15295 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: jstack.log, pstack.log, screenshot-1.png, > screenshot-2.png, screenshot-3.png > > > Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a > long time. > I used jstack to saw what happened. The main thread stuck in > *AbstractCommitLogSegmentManager.awaitAvailableSegment* > !screenshot-1.png! > The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it > was not actually running. > !screenshot-2.png! > And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on > java class initialization. > !screenshot-3.png! > This is a deadlock obviously. CommitLog waits for a CommitLogSegment when > initializing. In this moment, the CommitLog class is not initialized and the > main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a > CommitLogSegment with exception and call *CommitLog.handleCommitError*(static > method). COMMIT-LOG-ALLOCATOR will block on this line because CommitLog > class is still initializing. > > -- 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-15295) Running into deadlock when do CommitLog initialization
[ https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948268#comment-16948268 ] Zephyr Guo edited comment on CASSANDRA-15295 at 10/10/19 7:18 AM: -- Hi, [~djoshi] thanks for the review. I agree with most of what you said. Your change is very minimal for this issue. But something else I have to remind you. 1. Most of the changes in my patch are to build a UT to check the exception case for CommitLog. It's worth it for Cassandra. Not only we have to fix this problem but we also need to understand the root cause of the problem (lack of exception tests). 2. Your change introduces the risk of starting twice. CommitLog was designed to a singleton and It manages lifecycle by itself. When other modules call CommitLog.instance, they expect an initialized CommitLog. You change the original initialization process. 3. The major change (move to a different class) is very simple. The change DOES NOT change any original initialization process. 4. I agree with that "I think it is important to get the correctness issue resolved first". Don't you think that moving the code to another class is the easiest? I respect your decision, incorporate my patch to get a better one. What's next? was (Author: gzh1992n): Hi, [~djoshi] thanks for the review. I agree with most of what you said. Your change is very minimal for this issue. But something else I have to remind you. 1. Most of the changes in my patch are going to build a UT that ensures the exception case for CommitLog. It's worth it for Cassandra. Not only we have to fix this problem but we also need to understand the root cause of the problem (lack of exception tests). 2. Your change introduces the risk of starting twice. CommitLog was designed to a singleton and It manages lifecycle by itself. When other modules call CommitLog.instance, they expect an initialized CommitLog. You change the original initialization process. 3. The major change (move to a different class) is very simple. The change DOES NOT change any original initialization process. 4. I agree with that "I think it is important to get the correctness issue resolved first". Don't you think that moving the code to another class is the easiest? I respect your decision, incorporate my patch to get a better one. What's next? > Running into deadlock when do CommitLog initialization > -- > > Key: CASSANDRA-15295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15295 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: jstack.log, pstack.log, screenshot-1.png, > screenshot-2.png, screenshot-3.png > > > Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a > long time. > I used jstack to saw what happened. The main thread stuck in > *AbstractCommitLogSegmentManager.awaitAvailableSegment* > !screenshot-1.png! > The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it > was not actually running. > !screenshot-2.png! > And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on > java class initialization. > !screenshot-3.png! > This is a deadlock obviously. CommitLog waits for a CommitLogSegment when > initializing. In this moment, the CommitLog class is not initialized and the > main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a > CommitLogSegment with exception and call *CommitLog.handleCommitError*(static > method). COMMIT-LOG-ALLOCATOR will block on this line because CommitLog > class is still initializing. > > -- 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-15295) Running into deadlock when do CommitLog initialization
[ https://issues.apache.org/jira/browse/CASSANDRA-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948268#comment-16948268 ] Zephyr Guo commented on CASSANDRA-15295: Hi, [~djoshi] thanks for the review. I agree with most of what you said. Your change is very minimal for this issue. But something else I have to remind you. 1. Most of the changes in my patch are going to build a UT that ensures the exception case for CommitLog. It's worth it for Cassandra. Not only we have to fix this problem but we also need to understand the root cause of the problem (lack of exception tests). 2. Your change introduces the risk of starting twice. CommitLog was designed to a singleton and It manages lifecycle by itself. When other modules call CommitLog.instance, they expect an initialized CommitLog. You change the original initialization process. 3. The major change (move to a different class) is very simple. The change DOES NOT change any original initialization process. 4. I agree with that "I think it is important to get the correctness issue resolved first". Don't you think that moving the code to another class is the easiest? I respect your decision, incorporate my patch to get a better one. What's next? > Running into deadlock when do CommitLog initialization > -- > > Key: CASSANDRA-15295 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15295 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Zephyr Guo >Assignee: Zephyr Guo >Priority: Normal > Attachments: jstack.log, pstack.log, screenshot-1.png, > screenshot-2.png, screenshot-3.png > > > Recently, I found a cassandra(3.11.4) node stuck in STARTING status for a > long time. > I used jstack to saw what happened. The main thread stuck in > *AbstractCommitLogSegmentManager.awaitAvailableSegment* > !screenshot-1.png! > The strange thing is COMMIT-LOG-ALLOCATOR thread state was runnable but it > was not actually running. > !screenshot-2.png! > And then I used pstack to troubleshoot. I found COMMIT-LOG-ALLOCATOR block on > java class initialization. > !screenshot-3.png! > This is a deadlock obviously. CommitLog waits for a CommitLogSegment when > initializing. In this moment, the CommitLog class is not initialized and the > main thread holds the class lock. After that, COMMIT-LOG-ALLOCATOR creates a > CommitLogSegment with exception and call *CommitLog.handleCommitError*(static > method). COMMIT-LOG-ALLOCATOR will block on this line because CommitLog > class is still initializing. > > -- 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-15353) Documentation Preview - Cassandra 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent White reassigned CASSANDRA-15353: - Assignee: Vincent White > Documentation Preview - Cassandra 4.0 > - > > Key: CASSANDRA-15353 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15353 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: Vincent White >Priority: Normal > > Please review, and add comments to, some of the documentation preview for > Apache Cassandra 4.0. > *TODOs * > _Read Repair_ > https://docs.google.com/document/d/1qkyXPAYjkb2fFAP5WAOJ9KGTrRQ79Cl4nhuydf0m03U/edit?usp=sharing > _Full Repair Example_ > https://docs.google.com/document/d/1Hxncmze_KNhpDQjrvePMfhGnspZEuwW8tqgqrMAMp4Q/edit?usp=sharing > *New Features * > _Support for Java 11_ > https://docs.google.com/document/d/1v7ffccqk_5Son4iwfuwZae8YUam41quewKi_6Z_PQGw/edit?usp=sharing > *Improvements * > _Improved Streaming_ > https://docs.google.com/document/d/1zd6AuHBgC82v598cuDtVIkxJVDV9c0A2rrMEVFHyB4Y/edit?usp=sharing > _Improved Internode Messaging_ > https://docs.google.com/document/d/1ub2DBHE7hNEKe4tuCOpdbCZ7qGqCdMAYvSTC-YamuMA/edit?usp=sharing -- 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-15353) Documentation Preview - Cassandra 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent White reassigned CASSANDRA-15353: - Assignee: (was: Vincent White) > Documentation Preview - Cassandra 4.0 > - > > Key: CASSANDRA-15353 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15353 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: DeepakVohra >Priority: Normal > > Please review, and add comments to, some of the documentation preview for > Apache Cassandra 4.0. > *TODOs * > _Read Repair_ > https://docs.google.com/document/d/1qkyXPAYjkb2fFAP5WAOJ9KGTrRQ79Cl4nhuydf0m03U/edit?usp=sharing > _Full Repair Example_ > https://docs.google.com/document/d/1Hxncmze_KNhpDQjrvePMfhGnspZEuwW8tqgqrMAMp4Q/edit?usp=sharing > *New Features * > _Support for Java 11_ > https://docs.google.com/document/d/1v7ffccqk_5Son4iwfuwZae8YUam41quewKi_6Z_PQGw/edit?usp=sharing > *Improvements * > _Improved Streaming_ > https://docs.google.com/document/d/1zd6AuHBgC82v598cuDtVIkxJVDV9c0A2rrMEVFHyB4Y/edit?usp=sharing > _Improved Internode Messaging_ > https://docs.google.com/document/d/1ub2DBHE7hNEKe4tuCOpdbCZ7qGqCdMAYvSTC-YamuMA/edit?usp=sharing -- 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
