[cassandra-website] branch asf-staging updated (22ae39b55 -> 844919a9f)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 22ae39b55 generate docs for 8f277185 new 844919a9f generate docs for 8f277185 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (22ae39b55) \ N -- N -- N refs/heads/asf-staging (844919a9f) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17712) Remove javadocs step from CI and release process
[
https://issues.apache.org/jira/browse/CASSANDRA-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581135#comment-17581135
]
Berenguer Blasi commented on CASSANDRA-17712:
-
+1. No more javadocs are built. 2 runs are red but iiuc on some artifacts copy
error which I've seen before and I think it's unrelated.
> Remove javadocs step from CI and release process
>
>
> Key: CASSANDRA-17712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17712
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
>
> Currently the javadocs step is both:
> - Taking up jenkins cycles and generating a [large
> output|https://ci-cassandra.apache.org/job/Cassandra-trunk-artifacts/1313/jdk=jdk_1.8_latest,label=cassandra/consoleFull]
> in CI when building artifacts
> - Failing randomly on javadoc issues such as {{AlterTableStatement.java:135:
> error: text not allowed in element}}
> Apidocs are not being bundled, uploaded or used anywhere. Hence it would be
> best to remove javadocs generation on every CI. Mainly removing javadoc from
> artifacts and mvn-install.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17736) Settings Virtual Table should display the values assigned to a property in the DatabaseDescriptor on startup and not null (as per the yaml)
[ https://issues.apache.org/jira/browse/CASSANDRA-17736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581134#comment-17581134 ] Atri Sharma commented on CASSANDRA-17736: - [~e.dimitrova] I see a bunch of properties have a setter in DatabaseDescriptor, that gets called from various places within the code. However, some properties do not.I do not see these properties being referenced in specific JMX tests (checked around first 10).Is the task mostly about adding setters to DatabaseDescriptor for the missing properties? > Settings Virtual Table should display the values assigned to a property in > the DatabaseDescriptor on startup and not null (as per the yaml) > --- > > Key: CASSANDRA-17736 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17736 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Atri Sharma >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > There are a few properties that after startup do not show their assigned > values as per the DatabaseDescriptor assignment but the cassandra.yaml value. > They will not be also updated in the virtual table down the road in case they > are updated through JMX, nodetool etc. > *EDIT: This ticket should serve to check the properties that are not type > Duration, Data Storage and Data Rate; also that are not new to 4.1.* I will > post a list of who are those later today for convenience. We target all those > in Config class (some advanced properties are not broadly advertised in > cassandra.yaml intentionally). > There is [Settings Virtual Table > |https://cassandra.apache.org/doc/trunk/cassandra/new/virtualtables.html#settings-virtual-table] > which is supposed to show the values for our config parameters at any time. > Especially useful if any property was changed after startup through > JMX/nodetool and it doesn't match anymore the value in cassandra.yaml. For > this to be possible, we need to ensure that the parameters are always updated > in the Config class. It was observed that some are not always updating in > Config class, but after startup delegating to other internal variables. This > is a bug and this task should review and address any new findings. > Classes of interest - > [SettingsTable|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/virtual/SettingsTable.java] > where you can see how config parameters are listed; > [Config|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/Config.java] > class where our configuration parameters are defined. > We need patches 4.0 and above. I suggest you start looking into 4.0 branch > and then merge into higher branches. As you won't be checking the data > storage, data rate and duration type parameters, there shouldn't be many > conflicts on merge. > We have a lot of parameters and I suggest you split the list into batches to > check and produce patches where/if needed to make the work more incremental > and easier to work on and review it. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
[
https://issues.apache.org/jira/browse/CASSANDRA-17819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581129#comment-17581129
]
Jacek Lewandowski commented on CASSANDRA-17819:
---
[~e.dimitrova] would you like me to take this one?
> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> The test
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}},
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
> * 4.1:
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> * trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in
> org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
> at
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-15 15:02:14,783 Reflections.java:219 -
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO [main] 2022-08-15 15:02:16,407 Reflections.java:219 -
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> INFO [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (953819b2f -> 22ae39b55)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard 953819b2f generate docs for 8f277185
new 22ae39b55 generate docs for 8f277185
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (953819b2f)
\
N -- N -- N refs/heads/asf-staging (22ae39b55)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../cassandra/configuration}/configuration.html| 71 +++--
content/doc/4.1/cassandra/new/index.html | 3 +
.../cassandra/configuration}/configuration.html| 69 ++--
content/doc/4.2/cassandra/new/index.html | 3 +
.../cassandra/configuration}/configuration.html| 71 +++--
content/doc/latest/cassandra/new/index.html| 3 +
.../cassandra/configuration}/configuration.html| 69 ++--
content/doc/trunk/cassandra/new/index.html | 3 +
content/search-index.js| 2 +-
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
10 files changed, 215 insertions(+), 79 deletions(-)
rename content/doc/{latest/cassandra/new =>
4.1/cassandra/configuration}/configuration.html (96%)
rename content/doc/{trunk/cassandra/new =>
4.2/cassandra/configuration}/configuration.html (96%)
rename content/doc/{4.1/cassandra/new =>
latest/cassandra/configuration}/configuration.html (96%)
rename content/doc/{4.2/cassandra/new =>
trunk/cassandra/configuration}/configuration.html (96%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
Brad Schoening created CASSANDRA-17832:
--
Summary: Change bin/cqlsh.py shebang to use PATH with env prefix
Key: CASSANDRA-17832
URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
Project: Cassandra
Issue Type: Improvement
Reporter: Brad Schoening
For cqlsh.py this:
#!/usr/bin/env python
is preferable to the current hard coded /usr/bin/python3 which doesn't take
into account the python interpreter preferences in the users PATH.
'{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
strings containing the provided argument and returns the first instance it
finds. In the above syntax, {{env}} will search for the first instance of
{{python}} in {{$PATH}} and return it.
This is aligned with the recommendations in https://peps.python.org/pep-0394/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
[
https://issues.apache.org/jira/browse/CASSANDRA-17819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581094#comment-17581094
]
Ekaterina Dimitrova commented on CASSANDRA-17819:
-
I got curious and pushed the new test with the code before CASSANDRA-17658 was
committed and [it
seems|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1874/workflows/6d60a052-e3f6-44c2-9812-8ba863b32838/jobs/14687/tests#failed-test-0]
the timeout error was already there, the NullPointerException is new.
> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> The test
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}},
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
> * 4.1:
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> * trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in
> org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
> at
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-15 15:02:14,783 Reflections.java:219 -
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO [main] 2022-08-15 15:02:16,407 Reflections.java:219 -
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> INFO [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-17753: -- Source Control Link: https://github.com/apache/cassandra/pull/1729 > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abe Ratnofsky updated CASSANDRA-17753: -- Status: Review In Progress (was: Changes Suggested) > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581089#comment-17581089 ] Abe Ratnofsky commented on CASSANDRA-17753: --- Thanks for the clarification [~mck] – this makes sense to me. I just pushed a fix that checks if git is available first, and sets GitSHA=Unknown if not. I've tested this in situations where git is available (git clone'd repo) and not available (in the unzipped -src artifact directory) and it works as expected. Mind taking another look? > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17831) Add support in CQLSH for COPY FROM / TO in compact Parquet format
[
https://issues.apache.org/jira/browse/CASSANDRA-17831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17831:
---
Description:
CQL supports only CSV as a format for import and export. A binary big data
format such as Avro and/or Parquet would be more compact and highly portable to
other platforms.
Parquet does not require a schema, so it appears the easier format to support.
The existing syntax supports adding key value pair options, such as FORMAT =
PARQUET
{{ COPY table_name ... FROM 'file_name'[, 'file2_name', ...] }}
{{[WITH option = 'value' [AND ...]]}}
Side by side comparisons of CSV and Parquet show a 80% plus saving in disk
space.
[https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d]
was:
CQL supports only CSV as a format for import and export. A binary big data
format such as Avro and/or Parquet would be more compact and highly portable to
other platforms.
Parquet does not require a schema, so it appears the easier format to support.
The existing syntax supports adding key value pair options, such as FORMAT =
PARQUET
{{ COPY table_name ... FROM 'file_name'[, 'file2_name', ...] }}
{{{}{}}}{{{}[WITH option = 'value' [AND ...]]{}}}
{{{}{}}}Side by side comparisons of CSV and Parquet show a 80% plus saving in
disk space.
https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d
> Add support in CQLSH for COPY FROM / TO in compact Parquet format
> -
>
> Key: CASSANDRA-17831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17831
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
>
> CQL supports only CSV as a format for import and export. A binary big data
> format such as Avro and/or Parquet would be more compact and highly portable
> to other platforms.
> Parquet does not require a schema, so it appears the easier format to support.
> The existing syntax supports adding key value pair options, such as FORMAT =
> PARQUET
> {{ COPY table_name ... FROM 'file_name'[, 'file2_name', ...] }}
> {{[WITH option = 'value' [AND ...]]}}
> Side by side comparisons of CSV and Parquet show a 80% plus saving in disk
> space.
> [https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17831) Add support in CQLSH for COPY FROM / TO in compact Parquet format
[
https://issues.apache.org/jira/browse/CASSANDRA-17831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening reassigned CASSANDRA-17831:
--
Assignee: Brad Schoening
> Add support in CQLSH for COPY FROM / TO in compact Parquet format
> -
>
> Key: CASSANDRA-17831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17831
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
>
> CQL supports only CSV as a format for import and export. A binary big data
> format such as Avro and/or Parquet would be more compact and highly portable
> to other platforms.
> Parquet does not require a schema, so it appears the easier format to support.
> The existing syntax supports adding key value pair options, such as FORMAT =
> PARQUET
> {{ COPY table_name ... FROM 'file_name'[, 'file2_name', ...] }}
> {{{}{}}}{{{}[WITH option = 'value' [AND ...]]{}}}
> {{{}{}}}Side by side comparisons of CSV and Parquet show a 80% plus saving in
> disk space.
> https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17831) Add support in CQLSH for COPY FROM / TO in compact Parquet format
Brad Schoening created CASSANDRA-17831:
--
Summary: Add support in CQLSH for COPY FROM / TO in compact
Parquet format
Key: CASSANDRA-17831
URL: https://issues.apache.org/jira/browse/CASSANDRA-17831
Project: Cassandra
Issue Type: Improvement
Reporter: Brad Schoening
CQL supports only CSV as a format for import and export. A binary big data
format such as Avro and/or Parquet would be more compact and highly portable to
other platforms.
Parquet does not require a schema, so it appears the easier format to support.
The existing syntax supports adding key value pair options, such as FORMAT =
PARQUET
{{ COPY table_name ... FROM 'file_name'[, 'file2_name', ...] }}
{{{}{}}}{{{}[WITH option = 'value' [AND ...]]{}}}
{{{}{}}}Side by side comparisons of CSV and Parquet show a 80% plus saving in
disk space.
https://towardsdatascience.com/csv-files-for-storage-no-thanks-theres-a-better-option-72c78a414d1d
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17757) A user should not be able to manually remove ephemeral snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-17757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581074#comment-17581074 ] Paulo Motta edited comment on CASSANDRA-17757 at 8/17/22 11:30 PM: --- Looks mostly good. Added a few minor comments and created [this PR|https://github.com/instaclustr/cassandra/pull/47] to your branch with cosmetic suggestions. Let me know what do you think. was (Author: paulo): Looks mostly good. Added a few minor comments and cosmetic nits to the PR. > A user should not be able to manually remove ephemeral snapshots > > > Key: CASSANDRA-17757 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17757 > Project: Cassandra > Issue Type: New Feature > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.2 > > Time Spent: 20m > Remaining Estimate: 0h > > in CASSANDRA-16911 we introduced the "-e" flag to nodetool listsnaphots which > are returning ephemerals as well. An operator might try to remove these > snapshots by hand. This should not be possible as these snapshots are there > for repair to work on and manual removal breaks it. To be complete, these > snapshots are removed as part of repair mechanism automatically, or they are > removed on the next reboot upon node' start. They should never be removed by > a human. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17757) A user should not be able to manually remove ephemeral snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-17757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-17757: Status: Open (was: Patch Available) > A user should not be able to manually remove ephemeral snapshots > > > Key: CASSANDRA-17757 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17757 > Project: Cassandra > Issue Type: New Feature > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > in CASSANDRA-16911 we introduced the "-e" flag to nodetool listsnaphots which > are returning ephemerals as well. An operator might try to remove these > snapshots by hand. This should not be possible as these snapshots are there > for repair to work on and manual removal breaks it. To be complete, these > snapshots are removed as part of repair mechanism automatically, or they are > removed on the next reboot upon node' start. They should never be removed by > a human. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17757) A user should not be able to manually remove ephemeral snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-17757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581074#comment-17581074 ] Paulo Motta commented on CASSANDRA-17757: - Looks mostly good. Added a few minor comments and cosmetic nits to the PR. > A user should not be able to manually remove ephemeral snapshots > > > Key: CASSANDRA-17757 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17757 > Project: Cassandra > Issue Type: New Feature > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > in CASSANDRA-16911 we introduced the "-e" flag to nodetool listsnaphots which > are returning ephemerals as well. An operator might try to remove these > snapshots by hand. This should not be possible as these snapshots are there > for repair to work on and manual removal breaks it. To be complete, these > snapshots are removed as part of repair mechanism automatically, or they are > removed on the next reboot upon node' start. They should never be removed by > a human. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17778) WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu
[ https://issues.apache.org/jira/browse/CASSANDRA-17778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17778: Fix Version/s: 4.1-beta (was: 4.x) (was: 4.1.x) Source Control Link: https://github.com/apache/cassandra/commit/43036ecadda82dca35cc79eed0db52eec8d495ff Resolution: Fixed Status: Resolved (was: Ready to Commit) > WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu > -- > > Key: CASSANDRA-17778 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17778 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta > > > There is no way to navigate to the new configuration page for CASSANDRA-15234 > ([Liberating cassandra.yaml Parameters' Names from Their > Units|https://cassandra.apache.org/doc/trunk/cassandra/new/configuration.html]) > because it is not referenced anywhere. > Unless someone has bookmarked the page, there is no way to find it on the > site. > Other doc changes expected: > * Add a small table with supported units per type as currently we list only > the duration's ones and min units for old parameters. We list the supported > units only in NEWS.txt. > * Add info about the RuntimeExceptions we introduced in CASSANDRA-17725 for > a few deprecated JMX getters. > * Add a note for Cassandra developers - "Please ensure that any JMX > setters/getters update the Config class properties and not some local copies. > Settings Virtual Table reports the configuration loaded at any time from the > Config class." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17778) WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu
[ https://issues.apache.org/jira/browse/CASSANDRA-17778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581062#comment-17581062 ] Ekaterina Dimitrova commented on CASSANDRA-17778: - Committed, thanks! To https://github.com/apache/cassandra.git 590de42a06..43036ecadd cassandra-4.1 -> cassandra-4.1 3f2e8d1883..b70e14e2ac trunk -> trunk > WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu > -- > > Key: CASSANDRA-17778 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17778 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1.x, 4.x > > > There is no way to navigate to the new configuration page for CASSANDRA-15234 > ([Liberating cassandra.yaml Parameters' Names from Their > Units|https://cassandra.apache.org/doc/trunk/cassandra/new/configuration.html]) > because it is not referenced anywhere. > Unless someone has bookmarked the page, there is no way to find it on the > site. > Other doc changes expected: > * Add a small table with supported units per type as currently we list only > the duration's ones and min units for old parameters. We list the supported > units only in NEWS.txt. > * Add info about the RuntimeExceptions we introduced in CASSANDRA-17725 for > a few deprecated JMX getters. > * Add a note for Cassandra developers - "Please ensure that any JMX > setters/getters update the Config class properties and not some local copies. > Settings Virtual Table reports the configuration loaded at any time from the > Config class." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (590de42a06 -> 43036ecadd)
This is an automated email from the ASF dual-hosted git repository.
edimitrova pushed a change to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
from 590de42a06 Merge branch 'cassandra-4.0' into cassandra-4.1
add 43036ecadd Update docs and NEWS.txt; config docs are reachable now on
the website patch by Ekaterina Dimitrova; reviewed by Caleb Rackliffe for
CASSANDRA-17778
No new revisions were added by this update.
Summary of changes:
CHANGES.txt | 1 +
NEWS.txt | 9 ++---
.../pages/{new => configuration}/configuration.adoc | 12
doc/modules/cassandra/pages/new/index.adoc | 1 +
4 files changed, 20 insertions(+), 3 deletions(-)
rename doc/modules/cassandra/pages/{new => configuration}/configuration.adoc
(97%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository.
edimitrova pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit b70e14e2ac89f13570413cc214bcc6f25b902013
Merge: 3f2e8d1883 43036ecadd
Author: Ekaterina Dimitrova
AuthorDate: Wed Aug 17 18:30:59 2022 -0400
Merge branch 'cassandra-4.1' into trunk
CHANGES.txt | 1 +
NEWS.txt | 9 ++---
.../pages/{new => configuration}/configuration.adoc | 12
doc/modules/cassandra/pages/new/index.adoc | 1 +
4 files changed, 20 insertions(+), 3 deletions(-)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (3f2e8d1883 -> b70e14e2ac)
This is an automated email from the ASF dual-hosted git repository.
edimitrova pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
from 3f2e8d1883 NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive
add 43036ecadd Update docs and NEWS.txt; config docs are reachable now on
the website patch by Ekaterina Dimitrova; reviewed by Caleb Rackliffe for
CASSANDRA-17778
new b70e14e2ac Merge branch 'cassandra-4.1' into trunk
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
CHANGES.txt | 1 +
NEWS.txt | 9 ++---
.../pages/{new => configuration}/configuration.adoc | 12
doc/modules/cassandra/pages/new/index.adoc | 1 +
4 files changed, 20 insertions(+), 3 deletions(-)
rename doc/modules/cassandra/pages/{new => configuration}/configuration.adoc
(97%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17778) WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu
[ https://issues.apache.org/jira/browse/CASSANDRA-17778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581049#comment-17581049 ] Ekaterina Dimitrova commented on CASSANDRA-17778: - Things look as expected to me, starting commit soon > WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu > -- > > Key: CASSANDRA-17778 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17778 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1.x, 4.x > > > There is no way to navigate to the new configuration page for CASSANDRA-15234 > ([Liberating cassandra.yaml Parameters' Names from Their > Units|https://cassandra.apache.org/doc/trunk/cassandra/new/configuration.html]) > because it is not referenced anywhere. > Unless someone has bookmarked the page, there is no way to find it on the > site. > Other doc changes expected: > * Add a small table with supported units per type as currently we list only > the duration's ones and min units for old parameters. We list the supported > units only in NEWS.txt. > * Add info about the RuntimeExceptions we introduced in CASSANDRA-17725 for > a few deprecated JMX getters. > * Add a note for Cassandra developers - "Please ensure that any JMX > setters/getters update the Config class properties and not some local copies. > Settings Virtual Table reports the configuration loaded at any time from the > Config class." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17829) WEBSITE - August 2022 Blogs update
[ https://issues.apache.org/jira/browse/CASSANDRA-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17829: - Test and Documentation Plan: * "Inside Cassandra: An Interview with Project Contributor, Lorina Poland" image replacement * "Cassandra Day in Berlin Announced" text edits * "Talks & Sponsors Announced for Cassandra World Party 2022" sponsor and text edits * "Watch the Cassandra World Party" text edits was:* "Inside Cassandra: An Interview with Project Contributor, Lorina Poland" image replacement > WEBSITE - August 2022 Blogs update > -- > > Key: CASSANDRA-17829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17829 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's blog posts to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17829) WEBSITE - August 2022 Blogs update
[ https://issues.apache.org/jira/browse/CASSANDRA-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17829: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/165 > WEBSITE - August 2022 Blogs update > -- > > Key: CASSANDRA-17829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17829 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's blog posts to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17829) WEBSITE - August 2022 Blogs update
[ https://issues.apache.org/jira/browse/CASSANDRA-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17829: - Status: Open (was: Triage Needed) > WEBSITE - August 2022 Blogs update > -- > > Key: CASSANDRA-17829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17829 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's blog posts to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17829) WEBSITE - August 2022 Blogs update
[ https://issues.apache.org/jira/browse/CASSANDRA-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17829: --- Labels: pull-request-available (was: ) > WEBSITE - August 2022 Blogs update > -- > > Key: CASSANDRA-17829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17829 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's blog posts to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
[
https://issues.apache.org/jira/browse/CASSANDRA-17819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581033#comment-17581033
]
Ekaterina Dimitrova edited comment on CASSANDRA-17819 at 8/17/22 10:01 PM:
---
I think you meant to ping [~jlewandowski] actually :)
Ok, I hoped for it to be just our Jenkins turtle but it seems with 10 seconds
and [two
minutes|https://github.com/ekaterinadimitrova2/cassandra/commit/f0e1c893918a8af9de4a51b44c61f80994f98f39]
the test fails with about the same frequency respectively
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1872/workflows/c96fb0fa-434b-4d4e-8023-7a80e9accfed/jobs/14677]
and
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1873/workflows/f632eb7a-48a2-46e9-aa7b-d3d77679e2ca/jobs/14682/tests#failed-test-0]
(4.1 branch) and also in two ways - the one in the ticket description and with
a NullPointerException:
{code:java}
java.lang.NullPointerException at
org.apache.cassandra.schema.SchemaKeyspace.applyChanges(SchemaKeyspace.java:1256)
at
org.apache.cassandra.schema.DefaultSchemaUpdateHandler.applyMutations(DefaultSchemaUpdateHandler.java:186)
at
org.apache.cassandra.schema.DefaultSchemaUpdateHandler.reset(DefaultSchemaUpdateHandler.java:262)
at org.apache.cassandra.schema.Schema.resetLocalSchema(Schema.java:624) at
org.apache.cassandra.distributed.test.SchemaTest.lambda$schemaReset$81c80a4a$1(SchemaTest.java:108)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81) at
org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829){code}
I need to dig into the logs reminding myself about what s going on...it's been
a month since I looked into that ticket.
was (Author: e.dimitrova):
I think you meant to ping [~jlewandowski] actually :)
Ok, I hoped for it to be just our Jenkins turtle but it seems with 10 seconds
and [two
minutes|https://github.com/ekaterinadimitrova2/cassandra/commit/f0e1c893918a8af9de4a51b44c61f80994f98f39]
the test fails with about the same frequency respectively
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1872/workflows/c96fb0fa-434b-4d4e-8023-7a80e9accfed/jobs/14677]
and
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1873/workflows/f632eb7a-48a2-46e9-aa7b-d3d77679e2ca/jobs/14682/tests#failed-test-0]
and also in two ways - the one in the ticket description and with a
NullPointerException:
{code:java}
java.lang.NullPointerException at
org.apache.cassandra.schema.SchemaKeyspace.applyChanges(SchemaKeyspace.java:1256)
at
org.apache.cassandra.schema.DefaultSchemaUpdateHandler.applyMutations(DefaultSchemaUpdateHandler.java:186)
at
org.apache.cassandra.schema.DefaultSchemaUpdateHandler.reset(DefaultSchemaUpdateHandler.java:262)
at org.apache.cassandra.schema.Schema.resetLocalSchema(Schema.java:624) at
org.apache.cassandra.distributed.test.SchemaTest.lambda$schemaReset$81c80a4a$1(SchemaTest.java:108)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81) at
org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829){code}
I need to dig into the logs reminding myself about what s going on...it's been
a month since I looked into that ticket.
> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> The test
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}},
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
> * 4.1:
>
[jira] [Comment Edited] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
[
https://issues.apache.org/jira/browse/CASSANDRA-17819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581033#comment-17581033
]
Ekaterina Dimitrova edited comment on CASSANDRA-17819 at 8/17/22 10:00 PM:
---
I think you meant to ping [~jlewandowski] actually :)
Ok, I hoped for it to be just our Jenkins turtle but it seems with 10 seconds
and [two
minutes|https://github.com/ekaterinadimitrova2/cassandra/commit/f0e1c893918a8af9de4a51b44c61f80994f98f39]
the test fails with about the same frequency respectively
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1872/workflows/c96fb0fa-434b-4d4e-8023-7a80e9accfed/jobs/14677]
and
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1873/workflows/f632eb7a-48a2-46e9-aa7b-d3d77679e2ca/jobs/14682/tests#failed-test-0]
and also in two ways - the one in the ticket description and with a
NullPointerException:
{code:java}
java.lang.NullPointerException at
org.apache.cassandra.schema.SchemaKeyspace.applyChanges(SchemaKeyspace.java:1256)
at
org.apache.cassandra.schema.DefaultSchemaUpdateHandler.applyMutations(DefaultSchemaUpdateHandler.java:186)
at
org.apache.cassandra.schema.DefaultSchemaUpdateHandler.reset(DefaultSchemaUpdateHandler.java:262)
at org.apache.cassandra.schema.Schema.resetLocalSchema(Schema.java:624) at
org.apache.cassandra.distributed.test.SchemaTest.lambda$schemaReset$81c80a4a$1(SchemaTest.java:108)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81) at
org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829){code}
I need to dig into the logs reminding myself about what s going on...it's been
a month since I looked into that ticket.
was (Author: e.dimitrova):
I think you meant to ping [~jlewandowski] actually :)
Ok, I hoped for it to be just our Jenkins turtle but it seems with with 10
seconds and two minutes the test fails with about the same frequency and also,
with the two minutes we notice sometimes it starts failing with a
NullPointerException. I need to dig into the logs remind myself about what s
going on...it's been a month since I looked into that ticket.
> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> The test
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}},
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
> * 4.1:
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> * trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in
> org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
> at
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-15 15:02:14,783
[jira] [Commented] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
[
https://issues.apache.org/jira/browse/CASSANDRA-17819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581033#comment-17581033
]
Ekaterina Dimitrova commented on CASSANDRA-17819:
-
I think you meant to ping [~jlewandowski] actually :)
Ok, I hoped for it to be just our Jenkins turtle but it seems with with 10
seconds and two minutes the test fails with about the same frequency and also,
with the two minutes we notice sometimes it starts failing with a
NullPointerException. I need to dig into the logs remind myself about what s
going on...it's been a month since I looked into that ticket.
> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> The test
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}},
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
> * 4.1:
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> * trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in
> org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
> at
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-15 15:02:14,783 Reflections.java:219 -
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO [main] 2022-08-15 15:02:16,407 Reflections.java:219 -
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> INFO [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents
[
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17581029#comment-17581029
]
Paulo Motta commented on CASSANDRA-17804:
-
Thanks for the feedback. Addressed nit comments and resubmitted CI for
4.1/trunk:
|[trunk|https://github.com/apache/cassandra/pull/1596]|[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1651/]|
|[4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-17804-4.1]|[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1884/]|
> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>
> My guess is that in some resource constrained environment, even the first
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In
> other words, we skip to the state of the world the last assertion in the test
> is checking.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17822) NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive
[
https://issues.apache.org/jira/browse/CASSANDRA-17822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17822:
--
Fix Version/s: 4.2
(was: 4.x)
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/707ebc702eadce188d2d14a5cdbb3d2b1f38a868
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive
> -
>
> Key: CASSANDRA-17822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17822
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.2
>
>
> {code}
> java.lang.NullPointerException
> at org.apache.cassandra.cql3.Attributes.getTimeToLive(Attributes.java:129)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.getTimeToLive(ModificationStatement.java:237)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.makeUpdateParameters(ModificationStatement.java:833)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.makeUpdateParameters(ModificationStatement.java:799)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:736)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:689)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:470)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:454)
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:255)
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:716)
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:678)
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:160)
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
>at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:142)
>at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:158)
>at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:181)
>at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$1(Dispatcher.java:108)
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive
This is an automated email from the ASF dual-hosted git repository.
dcapwell 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 3f2e8d1883 NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive
3f2e8d1883 is described below
commit 3f2e8d1883c586bdb9cd7a23076ceaaeefa4bd8c
Author: David Capwell
AuthorDate: Wed Aug 17 09:47:17 2022 -0700
NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive
patch by David Capwell; reviewed by Caleb Rackliffe for CASSANDRA-17822
---
CHANGES.txt | 1 +
src/java/org/apache/cassandra/cql3/Attributes.java| 5 +
.../cassandra/cql3/validation/operations/InsertTest.java | 11 +++
3 files changed, 17 insertions(+)
diff --git a/CHANGES.txt b/CHANGES.txt
index b8584c3506..9d7d61194b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive (CASSANDRA-17822)
* Add guardrail for column size (CASSANDRA-17151)
* When doing a host replacement, we need to check that the node is a live
node before failing with "Cannot replace a live node..." (CASSANDRA-17805)
* Add support to generate a One-Shot heap dump on unhandled exceptions
(CASSANDRA-17795)
diff --git a/src/java/org/apache/cassandra/cql3/Attributes.java
b/src/java/org/apache/cassandra/cql3/Attributes.java
index e841828d79..559882f725 100644
--- a/src/java/org/apache/cassandra/cql3/Attributes.java
+++ b/src/java/org/apache/cassandra/cql3/Attributes.java
@@ -117,6 +117,11 @@ public class Attributes
if (tval == ByteBufferUtil.UNSET_BYTE_BUFFER)
return metadata.params.defaultTimeToLive;
+// byte[0] and null are the same for Int32Type. UNSET_BYTE_BUFFER is
also byte[0] but we rely on pointer
+// identity, so need to check this after checking that
+if (ByteBufferUtil.EMPTY_BYTE_BUFFER.equals(tval))
+return 0;
+
try
{
Int32Type.instance.validate(tval);
diff --git
a/test/unit/org/apache/cassandra/cql3/validation/operations/InsertTest.java
b/test/unit/org/apache/cassandra/cql3/validation/operations/InsertTest.java
index 0f01f3e3d4..0093764b0c 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/InsertTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/InsertTest.java
@@ -18,6 +18,8 @@
package org.apache.cassandra.cql3.validation.operations;
+import java.nio.ByteBuffer;
+
import org.junit.Assert;
import org.junit.Test;
@@ -29,6 +31,15 @@ import
org.apache.cassandra.exceptions.InvalidRequestException;
public class InsertTest extends CQLTester
{
+@Test
+public void testEmptyTTL() throws Throwable
+{
+createTable("CREATE TABLE %s (k int PRIMARY KEY, v int)");
+execute("INSERT INTO %s (k, v) VALUES (0, 0) USING TTL ?", (Object)
null);
+execute("INSERT INTO %s (k, v) VALUES (1, 1) USING TTL ?",
ByteBuffer.wrap(new byte[0]));
+assertRows(execute("SELECT k, v, ttl(v) FROM %s"), row(1, 1, null),
row(0, 0, null));
+}
+
@Test
public void testInsertWithUnset() throws Throwable
{
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17828) Read/Write/Truncate throw RequestFailure in a race condition with callback timeouts, should return Timeout instead
[ https://issues.apache.org/jira/browse/CASSANDRA-17828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17828: -- Summary: Read/Write/Truncate throw RequestFailure in a race condition with callback timeouts, should return Timeout instead (was: RequestFailure thrown when RequestTimeout should have thrown) > Read/Write/Truncate throw RequestFailure in a race condition with callback > timeouts, should return Timeout instead > -- > > Key: CASSANDRA-17828 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17828 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > There is an edge case with write timeout where the condition gets signaled on > the timeouts and this happens before await times out, this triggers us to > send a Failure rather than a Timeout -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17830) Read Unavailables due to GossipStage backlog with high number of pending tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-17830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17830: -- Test and Documentation Plan: No new testing required; perform existing tests. Status: Patch Available (was: Open) > Read Unavailables due to GossipStage backlog with high number of pending tasks > -- > > Key: CASSANDRA-17830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17830 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In CASSANDRA-16759, like we changed from iterating over liveMembers + > unreachableMembers to all keys in endpointStateMap > [here|https://github.com/apache/cassandra/commit/2fba5c80ce7bf71d04c62043ffa1088b9e832d83#diff-99267a2170b04fd7dd24d6c6bf2ba1fc26d6dc896cd74f8c5bd56c476e2540e4R208]. > We can have an endpoint in quarantine (in justRemovedEndpoints) which has no > release version information. In this case we don't memoize the value and > instead recalculate the min version for every endpoint for every incoming > gossip message... which can be bad. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17830) Read Unavailables due to GossipStage backlog with high number of pending tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-17830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17830: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Read Unavailables due to GossipStage backlog with high number of pending tasks > -- > > Key: CASSANDRA-17830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17830 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In CASSANDRA-16759, like we changed from iterating over liveMembers + > unreachableMembers to all keys in endpointStateMap > [here|https://github.com/apache/cassandra/commit/2fba5c80ce7bf71d04c62043ffa1088b9e832d83#diff-99267a2170b04fd7dd24d6c6bf2ba1fc26d6dc896cd74f8c5bd56c476e2540e4R208]. > We can have an endpoint in quarantine (in justRemovedEndpoints) which has no > release version information. In this case we don't memoize the value and > instead recalculate the min version for every endpoint for every incoming > gossip message... which can be bad. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17830) Read Unavailables due to GossipStage backlog with high number of pending tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-17830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580988#comment-17580988 ] Josh McKenzie commented on CASSANDRA-17830: --- ||Item|Link|| |PR|[link|https://github.com/apache/cassandra/pull/1797]| |JDK11 CI|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/273/workflows/45711470-a16d-46a0-a8ea-318940b5f79d]| > Read Unavailables due to GossipStage backlog with high number of pending tasks > -- > > Key: CASSANDRA-17830 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17830 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Gossip >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In CASSANDRA-16759, like we changed from iterating over liveMembers + > unreachableMembers to all keys in endpointStateMap > [here|https://github.com/apache/cassandra/commit/2fba5c80ce7bf71d04c62043ffa1088b9e832d83#diff-99267a2170b04fd7dd24d6c6bf2ba1fc26d6dc896cd74f8c5bd56c476e2540e4R208]. > We can have an endpoint in quarantine (in justRemovedEndpoints) which has no > release version information. In this case we don't memoize the value and > instead recalculate the min version for every endpoint for every incoming > gossip message... which can be bad. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580985#comment-17580985 ] Brandon Williams commented on CASSANDRA-13010: -- This looks good. bq. it is not possible to mix "verbose" with "vtable" output in nodetoo I think it makes sense to keep building on vtables, and thus the vtable output in compactionstats when someone wants more information than what's in the backward-compatible view. So I think keeping this behind the vtable flag is fine, and helps cuts down on the number of flags. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: Jon Haddad >Assignee: Stefan Miklosovic >Priority: Normal > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > Attachments: cleanup.png, multiple operations.png > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17830) Read Unavailables due to GossipStage backlog with high number of pending tasks
Josh McKenzie created CASSANDRA-17830: - Summary: Read Unavailables due to GossipStage backlog with high number of pending tasks Key: CASSANDRA-17830 URL: https://issues.apache.org/jira/browse/CASSANDRA-17830 Project: Cassandra Issue Type: Improvement Components: Cluster/Gossip Reporter: Josh McKenzie Assignee: Josh McKenzie In CASSANDRA-16759, like we changed from iterating over liveMembers + unreachableMembers to all keys in endpointStateMap [here|https://github.com/apache/cassandra/commit/2fba5c80ce7bf71d04c62043ffa1088b9e832d83#diff-99267a2170b04fd7dd24d6c6bf2ba1fc26d6dc896cd74f8c5bd56c476e2540e4R208]. We can have an endpoint in quarantine (in justRemovedEndpoints) which has no release version information. In this case we don't memoize the value and instead recalculate the min version for every endpoint for every incoming gossip message... which can be bad. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17829) WEBSITE - August 2022 Blogs update
[ https://issues.apache.org/jira/browse/CASSANDRA-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17829: - Change Category: Semantic Complexity: Normal Component/s: Documentation/Blog Impacts: Docs (was: None) Test and Documentation Plan: * "Inside Cassandra: An Interview with Project Contributor, Lorina Poland" image replacement > WEBSITE - August 2022 Blogs update > -- > > Key: CASSANDRA-17829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17829 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's blog posts to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17829) WEBSITE - August 2022 Blogs update
Diogenese Topper created CASSANDRA-17829: Summary: WEBSITE - August 2022 Blogs update Key: CASSANDRA-17829 URL: https://issues.apache.org/jira/browse/CASSANDRA-17829 Project: Cassandra Issue Type: Task Reporter: Diogenese Topper This ticket is to capture the work associated with updates to the Apache Cassandra Website's blog posts to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17622) WEBSITE - August 2022 Homepage update
[ https://issues.apache.org/jira/browse/CASSANDRA-17622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17622: - Epic Link: (was: CASSANDRA-16761) > WEBSITE - August 2022 Homepage update > - > > Key: CASSANDRA-17622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17622 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updating the Apache > Cassandra Resources page with new resources and replacing outdated resources > with more recent and relevant ones. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17622) WEBSITE - August 2022 Homepage update
[ https://issues.apache.org/jira/browse/CASSANDRA-17622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17622: - Status: Open (was: Triage Needed) > WEBSITE - August 2022 Homepage update > - > > Key: CASSANDRA-17622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17622 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updating the Apache > Cassandra Resources page with new resources and replacing outdated resources > with more recent and relevant ones. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17622) WEBSITE - August 2022 Homepage update
[ https://issues.apache.org/jira/browse/CASSANDRA-17622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17622: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/164 > WEBSITE - August 2022 Homepage update > - > > Key: CASSANDRA-17622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17622 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updating the Apache > Cassandra Resources page with new resources and replacing outdated resources > with more recent and relevant ones. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17622) WEBSITE - August 2022 Homepage update
[ https://issues.apache.org/jira/browse/CASSANDRA-17622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17622: --- Labels: pull-request-available (was: ) > WEBSITE - August 2022 Homepage update > - > > Key: CASSANDRA-17622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17622 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updating the Apache > Cassandra Resources page with new resources and replacing outdated resources > with more recent and relevant ones. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17622) WEBSITE - August 2022 Homepage update
[ https://issues.apache.org/jira/browse/CASSANDRA-17622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17622: - Summary: WEBSITE - August 2022 Homepage update (was: WEBSITE - Homepage update) > WEBSITE - August 2022 Homepage update > - > > Key: CASSANDRA-17622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17622 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updating the Apache > Cassandra Resources page with new resources and replacing outdated resources > with more recent and relevant ones. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17828) RequestFailure thrown when RequestTimeout should have thrown
[ https://issues.apache.org/jira/browse/CASSANDRA-17828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17828: -- Test and Documentation Plan: new tests Status: Patch Available (was: In Progress) > RequestFailure thrown when RequestTimeout should have thrown > > > Key: CASSANDRA-17828 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17828 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > There is an edge case with write timeout where the condition gets signaled on > the timeouts and this happens before await times out, this triggers us to > send a Failure rather than a Timeout -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[
https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580964#comment-17580964
]
Stefan Miklosovic commented on CASSANDRA-13010:
---
for vtable in nodetool it looks like this:
{code}
pending tasks: 2
- cql_test_keyspace.table_00: 2
keyspace tabletask id completion
ratio kind progress sstables total unit target directory
cql_test_keyspace table_00 6f155250-1e62-11ed-81ed-f13ee02c0a6e 0.10%
Cleanup123 1123456 bytes
cql_test_keyspace table_00 6d465eb0-1e62-11ed-81ed-f13ee02c0a6e 0.10%
Compaction 123 10 123456 bytes
/some/dir/cql_test_keyspace/table_00-6b470c40-1e62-11ed-81ed-f13ee02c0a6e
Active compaction remaining time :n/a
{code}
I fixed one issue - it is not possible to mix "verbose" with "vtable" output in
nodetool. They are mutually exclusive. One can do either verbose or vtable.
CQL vtable output contains that dir as well (new column).
It is same PR / branch. I am running the build as we speak.
> nodetool compactionstats should say which disk a compaction is writing to
> -
>
> Key: CASSANDRA-13010
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13010
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Compaction, Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: cleanup.png, multiple operations.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17821) Add ability to log load profiles at fixed intervals
[
https://issues.apache.org/jira/browse/CASSANDRA-17821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580950#comment-17580950
]
Josh McKenzie commented on CASSANDRA-17821:
---
Had a masking variable that snuck through on {{{}MaxSampler{}}}; re-running
JDK11 w[/the fixed
commit:|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/271/workflows/6ed3a63e-5b50-421f-94cb-aaebdae29579]
> Add ability to log load profiles at fixed intervals
> ---
>
> Key: CASSANDRA-17821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17821
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> A jmx operation to run profileload and log results every X would be helpful
> so operators can hot prop it on troubled nodes/clusters to identify
> troublesome queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17828) RequestFailure thrown when RequestTimeout should have thrown
[ https://issues.apache.org/jira/browse/CASSANDRA-17828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17828: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Transient Incorrect Response(12987) Complexity: Low Hanging Fruit Discovered By: Unit Test Fix Version/s: 4.x Severity: Normal Assignee: David Capwell Status: Open (was: Triage Needed) > RequestFailure thrown when RequestTimeout should have thrown > > > Key: CASSANDRA-17828 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17828 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Coordination >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > > There is an edge case with write timeout where the condition gets signaled on > the timeouts and this happens before await times out, this triggers us to > send a Failure rather than a Timeout -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17828) RequestFailure thrown when RequestTimeout should have thrown
David Capwell created CASSANDRA-17828: - Summary: RequestFailure thrown when RequestTimeout should have thrown Key: CASSANDRA-17828 URL: https://issues.apache.org/jira/browse/CASSANDRA-17828 Project: Cassandra Issue Type: Bug Components: Consistency/Coordination Reporter: David Capwell There is an edge case with write timeout where the condition gets signaled on the timeouts and this happens before await times out, this triggers us to send a Failure rather than a Timeout -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17461) Test Failure: org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation
[
https://issues.apache.org/jira/browse/CASSANDRA-17461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580921#comment-17580921
]
Benedict Elliott Smith edited comment on CASSANDRA-17461 at 8/17/22 6:05 PM:
-
Ok, I was on the right track but I had intercepted the problem at the wrong
point. I have pushed a new commit to the same branch, and the latest test run
is only failing due to the hints service shutdown problem.
(Which isn't really a problem, and might be something we can just choose to
ignore, though probably shutdown should avoid a sequence of events that permits
a hint to be submitted to a shutdown hint service, I think that's out of the
scope of this ticket)
was (Author: benedict):
Ok, I was on the right track but I had intercepted the problem at the wrong
point. I have pushed a new commit to the same branch, and the latest test run
is only failing due to the hints service shutdown problem.
> Test Failure:
> org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation
> -
>
> Key: CASSANDRA-17461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17461
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Intermittent failures on {{org.apache.cassandra.distributed.test.CASTest}}
> for trunk:
> *
> [testConflictingWritesWithStaleRingInformation|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.distributed.test/CASTest/testConflictingWritesWithStaleRingInformation_3/]
> *
> [testSuccessfulWriteBeforeRangeMovement|https://ci-cassandra.apache.org/job/Cassandra-trunk/1025/testReport/org.apache.cassandra.distributed.test/CASTest/testSuccessfulWriteBeforeRangeMovement/]
> *
> [testSuccessfulWriteDuringRangeMovementFollowedByConflicting|https://ci-cassandra.apache.org/job/Cassandra-trunk/1020/testReport/org.apache.cassandra.distributed.test/CASTest/testSuccessfulWriteDuringRangeMovementFollowedByConflicting/]
> *
> [testSucccessfulWriteDuringRangeMovementFollowedByRead|https://ci-cassandra.apache.org/job/Cassandra-trunk/1020/testReport/org.apache.cassandra.distributed.test/CASTest/testSucccessfulWriteDuringRangeMovementFollowedByRead/]
> All four seem to have the same aspect:
> {code}
> Failed 2 times in the last 5 runs. Flakiness: 50%, Stability: 60%
> Error Message
> CAS operation timed out: received 1 of 2 required responses after 0
> contention retries
> Stacktrace
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 1 of 2 required responses after 0 contention retries
> at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.begin(Paxos.java:1048)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:659)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618)
> at org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Standard Output
> DEBUG [main] 2022-03-19 16:20:42,868 Reflections.java:198 - going to scan
> these urls:
> [jar:file:/home/cassandra/cassandra/build/apache-cassandra-4.1-SNAPSHOT.jar!/,
>
> jar:file:/home/cassandra/cassandra/build/test/lib/jars/simulator-bootstrap.jar!/,
>
> jar:file:/home/cassandra/cassandra/build/test/lib/jars/dtest-api-0.0.12.jar!/,
> file:/home/cassandra/cassandra/build/classes/fqltool/,
> file:/home/cassandra/cassandra/build/test/classes/,
> file:/home/cassandra/cassandra/build/classes/main/,
[jira] [Commented] (CASSANDRA-17461) Test Failure: org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation
[
https://issues.apache.org/jira/browse/CASSANDRA-17461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580921#comment-17580921
]
Benedict Elliott Smith commented on CASSANDRA-17461:
Ok, I was on the right track but I had intercepted the problem at the wrong
point. I have pushed a new commit to the same branch, and the latest test run
is only failing due to the hints service shutdown problem.
> Test Failure:
> org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation
> -
>
> Key: CASSANDRA-17461
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17461
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Intermittent failures on {{org.apache.cassandra.distributed.test.CASTest}}
> for trunk:
> *
> [testConflictingWritesWithStaleRingInformation|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.distributed.test/CASTest/testConflictingWritesWithStaleRingInformation_3/]
> *
> [testSuccessfulWriteBeforeRangeMovement|https://ci-cassandra.apache.org/job/Cassandra-trunk/1025/testReport/org.apache.cassandra.distributed.test/CASTest/testSuccessfulWriteBeforeRangeMovement/]
> *
> [testSuccessfulWriteDuringRangeMovementFollowedByConflicting|https://ci-cassandra.apache.org/job/Cassandra-trunk/1020/testReport/org.apache.cassandra.distributed.test/CASTest/testSuccessfulWriteDuringRangeMovementFollowedByConflicting/]
> *
> [testSucccessfulWriteDuringRangeMovementFollowedByRead|https://ci-cassandra.apache.org/job/Cassandra-trunk/1020/testReport/org.apache.cassandra.distributed.test/CASTest/testSucccessfulWriteDuringRangeMovementFollowedByRead/]
> All four seem to have the same aspect:
> {code}
> Failed 2 times in the last 5 runs. Flakiness: 50%, Stability: 60%
> Error Message
> CAS operation timed out: received 1 of 2 required responses after 0
> contention retries
> Stacktrace
> org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed
> out: received 1 of 2 required responses after 0 contention retries
> at
> org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547)
> at org.apache.cassandra.service.paxos.Paxos.begin(Paxos.java:1048)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:659)
> at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618)
> at org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Standard Output
> DEBUG [main] 2022-03-19 16:20:42,868 Reflections.java:198 - going to scan
> these urls:
> [jar:file:/home/cassandra/cassandra/build/apache-cassandra-4.1-SNAPSHOT.jar!/,
>
> jar:file:/home/cassandra/cassandra/build/test/lib/jars/simulator-bootstrap.jar!/,
>
> jar:file:/home/cassandra/cassandra/build/test/lib/jars/dtest-api-0.0.12.jar!/,
> file:/home/cassandra/cassandra/build/classes/fqltool/,
> file:/home/cassandra/cassandra/build/test/classes/,
> file:/home/cassandra/cassandra/build/classes/main/, file:/home/cass
> ...[truncated 4929659 chars]...
> gService.java:519 - Waiting for messaging service to quiesce
> INFO [node1_isolatedExecutor:10] 2022-03-19 16:21:55,223
> SubstituteLogger.java:169 - INFO [node1_isolatedExecutor:10] node1
> 2022-03-19 16:21:55,221 MessagingService.java:519 - Waiting for messaging
> service to quiesce
> INFO [node2_isolatedExecutor:8] 2022-03-19 16:21:55,223
> SubstituteLogger.java:169 - INFO [node2_isolatedExecutor:8] node2 2022-03-19
> 16:21:55,222 MessagingService.java:519 - Waiting for messaging
[jira] [Assigned] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
[
https://issues.apache.org/jira/browse/CASSANDRA-17819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-17819:
---
Assignee: Ekaterina Dimitrova
> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> The test
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}},
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
> * 4.1:
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> * trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in
> org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
> at
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-15 15:02:14,783 Reflections.java:219 -
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO [main] 2022-08-15 15:02:16,407 Reflections.java:219 -
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> INFO [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17819) Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
[
https://issues.apache.org/jira/browse/CASSANDRA-17819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17819:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> Test failure: org.apache.cassandra.distributed.test.SchemaTest.schemaReset
> --
>
> Key: CASSANDRA-17819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17819
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> The test
> {{{}org.apache.cassandra.distributed.test.SchemaTest.schemaReset{}}},
> recently introduced by CASSANDRA-17658, is flaky on 4.1 and trunk:
> * 4.1:
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/134/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> * trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1265/testReport/org.apache.cassandra.distributed.test/SchemaTest/schemaReset_2/]
> {code:java}
> Error Message
> Condition with lambda expression in
> org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> Stacktrace
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.cassandra.distributed.test.SchemaTest that uses
> org.apache.cassandra.distributed.Cluster was not fulfilled within 1 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
> at
> org.apache.cassandra.distributed.test.SchemaTest.schemaReset(SchemaTest.java:115)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-15 15:02:14,783 Reflections.java:219 -
> Reflections took 1873 ms to scan 8 urls, producing 1754 keys and 6912 values
> INFO [main] 2022-08-15 15:02:16,407 Reflections.java:219 -
> Reflections took 1561 ms to scan 8 urls, producing 1754 keys and 6912 values
> Node id topology:
> node 1: dc = datacenter0, rack = rack0
> node 2: dc = datacenter0, rack = rack0
> Configured node count: 2, nodeIdTopology size: 2
> DEBUG [main] node1 2022-08-15 15:02:17,554 InternalLoggerFactory.ja
> ...[truncated 1761288 chars]...
> cutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> INFO [node2_isolatedExecutor:3] node2 2022-08-15 15:03:52,096
> MessagingService.java:519 - Waiting for messaging service to quiesce
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17827) WEBSITE - August 2022 Case Studies update
[ https://issues.apache.org/jira/browse/CASSANDRA-17827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17827: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/163 > WEBSITE - August 2022 Case Studies update > - > > Key: CASSANDRA-17827 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17827 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Case Studies page to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17827) WEBSITE - August 2022 Case Studies update
[ https://issues.apache.org/jira/browse/CASSANDRA-17827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17827: --- Labels: pull-request-available (was: ) > WEBSITE - August 2022 Case Studies update > - > > Key: CASSANDRA-17827 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17827 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Case Studies page to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17826) WEBSITE - August 2022 Resources update
[ https://issues.apache.org/jira/browse/CASSANDRA-17826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17826: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/162 > WEBSITE - August 2022 Resources update > -- > > Key: CASSANDRA-17826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17826 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Resources page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17825) WEBSITE - August 2022 Ecosystem update
[ https://issues.apache.org/jira/browse/CASSANDRA-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17825: - Summary: WEBSITE - August 2022 Ecosystem update (was: WEBSITE - Ecosystem update) > WEBSITE - August 2022 Ecosystem update > -- > > Key: CASSANDRA-17825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17825 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Ecosystem page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17826) WEBSITE - August 2022 Resources update
[ https://issues.apache.org/jira/browse/CASSANDRA-17826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17826: - Summary: WEBSITE - August 2022 Resources update (was: WEBSITE - Resources update) > WEBSITE - August 2022 Resources update > -- > > Key: CASSANDRA-17826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17826 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Resources page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17827) WEBSITE - August 2022 Case Studies update
[ https://issues.apache.org/jira/browse/CASSANDRA-17827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17827: - Status: Open (was: Triage Needed) > WEBSITE - August 2022 Case Studies update > - > > Key: CASSANDRA-17827 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17827 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Case Studies page to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17826) WEBSITE - August 2022 Resources update
[ https://issues.apache.org/jira/browse/CASSANDRA-17826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17826: - Status: Open (was: Triage Needed) > WEBSITE - August 2022 Resources update > -- > > Key: CASSANDRA-17826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17826 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Resources page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17827) WEBSITE - August 2022 Case Studies update
[ https://issues.apache.org/jira/browse/CASSANDRA-17827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17827: - Change Category: Semantic Complexity: Normal Impacts: Docs (was: None) Test and Documentation Plan: * Add alt text for company logos * Add quotation marks to the Backblaze case study card * Add logo on the Backblaze case study page * Formatting fix Instana testimonial quotes > WEBSITE - August 2022 Case Studies update > - > > Key: CASSANDRA-17827 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17827 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Case Studies page to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17827) WEBSITE - August 2022 Case Studies update
Diogenese Topper created CASSANDRA-17827: Summary: WEBSITE - August 2022 Case Studies update Key: CASSANDRA-17827 URL: https://issues.apache.org/jira/browse/CASSANDRA-17827 Project: Cassandra Issue Type: Task Components: Documentation/Website Reporter: Diogenese Topper This ticket is to capture the work associated with updates to the Apache Cassandra Website's Case Studies page to address typos and formatting issues. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17826) WEBSITE - Resources update
[ https://issues.apache.org/jira/browse/CASSANDRA-17826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17826: --- Labels: pull-request-available (was: ) > WEBSITE - Resources update > -- > > Key: CASSANDRA-17826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17826 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Resources page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17826) WEBSITE - Resources update
[ https://issues.apache.org/jira/browse/CASSANDRA-17826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17826: - Change Category: Semantic Complexity: Normal Component/s: Documentation/Website Impacts: Docs (was: None) Test and Documentation Plan: * Added resources ** Top 50 interview questions and answers of Apache Cassandra ** Apache Cassandra Lunch #84: Data & Analytics Platform: Cassandra, Spark, Kafka ** Apache Cassandra Architecture ** Can Spark Applications Coexist with NoSQL Databases? ** The Search for a Cloud-Native Database > WEBSITE - Resources update > -- > > Key: CASSANDRA-17826 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17826 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Resources page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17825) WEBSITE - Ecosystem update
[ https://issues.apache.org/jira/browse/CASSANDRA-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17825: - Component/s: Documentation/Website (was: Documentation/Blog) > WEBSITE - Ecosystem update > -- > > Key: CASSANDRA-17825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17825 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Ecosystem page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17826) WEBSITE - Resources update
Diogenese Topper created CASSANDRA-17826: Summary: WEBSITE - Resources update Key: CASSANDRA-17826 URL: https://issues.apache.org/jira/browse/CASSANDRA-17826 Project: Cassandra Issue Type: Task Reporter: Diogenese Topper This ticket is to capture the work associated with updates to the Apache Cassandra Website's Resources page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17825) WEBSITE - Ecosystem update
[ https://issues.apache.org/jira/browse/CASSANDRA-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17825: - Status: Open (was: Triage Needed) > WEBSITE - Ecosystem update > -- > > Key: CASSANDRA-17825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17825 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Ecosystem page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17825) WEBSITE - Ecosystem update
[ https://issues.apache.org/jira/browse/CASSANDRA-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17825: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/161 > WEBSITE - Ecosystem update > -- > > Key: CASSANDRA-17825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17825 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Ecosystem page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17825) WEBSITE - Ecosystem update
[ https://issues.apache.org/jira/browse/CASSANDRA-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17825: --- Labels: pull-request-available (was: ) > WEBSITE - Ecosystem update > -- > > Key: CASSANDRA-17825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17825 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Ecosystem page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17825) WEBSITE - Ecosystem update
[ https://issues.apache.org/jira/browse/CASSANDRA-17825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17825: - Change Category: Semantic Complexity: Normal Impacts: Docs (was: None) Test and Documentation Plan: * Added AxonOps to Cassandra Tools section > WEBSITE - Ecosystem update > -- > > Key: CASSANDRA-17825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17825 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updates to the Apache > Cassandra Website's Ecosystem page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17825) WEBSITE - Ecosystem update
Diogenese Topper created CASSANDRA-17825: Summary: WEBSITE - Ecosystem update Key: CASSANDRA-17825 URL: https://issues.apache.org/jira/browse/CASSANDRA-17825 Project: Cassandra Issue Type: Task Components: Documentation/Blog Reporter: Diogenese Topper This ticket is to capture the work associated with updates to the Apache Cassandra Website's Ecosystem page. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17658) Test Failures: org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
[
https://issues.apache.org/jira/browse/CASSANDRA-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580902#comment-17580902
]
Ekaterina Dimitrova edited comment on CASSANDRA-17658 at 8/17/22 5:29 PM:
--
The one ran in a loop indeed has the same name, but it is different class - the
one tested was a unit test, the flaky one is in-jvm. I will push some runs now
to see where it broke. Thanks for raising it!
was (Author: e.dimitrova):
The one ran in a loop indeed has the same name, but it is different class - the
one tested was a unit test, the flaky one is in-jvm.
> Test Failures:
> org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
>
>
> Key: CASSANDRA-17658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17658
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1-beta, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The test
> {{org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop}}
> seems to be flaky on CircleCI, although I haven't seen it failing on Jenkins.
> It was first detected during CASSANDRA-17509, on [this
> run|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/211/workflows/2cbb5465-a970-440b-a502-06e380ce6851/jobs/1977/tests]:
> {code}
> junit.framework.AssertionFailedError:
>
[jira] [Commented] (CASSANDRA-17658) Test Failures: org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
[
https://issues.apache.org/jira/browse/CASSANDRA-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580902#comment-17580902
]
Ekaterina Dimitrova commented on CASSANDRA-17658:
-
The one ran in a loop indeed has the same name, but it is different class - the
one tested was a unit test, the flaky one is in-jvm.
> Test Failures:
> org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
>
>
> Key: CASSANDRA-17658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17658
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1-beta, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The test
> {{org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop}}
> seems to be flaky on CircleCI, although I haven't seen it failing on Jenkins.
> It was first detected during CASSANDRA-17509, on [this
> run|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/211/workflows/2cbb5465-a970-440b-a502-06e380ce6851/jobs/1977/tests]:
> {code}
> junit.framework.AssertionFailedError:
>
[jira] [Updated] (CASSANDRA-17822) NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive
[
https://issues.apache.org/jira/browse/CASSANDRA-17822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17822:
--
Status: Ready to Commit (was: Review In Progress)
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17822-trunk-EE85F968-975F-488F-AB44-EBE482CA8D62]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17822-trunk-EE85F968-975F-488F-AB44-EBE482CA8D62]|[build|unknown]|
> NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive
> -
>
> Key: CASSANDRA-17822
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17822
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> {code}
> java.lang.NullPointerException
> at org.apache.cassandra.cql3.Attributes.getTimeToLive(Attributes.java:129)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.getTimeToLive(ModificationStatement.java:237)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.makeUpdateParameters(ModificationStatement.java:833)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.makeUpdateParameters(ModificationStatement.java:799)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:736)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:689)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:470)
>at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:454)
>at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:255)
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:716)
>at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:678)
>at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:160)
>at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
>at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:142)
>at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:158)
>at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:181)
>at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$1(Dispatcher.java:108)
>at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17668:
Status: Changes Suggested (was: Review In Progress)
> Fix leak of non-standard Java types in our Exceptions as clients using JMX
> are unable to handle them
>
>
> Key: CASSANDRA-17668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17668
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Observability/JMX
>Reporter: Ekaterina Dimitrova
>Assignee: Leonard Ma
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a continuation of CASSANDRA-17638 where we fixed leaks introduced
> during development of 4.1 to ensure no regressions.
> This ticket is to fix a few leakages which are there since previous major
> versions, not 4.1 regressions.
> {_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and
> _setRepairSessionSpaceInMegabytes(since 4.0)_
> in the DatabaseDescriptor.
> checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf
> (both since 4.0)_
> are used in both setters and on startup. They shouldn't throw
> ConfigurationException in the setters.
> There might be more but those are at least a few obvious I found in the
> DatabaseDescriptor.
> CC [~dcapwell]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580861#comment-17580861
]
Ekaterina Dimitrova commented on CASSANDRA-17668:
-
Hi [~lmtrombone],
Thank you for the patch and the extensive explanation!
Overall it looks good on a quick skim, I left some tiny suggestions. Just to
confirm, did you have the chance to verify whether there are other
setters/getters in the DatabaseDescriptor that can suffer from this problem,
out of the list/examples suggested on the ticket?
Also, I would like to suggest to add some basic unit tests to
DatabaseDescriptorTest class?
Also, I think we need patches for previous versions and we normally merge them
from lower affected version upwards to trunk - for more info
https://cassandra.apache.org/_/development/patches.html (Bug Fixes section).
There might be also the case we need different patches for the different
versions as things diverged between them. I can run a full CI for you when we
get things into shape.
One more thing is to check whether our docs need some relevant update, at
minimum we need to update the Deprecation section in NEWS.txt. Thank you for
your work!
{quote} I was tempted to just modify 'checkValidForByteConversion' so it throws
'IllegalArgumentException' as this will make my solution much simpler/cleaner
and because it already throws it elsewhere. However, for now I have opted to
create new methods as from my understanding, modifying the exceptions thrown is
still a breaking change to two of the APIs that have been released in 4.0.
{quote}
The breaking change is one very valid point. Another one is that
checkValidForByteConversion is also used on startup. We throw
ConfigurationException on startup, JMX setters/getters should throw
IllegalArgumentException though
[~dcapwell] , do you mind to be a second reviewer for this ticket as you were
the one who initially raised the point and worked on fixing breaking changes?
> Fix leak of non-standard Java types in our Exceptions as clients using JMX
> are unable to handle them
>
>
> Key: CASSANDRA-17668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17668
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Observability/JMX
>Reporter: Ekaterina Dimitrova
>Assignee: Leonard Ma
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a continuation of CASSANDRA-17638 where we fixed leaks introduced
> during development of 4.1 to ensure no regressions.
> This ticket is to fix a few leakages which are there since previous major
> versions, not 4.1 regressions.
> {_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and
> _setRepairSessionSpaceInMegabytes(since 4.0)_
> in the DatabaseDescriptor.
> checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf
> (both since 4.0)_
> are used in both setters and on startup. They shouldn't throw
> ConfigurationException in the setters.
> There might be more but those are at least a few obvious I found in the
> DatabaseDescriptor.
> CC [~dcapwell]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580856#comment-17580856 ] Brandon Williams commented on CASSANDRA-13010: -- Yeah, that makes sense. > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: Jon Haddad >Assignee: Stefan Miklosovic >Priority: Normal > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > Attachments: cleanup.png, multiple operations.png > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580854#comment-17580854 ] Stefan Miklosovic commented on CASSANDRA-13010: --- Hmmm interesting, let me think about how that would actually look like ... Do you want to expose additional column per entry which would contain the disk path? > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: Jon Haddad >Assignee: Stefan Miklosovic >Priority: Normal > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > Attachments: cleanup.png, multiple operations.png > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17668:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova
Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> Fix leak of non-standard Java types in our Exceptions as clients using JMX
> are unable to handle them
>
>
> Key: CASSANDRA-17668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17668
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Observability/JMX
>Reporter: Ekaterina Dimitrova
>Assignee: Leonard Ma
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> This is a continuation of CASSANDRA-17638 where we fixed leaks introduced
> during development of 4.1 to ensure no regressions.
> This ticket is to fix a few leakages which are there since previous major
> versions, not 4.1 regressions.
> {_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and
> _setRepairSessionSpaceInMegabytes(since 4.0)_
> in the DatabaseDescriptor.
> checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf
> (both since 4.0)_
> are used in both setters and on startup. They shouldn't throw
> ConfigurationException in the setters.
> There might be more but those are at least a few obvious I found in the
> DatabaseDescriptor.
> CC [~dcapwell]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-17668:
---
Assignee: Leonard Ma (was: Ekaterina Dimitrova)
> Fix leak of non-standard Java types in our Exceptions as clients using JMX
> are unable to handle them
>
>
> Key: CASSANDRA-17668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17668
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Observability/JMX
>Reporter: Ekaterina Dimitrova
>Assignee: Leonard Ma
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> This is a continuation of CASSANDRA-17638 where we fixed leaks introduced
> during development of 4.1 to ensure no regressions.
> This ticket is to fix a few leakages which are there since previous major
> versions, not 4.1 regressions.
> {_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and
> _setRepairSessionSpaceInMegabytes(since 4.0)_
> in the DatabaseDescriptor.
> checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf
> (both since 4.0)_
> are used in both setters and on startup. They shouldn't throw
> ConfigurationException in the setters.
> There might be more but those are at least a few obvious I found in the
> DatabaseDescriptor.
> CC [~dcapwell]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-17668:
---
Assignee: Ekaterina Dimitrova (was: Leonard Ma)
> Fix leak of non-standard Java types in our Exceptions as clients using JMX
> are unable to handle them
>
>
> Key: CASSANDRA-17668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17668
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Observability/JMX
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> This is a continuation of CASSANDRA-17638 where we fixed leaks introduced
> during development of 4.1 to ensure no regressions.
> This ticket is to fix a few leakages which are there since previous major
> versions, not 4.1 regressions.
> {_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and
> _setRepairSessionSpaceInMegabytes(since 4.0)_
> in the DatabaseDescriptor.
> checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf
> (both since 4.0)_
> are used in both setters and on startup. They shouldn't throw
> ConfigurationException in the setters.
> There might be more but those are at least a few obvious I found in the
> DatabaseDescriptor.
> CC [~dcapwell]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13010) nodetool compactionstats should say which disk a compaction is writing to
[ https://issues.apache.org/jira/browse/CASSANDRA-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580849#comment-17580849 ] Brandon Williams commented on CASSANDRA-13010: -- I think this looks good but shouldn't this be available via vtable too? > nodetool compactionstats should say which disk a compaction is writing to > - > > Key: CASSANDRA-13010 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13010 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: Jon Haddad >Assignee: Stefan Miklosovic >Priority: Normal > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > Attachments: cleanup.png, multiple operations.png > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17778) WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu
[ https://issues.apache.org/jira/browse/CASSANDRA-17778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580818#comment-17580818 ] Ekaterina Dimitrova commented on CASSANDRA-17778: - Thanks [~maedhroz] Added the correction suggested to [4.1|https://github.com/ekaterinadimitrova2/cassandra/commit/5b6fd6f44f6550383a5d1bcdfb164e5d2893a54b] and propagated the patch also to [trunk|https://github.com/ekaterinadimitrova2/cassandra/commit/779f6aab0c6c831f4bc19cb0455cfc32b76fc28d]. Running pre-commit workflow for both [4.1|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17778-4.1] and [trunk|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17778-trunk] but with low resources (as it is just a doc change after all) so expect many Python DTests to fail due to lack of resources Side note: I used the opportunity to fix CHANGES.txt, missing merge entry from 4.0 [here|https://github.com/ekaterinadimitrova2/cassandra/commit/779f6aab0c6c831f4bc19cb0455cfc32b76fc28d#diff-59130575b4fb2932c957db2922977d7d89afb0b2085357db1a14615a2fcad776R83] > WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu > -- > > Key: CASSANDRA-17778 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17778 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1.x, 4.x > > > There is no way to navigate to the new configuration page for CASSANDRA-15234 > ([Liberating cassandra.yaml Parameters' Names from Their > Units|https://cassandra.apache.org/doc/trunk/cassandra/new/configuration.html]) > because it is not referenced anywhere. > Unless someone has bookmarked the page, there is no way to find it on the > site. > Other doc changes expected: > * Add a small table with supported units per type as currently we list only > the duration's ones and min units for old parameters. We list the supported > units only in NEWS.txt. > * Add info about the RuntimeExceptions we introduced in CASSANDRA-17725 for > a few deprecated JMX getters. > * Add a note for Cassandra developers - "Please ensure that any JMX > setters/getters update the Config class properties and not some local copies. > Settings Virtual Table reports the configuration loaded at any time from the > Config class." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17778) WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu
[ https://issues.apache.org/jira/browse/CASSANDRA-17778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17778: Status: Ready to Commit (was: Review In Progress) > WEBSITE - Add CASSANDRA-15234 config page to Docs nav menu > -- > > Key: CASSANDRA-17778 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17778 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1.x, 4.x > > > There is no way to navigate to the new configuration page for CASSANDRA-15234 > ([Liberating cassandra.yaml Parameters' Names from Their > Units|https://cassandra.apache.org/doc/trunk/cassandra/new/configuration.html]) > because it is not referenced anywhere. > Unless someone has bookmarked the page, there is no way to find it on the > site. > Other doc changes expected: > * Add a small table with supported units per type as currently we list only > the duration's ones and min units for old parameters. We list the supported > units only in NEWS.txt. > * Add info about the RuntimeExceptions we introduced in CASSANDRA-17725 for > a few deprecated JMX getters. > * Add a note for Cassandra developers - "Please ensure that any JMX > setters/getters update the Config class properties and not some local copies. > Settings Virtual Table reports the configuration loaded at any time from the > Config class." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (aa5576831 -> 953819b2f)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard aa5576831 generate docs for 8f277185 new 953819b2f generate docs for 8f277185 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (aa5576831) \ N -- N -- N refs/heads/asf-staging (953819b2f) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (b8ee0e6c -> aa557683)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard b8ee0e6c generate docs for 8f277185 new aa557683 generate docs for 8f277185 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (b8ee0e6c) \ N -- N -- N refs/heads/asf-staging (aa557683) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17712) Remove javadocs step from CI and release process
[
https://issues.apache.org/jira/browse/CASSANDRA-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580749#comment-17580749
]
Berenguer Blasi commented on CASSANDRA-17712:
-
Given how many times we've been hit by packaging, which only gets exercised in
jenkins, seems worth it to me.
> Remove javadocs step from CI and release process
>
>
> Key: CASSANDRA-17712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17712
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
>
> Currently the javadocs step is both:
> - Taking up jenkins cycles and generating a [large
> output|https://ci-cassandra.apache.org/job/Cassandra-trunk-artifacts/1313/jdk=jdk_1.8_latest,label=cassandra/consoleFull]
> in CI when building artifacts
> - Failing randomly on javadoc issues such as {{AlterTableStatement.java:135:
> error: text not allowed in element}}
> Apidocs are not being bundled, uploaded or used anywhere. Hence it would be
> best to remove javadocs generation on every CI. Mainly removing javadoc from
> artifacts and mvn-install.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17422) Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580721#comment-17580721
]
Brandon Williams commented on CASSANDRA-17422:
--
SGTM, +1.
> Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
> --
>
> Key: CASSANDRA-17422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17422
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Attachments: CASSANDRA-17422.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Branch: 4.0
> https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.net/OutboundMessageQueueTest/testRemove_cdc/
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.net.OutboundMessageQueueTest.testRemove(OutboundMessageQueueTest.java:91)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure: 1 of 3
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17712) Remove javadocs step from CI and release process
[
https://issues.apache.org/jira/browse/CASSANDRA-17712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580719#comment-17580719
]
Brandon Williams commented on CASSANDRA-17712:
--
We don't ship the jars and I doublechecked that in the builds, so it shouldn't
make a difference but it certainly won't hurt! Thanks.
> Remove javadocs step from CI and release process
>
>
> Key: CASSANDRA-17712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17712
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
>
> Currently the javadocs step is both:
> - Taking up jenkins cycles and generating a [large
> output|https://ci-cassandra.apache.org/job/Cassandra-trunk-artifacts/1313/jdk=jdk_1.8_latest,label=cassandra/consoleFull]
> in CI when building artifacts
> - Failing randomly on javadoc issues such as {{AlterTableStatement.java:135:
> error: text not allowed in element}}
> Apidocs are not being bundled, uploaded or used anywhere. Hence it would be
> best to remove javadocs generation on every CI. Mainly removing javadoc from
> artifacts and mvn-install.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10789) Allow DBAs to kill individual client sessions from certain IP(s) and temporarily block subsequent connections without bouncing JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580699#comment-17580699
]
Stefan Miklosovic edited comment on CASSANDRA-10789 at 8/17/22 9:40 AM:
I updated this ticket to current trunk as the patch was not applying anymore. I
think that it would be nice to expose banned ips / addresses via a virtual
table. We would not have new nodetool commands which would enable / disable
clients. Instead, it would be possible to ban / unban a client via CQL virtual
table which would in turn talk to ConnectionBlacklistHandler. We might
contemplate about getting rid of JMX way of managing this stuff completely and
we would go only via CQL / virtual tables. I do not think that doing one thing
by two ways is a good idea and there is a general trend towards CQL / virtual
tables instead of JMX anyway.
Banning a client would look like:
{code:java}
INSERT INTO system_views.banned_clients (hostname) values ("192.168.1.10");
{code}
This would in turn call handler and it would add that banned host into the list.
Unbanning would look like
{code:java}
DELETE FROM system_views.banned_clients where hostname = "192.168.1.10";
{code}
This CQL functionality would be built on top of
https://issues.apache.org/jira/browse/CASSANDRA-16806 which enables DELETE when
implementation allows it. This would also support TRUNCATE to unban all clients.
EDIT: one interesting problem with this feature is that what should we do when
we ban ourselves? How would one unban himself when he banned himself? One way
of doing that would be to restart a node as the state of banned clients is not
persisted. I am just thinking about more robust way how to prevent this from
happening. I think that keeping JMX way of doing things around would solve this
issue but I would expose just that MBean and nothing else - no nodetool
commands. This is all transparent from virtual table point of view because vt
implementation would use the very same handler anyway which would JMX use as
well.
was (Author: smiklosovic):
I updated this ticket to current trunk as the patch was not applying anymore. I
think that it would be nice to expose banned ips / addresses via a virtual
table. We would not have new nodetool commands which would enable / disable
clients. Instead, it would be possible to ban / unban a client via CQL virtual
table which would in turn talk to ConnectionBlacklistHandler. We might
contemplate about getting rid of JMX way of managing this stuff completely and
we would go only via CQL / virtual tables. I do not think that doing one thing
by two ways is a good idea and there is a general trend towards CQL / virtual
tables instead of JMX anyway.
Banning a client would look like:
{code:java}
INSERT INTO system_views.banned_clients (hostname) values ("192.168.1.10");
{code}
This would in turn call handler and it would add that banned host into the list.
Unbanning would look like
{code:java}
DELETE FROM system_views.banned_clients where hostname = "192.168.1.10";
{code}
This CQL functionality would be built on top of
https://issues.apache.org/jira/browse/CASSANDRA-16806 which enables DELETE when
implementation allows it. This would also support TRUNCATE to unban all clients.
EDIT: one interesting problem with this feature is that what should we do when
we ban ourselves? How would one unban himself when he banned himself? One way
of doing that would be to restart a node as the state of banned clients is not
persisted. I am just thinking about more robust way how to prevent this from
happening.
> Allow DBAs to kill individual client sessions from certain IP(s) and
> temporarily block subsequent connections without bouncing JVM
> --
>
> Key: CASSANDRA-10789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10789
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Coordination
>Reporter: Wei Deng
>Assignee: Damien Stevenson
>Priority: Normal
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 10789-trunk-dtest.txt, 10789-trunk.txt
>
>
> In production, there could be hundreds of clients connected to a Cassandra
> cluster (maybe even from different applications), and if they use DataStax
> Java Driver, each client will establish at least one TCP connection to a
> Cassandra server (see
> https://datastax.github.io/java-driver/2.1.9/features/pooling/). This is all
> normal and at any given time, you can indeed see hundreds of ESTABLISHED
> connections to port 9042 on a C* server (from netstat -na). The problem is
> that sometimes when a C* cluster is under heavy load,
[jira] [Comment Edited] (CASSANDRA-10789) Allow DBAs to kill individual client sessions from certain IP(s) and temporarily block subsequent connections without bouncing JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580699#comment-17580699
]
Stefan Miklosovic edited comment on CASSANDRA-10789 at 8/17/22 9:36 AM:
I updated this ticket to current trunk as the patch was not applying anymore. I
think that it would be nice to expose banned ips / addresses via a virtual
table. We would not have new nodetool commands which would enable / disable
clients. Instead, it would be possible to ban / unban a client via CQL virtual
table which would in turn talk to ConnectionBlacklistHandler. We might
contemplate about getting rid of JMX way of managing this stuff completely and
we would go only via CQL / virtual tables. I do not think that doing one thing
by two ways is a good idea and there is a general trend towards CQL / virtual
tables instead of JMX anyway.
Banning a client would look like:
{code:java}
INSERT INTO system_views.banned_clients (hostname) values ("192.168.1.10");
{code}
This would in turn call handler and it would add that banned host into the list.
Unbanning would look like
{code:java}
DELETE FROM system_views.banned_clients where hostname = "192.168.1.10";
{code}
This CQL functionality would be built on top of
https://issues.apache.org/jira/browse/CASSANDRA-16806 which enables DELETE when
implementation allows it. This would also support TRUNCATE to unban all clients.
EDIT: one interesting problem with this feature is that what should we do when
we ban ourselves? How would one unban himself when he banned himself? One way
of doing that would be to restart a node as the state of banned clients is not
persisted. I am just thinking about more robust way how to prevent this from
happening.
was (Author: smiklosovic):
I updated this ticket to current trunk as the patch was not applying anymore. I
think that it would be nice to expose banned ips / addresses via a virtual
table. We would not have new nodetool commands which would enable / disable
clients. Instead, it would be possible to ban / unban a client via CQL virtual
table which would in turn talk to ConnectionBlacklistHandler. We might
contemplate about getting rid of JMX way of managing this stuff completely and
we would go only via CQL / virtual tables. I do not think that doing one thing
by two ways is a good idea and there is a general trend towards CQL / virtual
tables instead of JMX anyway.
Banning a client would look like:
{code:java}
INSERT INTO system_views.banned_clients (hostname) values ("192.168.1.10");
{code}
This would in turn call handler and it would add that banned host into the list.
Unbanning would look like
{code:java}
DELETE FROM system_views.banned_clients where hostname = "192.168.1.10";
{code}
This CQL functionality would be built on top of
https://issues.apache.org/jira/browse/CASSANDRA-16806 which enables DELETE when
implementation allows it. This would also support TRUNCATE to unban all clients.
> Allow DBAs to kill individual client sessions from certain IP(s) and
> temporarily block subsequent connections without bouncing JVM
> --
>
> Key: CASSANDRA-10789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10789
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Coordination
>Reporter: Wei Deng
>Assignee: Damien Stevenson
>Priority: Normal
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 10789-trunk-dtest.txt, 10789-trunk.txt
>
>
> In production, there could be hundreds of clients connected to a Cassandra
> cluster (maybe even from different applications), and if they use DataStax
> Java Driver, each client will establish at least one TCP connection to a
> Cassandra server (see
> https://datastax.github.io/java-driver/2.1.9/features/pooling/). This is all
> normal and at any given time, you can indeed see hundreds of ESTABLISHED
> connections to port 9042 on a C* server (from netstat -na). The problem is
> that sometimes when a C* cluster is under heavy load, when the DBA identifies
> some client session that sends abusive amount of traffic to the C* server and
> would like to stop it, they would like a lightweight approach rather than
> shutting down the JVM or rolling restart the whole cluster to kill all
> hundreds of connections in order to kill a single client session. If the DBA
> had root privilege, they would have been able to do something at the OS
> network level to achieve the same goal but oftentimes enterprise DBA role is
> separate from OS sysadmin role, so the DBAs usually don't have that privilege.
> This is especially helpful when you have a multi-tenant C*
[jira] [Comment Edited] (CASSANDRA-10789) Allow DBAs to kill individual client sessions from certain IP(s) and temporarily block subsequent connections without bouncing JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580699#comment-17580699
]
Stefan Miklosovic edited comment on CASSANDRA-10789 at 8/17/22 9:31 AM:
I updated this ticket to current trunk as the patch was not applying anymore. I
think that it would be nice to expose banned ips / addresses via a virtual
table. We would not have new nodetool commands which would enable / disable
clients. Instead, it would be possible to ban / unban a client via CQL virtual
table which would in turn talk to ConnectionBlacklistHandler. We might
contemplate about getting rid of JMX way of managing this stuff completely and
we would go only via CQL / virtual tables. I do not think that doing one thing
by two ways is a good idea and there is a general trend towards CQL / virtual
tables instead of JMX anyway.
Banning a client would look like:
{code:java}
INSERT INTO system_views.banned_clients (hostname) values ("192.168.1.10");
{code}
This would in turn call handler and it would add that banned host into the list.
Unbanning would look like
{code:java}
DELETE FROM system_views.banned_clients where hostname = "192.168.1.10";
{code}
This CQL functionality would be built on top of
https://issues.apache.org/jira/browse/CASSANDRA-16806 which enables DELETE when
implementation allows it. This would also support TRUNCATE to unban all clients.
was (Author: smiklosovic):
I updated this ticket to current trunk as the patch was not applying anymore. I
think that it would be nice to expose banned ips / addresses via a virtual
table. We would not have new nodetool commands which would enable / disable
clients. Instead, it would be possible to ban / unban a client via CQL virtual
table which would in turn talk to ConnectionBlacklistHandler. We might
contemplate about getting rid of JMX way of managing this stuff completely and
we would go only via CQL / virtual tables. I do not think that doing one thing
by two ways is a good idea and there is a general trend towards CQL / virtual
tables instead of JMX anyway.
Banning a client would look like:
{code}
INSERT INTO system_views.banned_clients (hostname) values ("192.168.1.10");
{code}
This would in turn called handler and it would added that banned host into the
list.
Unbanning would look like
{code}
DELETE FROM system_views.banned_clients where hostname = "192.168.1.10";
{code}
This CQL functionality would be built on top of
https://issues.apache.org/jira/browse/CASSANDRA-16806 which enables DELETE when
implementation allows it. This would also support TRUNCATE to unban all clients.
> Allow DBAs to kill individual client sessions from certain IP(s) and
> temporarily block subsequent connections without bouncing JVM
> --
>
> Key: CASSANDRA-10789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10789
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Coordination
>Reporter: Wei Deng
>Assignee: Damien Stevenson
>Priority: Normal
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 10789-trunk-dtest.txt, 10789-trunk.txt
>
>
> In production, there could be hundreds of clients connected to a Cassandra
> cluster (maybe even from different applications), and if they use DataStax
> Java Driver, each client will establish at least one TCP connection to a
> Cassandra server (see
> https://datastax.github.io/java-driver/2.1.9/features/pooling/). This is all
> normal and at any given time, you can indeed see hundreds of ESTABLISHED
> connections to port 9042 on a C* server (from netstat -na). The problem is
> that sometimes when a C* cluster is under heavy load, when the DBA identifies
> some client session that sends abusive amount of traffic to the C* server and
> would like to stop it, they would like a lightweight approach rather than
> shutting down the JVM or rolling restart the whole cluster to kill all
> hundreds of connections in order to kill a single client session. If the DBA
> had root privilege, they would have been able to do something at the OS
> network level to achieve the same goal but oftentimes enterprise DBA role is
> separate from OS sysadmin role, so the DBAs usually don't have that privilege.
> This is especially helpful when you have a multi-tenant C* cluster and you
> want to have the impact for handling such client to be minimal to the other
> applications. This feature (killing individual session) seems to be a common
> feature in other databases (regardless of whether the client has some
> reconnect logic or not). It could be implemented as a JMX MBean method and
>
[jira] [Commented] (CASSANDRA-10789) Allow DBAs to kill individual client sessions from certain IP(s) and temporarily block subsequent connections without bouncing JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580699#comment-17580699
]
Stefan Miklosovic commented on CASSANDRA-10789:
---
I updated this ticket to current trunk as the patch was not applying anymore. I
think that it would be nice to expose banned ips / addresses via a virtual
table. We would not have new nodetool commands which would enable / disable
clients. Instead, it would be possible to ban / unban a client via CQL virtual
table which would in turn talk to ConnectionBlacklistHandler. We might
contemplate about getting rid of JMX way of managing this stuff completely and
we would go only via CQL / virtual tables. I do not think that doing one thing
by two ways is a good idea and there is a general trend towards CQL / virtual
tables instead of JMX anyway.
Banning a client would look like:
{code}
INSERT INTO system_views.banned_clients (hostname) values ("192.168.1.10");
{code}
This would in turn called handler and it would added that banned host into the
list.
Unbanning would look like
{code}
DELETE FROM system_views.banned_clients where hostname = "192.168.1.10";
{code}
This CQL functionality would be built on top of
https://issues.apache.org/jira/browse/CASSANDRA-16806 which enables DELETE when
implementation allows it. This would also support TRUNCATE to unban all clients.
> Allow DBAs to kill individual client sessions from certain IP(s) and
> temporarily block subsequent connections without bouncing JVM
> --
>
> Key: CASSANDRA-10789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10789
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Coordination
>Reporter: Wei Deng
>Assignee: Damien Stevenson
>Priority: Normal
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 10789-trunk-dtest.txt, 10789-trunk.txt
>
>
> In production, there could be hundreds of clients connected to a Cassandra
> cluster (maybe even from different applications), and if they use DataStax
> Java Driver, each client will establish at least one TCP connection to a
> Cassandra server (see
> https://datastax.github.io/java-driver/2.1.9/features/pooling/). This is all
> normal and at any given time, you can indeed see hundreds of ESTABLISHED
> connections to port 9042 on a C* server (from netstat -na). The problem is
> that sometimes when a C* cluster is under heavy load, when the DBA identifies
> some client session that sends abusive amount of traffic to the C* server and
> would like to stop it, they would like a lightweight approach rather than
> shutting down the JVM or rolling restart the whole cluster to kill all
> hundreds of connections in order to kill a single client session. If the DBA
> had root privilege, they would have been able to do something at the OS
> network level to achieve the same goal but oftentimes enterprise DBA role is
> separate from OS sysadmin role, so the DBAs usually don't have that privilege.
> This is especially helpful when you have a multi-tenant C* cluster and you
> want to have the impact for handling such client to be minimal to the other
> applications. This feature (killing individual session) seems to be a common
> feature in other databases (regardless of whether the client has some
> reconnect logic or not). It could be implemented as a JMX MBean method and
> exposed through nodetool to the DBAs.
> Note due to CQL driver's automated reconnection, simply killing the currently
> connected client session will not work well, so the JMX parameter should be
> an IP address or a list of IP addresses, so that the Cassandra server can
> terminate existing connection with that IP, and block future connection
> attempts from that IP for the remaining time until the JVM is restarted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17110) CEP-15: (Accord) Transaction outcomes must be replicated to an optimal number of replicas
[ https://issues.apache.org/jira/browse/CASSANDRA-17110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580691#comment-17580691 ] Benedict Elliott Smith commented on CASSANDRA-17110: [PR|https://github.com/apache/cassandra-accord/pull/7] > CEP-15: (Accord) Transaction outcomes must be replicated to an optimal number > of replicas > - > > Key: CASSANDRA-17110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17110 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Priority: Normal > > Transaction outcomes that are defined by the transaction should not be > replicated, and outcomes that are computed from existing records (and as such > were not replicated as part of the original transaction) should only be > replicated to a single primary shard. This complicates execution, however, > without MVCC as the shards from which we had to read the original value > cannot delete their state until they know the updated value is replicated > durably. One simple option here might be to replicate any new values only to > those shards on whom the value's computation depended, so that any shard that > receives this new value is safely able to report what the outcome of the > transaction is (but is unable to participate in a recomputation of that part > of the transaction). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17111) CEP-15: (Accord) Transaction dependencies must include at most the txnId
[
https://issues.apache.org/jira/browse/CASSANDRA-17111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-17111:
---
Source Control Link:
[bb52de784b3a3de5ec473d3e935d4f76c6258c13|https://github.com/apache/cassandra-accord/commit/bb52de784b3a3de5ec473d3e935d4f76c6258c13]
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> CEP-15: (Accord) Transaction dependencies must include at most the txnId
>
>
> Key: CASSANDRA-17111
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17111
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Labels: pull-request-available
> Fix For: NA
>
>
> Today we must ship the entire transaction as part of the dependencies we
> share. This is very costly. We may ship only the {{txnId,primary shard key}}
> if we modify recovery to first discover the original transaction, or
> invalidate it if it cannot be found.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17422) Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580668#comment-17580668
]
Berenguer Blasi commented on CASSANDRA-17422:
-
Yep I was waiting for tomorrow, which would be the 1 month mark without any
movement, to take it. So I pushed PRs, repro'ed locally the fix and ran only
junit on all branches as I don't think we need to hammer circle 10K per branch
having the local repro already. If you +1 I'll commit.
> Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
> --
>
> Key: CASSANDRA-17422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17422
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Attachments: CASSANDRA-17422.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Branch: 4.0
> https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.net/OutboundMessageQueueTest/testRemove_cdc/
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.net.OutboundMessageQueueTest.testRemove(OutboundMessageQueueTest.java:91)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure: 1 of 3
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17422) Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17422:
Authors: Berenguer Blasi, shylaja kokoori (was: Berenguer Blasi)
> Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
> --
>
> Key: CASSANDRA-17422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17422
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Attachments: CASSANDRA-17422.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Branch: 4.0
> https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.net/OutboundMessageQueueTest/testRemove_cdc/
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.net.OutboundMessageQueueTest.testRemove(OutboundMessageQueueTest.java:91)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure: 1 of 3
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17422) Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-17422:
---
Assignee: Berenguer Blasi (was: shylaja kokoori)
> Test Failure: org.apache.cassandra.net.OutboundMessageQueueTest.testRemove-cdc
> --
>
> Key: CASSANDRA-17422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17422
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Attachments: CASSANDRA-17422.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Branch: 4.0
> https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.net/OutboundMessageQueueTest/testRemove_cdc/
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.net.OutboundMessageQueueTest.testRemove(OutboundMessageQueueTest.java:91)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> Failure: 1 of 3
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580658#comment-17580658
]
Stefan Miklosovic commented on CASSANDRA-16860:
---
Preliminary work is in this patch (1) which builds on top of CASSANDRA-17757. I
am waiting for a progress in 17757 in order to move this one forward.
(1) https://github.com/instaclustr/cassandra/tree/CASSANDRA-16860
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
