[jira] [Updated] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
[ https://issues.apache.org/jira/browse/CASSANDRA-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mayank pesswani updated CASSANDRA-14996: Attachment: patch_CASSANDRA-14996.html > Incremental backups can fill up the disk if they are not being uploaded > --- > > Key: CASSANDRA-14996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 > Project: Cassandra > Issue Type: Improvement >Reporter: Shaurya Gupta >Priority: Major > Attachments: patch_CASSANDRA-14996, patch_CASSANDRA-14996.html > > > This creates a major problem if the script which uploads the snapshots is > triggered via some API and the application triggering it is somehow down and > is not able to hit the API. This affects Cassandra and slowly one or more > Cassandra nodes go down. > There could be a check in Cassandra that before creating a snapshot it checks > that the disk has some sufficient (configurable via cassandra.yaml and jmx) > disk space. > This could be achieved by making change in > public void maybeIncrementallyBackup(final Iterable sstables) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
[ https://issues.apache.org/jira/browse/CASSANDRA-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753817#comment-16753817 ] mayank pesswani commented on CASSANDRA-14996: - To Solve This Use Case. A New Config has been added in cassandra.yaml. "min_free_space_percentile_for_incremental_backups" It's Default value is 0.2. That Means getUsableSpace() / getTotalSpace() should be bigger than configured value. > Incremental backups can fill up the disk if they are not being uploaded > --- > > Key: CASSANDRA-14996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 > Project: Cassandra > Issue Type: Improvement >Reporter: Shaurya Gupta >Priority: Major > Attachments: patch_CASSANDRA-14996, patch_CASSANDRA-14996.html > > > This creates a major problem if the script which uploads the snapshots is > triggered via some API and the application triggering it is somehow down and > is not able to hit the API. This affects Cassandra and slowly one or more > Cassandra nodes go down. > There could be a check in Cassandra that before creating a snapshot it checks > that the disk has some sufficient (configurable via cassandra.yaml and jmx) > disk space. > This could be achieved by making change in > public void maybeIncrementallyBackup(final Iterable sstables) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14972) Provide a script or method to generate the entire website at the push of a button
[ https://issues.apache.org/jira/browse/CASSANDRA-14972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14972: Status: Patch Available (was: Open) > Provide a script or method to generate the entire website at the push of a > button > - > > Key: CASSANDRA-14972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14972 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Anthony Grasso >Assignee: Anthony Grasso >Priority: Major > Attachments: 14972_Dockerfile_v2, 14972_README_v1, Dockerfile, > docker-compose.yml, docker-entrypoint.sh > > > The process involved to generate the website involves two repositories (Git > and SVN), a range of tools, and a number of steps. > It would be good to have a script or something similar which we run and it > will generate the entire website for us which is ready to commit back into > SVN for publication. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14972) Provide a script or method to generate the entire website at the push of a button
[ https://issues.apache.org/jira/browse/CASSANDRA-14972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14972: Reviewers: mck > Provide a script or method to generate the entire website at the push of a > button > - > > Key: CASSANDRA-14972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14972 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Anthony Grasso >Assignee: Anthony Grasso >Priority: Major > Attachments: 14972_Dockerfile_v2, 14972_README_v1, Dockerfile, > docker-compose.yml, docker-entrypoint.sh > > > The process involved to generate the website involves two repositories (Git > and SVN), a range of tools, and a number of steps. > It would be good to have a script or something similar which we run and it > will generate the entire website for us which is ready to commit back into > SVN for publication. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14972) Provide a script or method to generate the entire website at the push of a button
[ https://issues.apache.org/jira/browse/CASSANDRA-14972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753828#comment-16753828 ] mck commented on CASSANDRA-14972: - This is +1 from me. Keen to get a quick second review, [~mshuler], [~zznate]? > Provide a script or method to generate the entire website at the push of a > button > - > > Key: CASSANDRA-14972 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14972 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Anthony Grasso >Assignee: Anthony Grasso >Priority: Major > Attachments: 14972_Dockerfile_v2, 14972_README_v1, Dockerfile, > docker-compose.yml, docker-entrypoint.sh > > > The process involved to generate the website involves two repositories (Git > and SVN), a range of tools, and a number of steps. > It would be good to have a script or something similar which we run and it > will generate the entire website for us which is ready to commit back into > SVN for publication. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14131) Full FreeBSD support
[ https://issues.apache.org/jira/browse/CASSANDRA-14131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753873#comment-16753873 ] Lapo Luchini commented on CASSANDRA-14131: -- JTLUK Cassandra 3.11.3 has been [committed to FreeBSD Ports|https://www.freshports.org/databases/cassandra3/]. > Full FreeBSD support > > > Key: CASSANDRA-14131 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14131 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination >Reporter: Konrad Jopek >Priority: Major > Attachments: cassandra-freebsd.patch > > > FreeBSD had problems with Cassandra (CASSANDRA-8325). Attached patch is > modified version of untested_2.2.4-src.patch from mentioned task and also > adds native libraries support for FreeBSD. > TODO: Add KQueue support in the same manner as Epoll. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Validate token() arguments early instead of throwing NPE at execution
This is an automated email from the ASF dual-hosted git repository.
aleksey 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 174cf76 Validate token() arguments early instead of throwing NPE at
execution
174cf76 is described below
commit 174cf761f7897443080b8a840b649b7eab17ae25
Author: Dinesh A. Joshi
AuthorDate: Mon Jan 28 12:29:46 2019 +
Validate token() arguments early instead of throwing NPE at execution
patch by Dinesh Joshi; reviewed by Aleksey Yeschenko and Jon Meredith
for CASSANDRA-14989
---
CHANGES.txt| 1 +
.../cassandra/cql3/functions/FunctionResolver.java | 52 ++-
.../cql3/validation/operations/SelectTest.java | 73 ++
3 files changed, 111 insertions(+), 15 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index a0c51f0..852cccf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0
+ * Validate token() arguments early instead of throwing NPE at execution
(CASSANDRA-14989)
* Add a new tool to dump audit logs (CASSANDRA-14885)
* Fix generating javadoc with Java11 (CASSANDRA-14988)
* Only cancel conflicting compactions when starting anticompactions and sub
range compactions (CASSANDRA-14935)
diff --git a/src/java/org/apache/cassandra/cql3/functions/FunctionResolver.java
b/src/java/org/apache/cassandra/cql3/functions/FunctionResolver.java
index 99c0fca..ae5d17e 100644
--- a/src/java/org/apache/cassandra/cql3/functions/FunctionResolver.java
+++ b/src/java/org/apache/cassandra/cql3/functions/FunctionResolver.java
@@ -69,8 +69,32 @@ public final class FunctionResolver
AbstractType receiverType)
throws InvalidRequestException
{
+Collection candidates = collectCandidates(keyspace, name,
receiverKs, receiverCf, receiverType);
+
+if (candidates.isEmpty())
+return null;
+
+// Fast path if there is only one choice
+if (candidates.size() == 1)
+{
+Function fun = candidates.iterator().next();
+validateTypes(keyspace, fun, providedArgs, receiverKs, receiverCf);
+return fun;
+}
+
+return pickBestMatch(keyspace, name, providedArgs, receiverKs,
receiverCf, receiverType, candidates);
+}
+
+private static Collection collectCandidates(String keyspace,
+ FunctionName name,
+ String receiverKs,
+ String receiverCf,
+ AbstractType
receiverType)
+{
+Collection candidates = new ArrayList<>();
+
if (name.equalsNativeFunction(TOKEN_FUNCTION_NAME))
-return new TokenFct(Schema.instance.getTableMetadata(receiverKs,
receiverCf));
+candidates.add(new
TokenFct(Schema.instance.getTableMetadata(receiverKs, receiverCf)));
// The toJson() function can accept any type of argument, so instances
of it are not pre-declared. Instead,
// we create new instances as needed while handling selectors (which
is the only place that toJson() is supported,
@@ -83,14 +107,12 @@ public final class FunctionResolver
{
if (receiverType == null)
throw new InvalidRequestException("fromJson() cannot be used
in the selection clause of a SELECT statement");
-return FromJsonFct.getInstance(receiverType);
+candidates.add(FromJsonFct.getInstance(receiverType));
}
-Collection candidates;
if (!name.hasKeyspace())
{
// function name not fully qualified
-candidates = new ArrayList<>();
// add 'SYSTEM' (native) candidates
candidates.addAll(Schema.instance.getFunctions(name.asNativeFunction()));
// add 'current keyspace' candidates
@@ -99,20 +121,19 @@ public final class FunctionResolver
else
{
// function name is fully qualified (keyspace + name)
-candidates = Schema.instance.getFunctions(name);
+candidates.addAll(Schema.instance.getFunctions(name));
}
-if (candidates.isEmpty())
-return null;
-
-// Fast path if there is only one choice
-if (candidates.size() == 1)
-{
-Function fun = candidates.iterator().next();
-validateTypes(keyspace, fun, providedArgs, receiverKs, receiverCf);
-return fun;
-}
+return candidates;
+}
+private static Function pickBestMatch(String keyspace,
+ FunctionName name,
+ List
providedArgs,
+
[jira] [Resolved] (CASSANDRA-14989) NullPointerException when SELECTing token() on only one part of a two-part partition key
[
https://issues.apache.org/jira/browse/CASSANDRA-14989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko resolved CASSANDRA-14989.
---
Resolution: Fixed
Fix Version/s: (was: 3.11.x)
(was: 3.0.x)
Reviewers: Aleksey Yeschenko, Jon Meredith (was: Jon Meredith)
Reproduced In: 3.11.3, 3.0.17, 4.0 (was: 3.0.17, 3.11.3, 4.0)
The first two unit tests were exact duplicates of each other, so I removed one,
and added a missing test for mismatched argument counts.
Committed to trunk as
[174cf761f7897443080b8a840b649b7eab17ae25|https://github.com/apache/cassandra/commit/174cf761f7897443080b8a840b649b7eab17ae25],
thanks.
> NullPointerException when SELECTing token() on only one part of a two-part
> partition key
>
>
> Key: CASSANDRA-14989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14989
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
> Environment: Using {{cqlsh 5.0.1}} on a Mac OS X host system with
> Cassandra 3.11.3 running via Docker for Mac from the official
> {{cassandra:3.11.3}} image.
>Reporter: Manuel Kießling
>Assignee: Dinesh Joshi
>Priority: Minor
> Fix For: 4.0
>
>
> I have the following schema:
> {code}
> CREATE TABLE query_tests.cart_snapshots (
> cart_id uuid,
> realm text,
> snapshot_id timeuuid,
> state text,
> PRIMARY KEY ((cart_id, realm), snapshot_id)
> ) WITH CLUSTERING ORDER BY (snapshot_id DESC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> In cqlsh, I try the following query:
> {code}select token(cart_id) from cart_snapshots ;{code}
> This results in cqlsh returning {{ServerError:
> java.lang.NullPointerException}}, and the following error in the server log:
> {code}
> DC1N1_1 | ERROR [Native-Transport-Requests-1] 2019-01-16 12:17:52,075
> QueryMessage.java:129 - Unexpected error during query
> DC1N1_1 | java.lang.NullPointerException: null
> DC1N1_1 | at
> org.apache.cassandra.db.marshal.CompositeType.build(CompositeType.java:356)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.db.marshal.CompositeType.build(CompositeType.java:349)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.config.CFMetaData.serializePartitionKey(CFMetaData.java:805)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.functions.TokenFct.execute(TokenFct.java:59)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.selection.ScalarFunctionSelector.getOutput(ScalarFunctionSelector.java:61)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing$1.getOutputRow(Selection.java:666)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.selection.Selection$ResultSetBuilder.getOutputRow(Selection.java:492)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.selection.Selection$ResultSetBuilder.newRow(Selection.java:458)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:860)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:790)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:438)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:416)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:289)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatem
[jira] [Commented] (CASSANDRA-14989) NullPointerException when SELECTing token() on only one part of a two-part partition key
[
https://issues.apache.org/jira/browse/CASSANDRA-14989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753962#comment-16753962
]
Aleksey Yeschenko commented on CASSANDRA-14989:
---
Didn't commit to 3.0 or 3.11, but don't mind backporting, in principle, despite
the issue not being a major one.
> NullPointerException when SELECTing token() on only one part of a two-part
> partition key
>
>
> Key: CASSANDRA-14989
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14989
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
> Environment: Using {{cqlsh 5.0.1}} on a Mac OS X host system with
> Cassandra 3.11.3 running via Docker for Mac from the official
> {{cassandra:3.11.3}} image.
>Reporter: Manuel Kießling
>Assignee: Dinesh Joshi
>Priority: Minor
> Fix For: 4.0
>
>
> I have the following schema:
> {code}
> CREATE TABLE query_tests.cart_snapshots (
> cart_id uuid,
> realm text,
> snapshot_id timeuuid,
> state text,
> PRIMARY KEY ((cart_id, realm), snapshot_id)
> ) WITH CLUSTERING ORDER BY (snapshot_id DESC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> {code}
> In cqlsh, I try the following query:
> {code}select token(cart_id) from cart_snapshots ;{code}
> This results in cqlsh returning {{ServerError:
> java.lang.NullPointerException}}, and the following error in the server log:
> {code}
> DC1N1_1 | ERROR [Native-Transport-Requests-1] 2019-01-16 12:17:52,075
> QueryMessage.java:129 - Unexpected error during query
> DC1N1_1 | java.lang.NullPointerException: null
> DC1N1_1 | at
> org.apache.cassandra.db.marshal.CompositeType.build(CompositeType.java:356)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.db.marshal.CompositeType.build(CompositeType.java:349)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.config.CFMetaData.serializePartitionKey(CFMetaData.java:805)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.functions.TokenFct.execute(TokenFct.java:59)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.selection.ScalarFunctionSelector.getOutput(ScalarFunctionSelector.java:61)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.selection.Selection$SelectionWithProcessing$1.getOutputRow(Selection.java:666)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.selection.Selection$ResultSetBuilder.getOutputRow(Selection.java:492)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.selection.Selection$ResultSetBuilder.newRow(Selection.java:458)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.processPartition(SelectStatement.java:860)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.process(SelectStatement.java:790)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.processResults(SelectStatement.java:438)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:416)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:289)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:117)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:224)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:255)
> ~[apache-cassandra-3.11.3.jar:3.11.3]
> DC1N1_1 | at
[jira] [Commented] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753986#comment-16753986
]
Stefan Podkowinski commented on CASSANDRA-14806:
I think ccm must be updated first for the new git url, so the tests actually
run. Can you try {{spod/cassandra-testing-ubuntu1810-java11-w-dependencies}} as
new docker image?
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14802) calculatePendingRanges assigns more pending ranges than necessary
[
https://issues.apache.org/jira/browse/CASSANDRA-14802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754286#comment-16754286
]
Sam Tunnicliffe commented on CASSANDRA-14802:
-
During concurrent replacements without any actual range movements occurring,
the pending ranges calculation can also be incorrect due to the fact that we
don't differentiate between {{BOOTSTRAP}} and {{BOOTSTRAP_REPLACE}}.
Updating {{allLeftMetadata}} with the tokens & endpoint for a
{{BOOTSTRAP_REPLACE}} doesn't grow the ring as it's a straight up replacement,
so the subsequent removal of the new endpoint after we grab its new ranges
actually constitutes a shrink, skewing the ownership represented by
{{allLeftMetadata}}. If there are concurrent replacements happening, this then
makes the pending ranges calculation for those tokens completely off.
> calculatePendingRanges assigns more pending ranges than necessary
> --
>
> Key: CASSANDRA-14802
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14802
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Coordination, Legacy/Distributed Metadata
>Reporter: Benedict
>Priority: Major
> Fix For: 4.x
>
>
> This might be a good thing, but should probably be configurable, and made
> consistent. Presently, in a number of circumstances where there are multiple
> range movements, {{calculatePendingRanges}} will assign a pending range to a
> node that will not ultimately own it. If done consistently, this might make
> range movements resilient to node failures / aborted range movements, since
> all nodes will be receiving all ranges they might own under any incomplete
> range ownership movements. But done inconsistently it seems only to reduce
> availability in the cluster, by potentially increasing the number of pending
> nodes unnecessarily.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14996) Incremental backups can fill up the disk if they are not being uploaded
[ https://issues.apache.org/jira/browse/CASSANDRA-14996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754459#comment-16754459 ] Blake Eggleston commented on CASSANDRA-14996: - This doesn’t seem like the right solution to the problem you’re describing. If I understand incremental backup correctly, occasionally skipping hard link creation defeats the purpose and will leave you with an incomplete backup and lost data on recovery. The real problem seems to be that you don’t notice that your backup system has failed or your nodes are out of disk space until nodes start falling over. I'd probably start by putting some monitoring and alerts around your cluster and backup system. > Incremental backups can fill up the disk if they are not being uploaded > --- > > Key: CASSANDRA-14996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14996 > Project: Cassandra > Issue Type: Improvement >Reporter: Shaurya Gupta >Priority: Major > Attachments: patch_CASSANDRA-14996, patch_CASSANDRA-14996.html > > > This creates a major problem if the script which uploads the snapshots is > triggered via some API and the application triggering it is somehow down and > is not able to hit the API. This affects Cassandra and slowly one or more > Cassandra nodes go down. > There could be a check in Cassandra that before creating a snapshot it checks > that the disk has some sufficient (configurable via cassandra.yaml and jmx) > disk space. > This could be achieved by making change in > public void maybeIncrementallyBackup(final Iterable sstables) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14871) Severe concurrency issues in STCS,DTCS,TWCS,TMD.Topology,TypeParser
[
https://issues.apache.org/jira/browse/CASSANDRA-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754461#comment-16754461
]
Blake Eggleston commented on CASSANDRA-14871:
-
[~snazy] ping
> Severe concurrency issues in STCS,DTCS,TWCS,TMD.Topology,TypeParser
> ---
>
> Key: CASSANDRA-14871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14871
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Critical
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> There are a couple of places in the code base that do not respect that
> j.u.HashMap + related classes are not thread safe and some parts rely on
> internals of the implementation of HM, which can change.
> We have observed failures like {{NullPointerException}} and
> {{ConcurrentModificationException}} as well as wrong behavior.
> Affected areas in the code base:
> * {{SizeTieredCompactionStrategy}}
> * {{DateTieredCompactionStrategy}}
> * {{TimeWindowCompactionStrategy}}
> * {{TokenMetadata.Topology}}
> * {{TypeParser}}
> * streaming / concurrent access to {{LifecycleTransaction}} (handled in
> CASSANDRA-14554)
> While the patches for the compaction strategies + {{TypeParser}} are pretty
> straight forward, the patch for {{TokenMetadata.Topology}} requires it to be
> made immutable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
