[jira] [Commented] (CASSANDRA-17214) Cannot restart a node when there are other nodes being down in in-jvm dtest framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460462#comment-17460462
]
Jacek Lewandowski commented on CASSANDRA-17214:
---
[PR for Cassandra|https://github.com/apache/cassandra/pull/1367]
[PR for DTest API|https://github.com/apache/cassandra-in-jvm-dtest-api/pull/30]
> Cannot restart a node when there are other nodes being down in in-jvm dtest
> framework
> -
>
> Key: CASSANDRA-17214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17214
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> Such scenario:
> {code:java}
> @Test
> public void test() throws Exception
> {
> try (Cluster cluster =
> init(Cluster.build(2).withDataDirCount(1)).start()))
> {
> FBUtilities.waitOnFuture(cluster.get(2).shutdown());
> FBUtilities.waitOnFuture(cluster.get(1).shutdown());
> cluster.get(1).startup();
> cluster.get(2).startup();
> }
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalStateException: Can't use shut down instances, delegate is
> null
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:210)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.getMessagingVersion(DelegatingInvokableInstance.java:90)
> at
> org.apache.cassandra.distributed.action.GossipHelper.unsafeStatusToNormal(GossipHelper.java:95)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$10(Instance.java:640)
> {noformat}
> when we do not use {{Gossiper}} feature flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17215) nodetool snapshot not copying .TOC file fir a sstable
NISHANT GUPTA created CASSANDRA-17215: - Summary: nodetool snapshot not copying .TOC file fir a sstable Key: CASSANDRA-17215 URL: https://issues.apache.org/jira/browse/CASSANDRA-17215 Project: Cassandra Issue Type: Bug Components: Tool/nodetool, Tool/sstable Reporter: NISHANT GUPTA In apache cassandra 4.0, I am seeing that nodetool snapshot is not copying the TOC file for one of the sstable. The one difference with this sstable is that time stamp of the TOC file for the problematic sstable is 13 min past rest of the files. -rw-rw-r-- 2 cassandra4 cassandra4 47 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/nb-3-big-CompressionInfo.db -rw-rw-r-- 2 cassandra4 cassandra4 64 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/nb-3-big-Data.db -rw-rw-r-- 2 cassandra4 cassandra4 10 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/nb-3-big-Digest.crc32 -rw-rw-r-- 2 cassandra4 cassandra4 16 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/nb-3-big-Filter.db -rw-rw-r-- 2 cassandra4 cassandra4 16 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/nb-3-big-Index.db -rw-rw-r-- 2 cassandra4 cassandra4 4763 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/nb-3-big-Statistics.db -rw-rw-r-- 2 cassandra4 cassandra4 56 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/nb-3-big-Summary.db *-rw-rw-r-- 1 cassandra4 cassandra4 92 Dec 15 16:45 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/nb-3-big-TOC.txt* After taking the snapshot with command "~/apache-cassandra-4.0.1/bin/nodetool snapshot -t exp_cas4_new nishant", the content of this sstable snapshot is as follows: -rw-rw-r-- 2 cassandra4 cassandra4 47 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/snapshots/exp_cas4_new/nb-3-big-CompressionInfo.db -rw-rw-r-- 2 cassandra4 cassandra4 64 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/snapshots/exp_cas4_new/nb-3-big-Data.db -rw-rw-r-- 2 cassandra4 cassandra4 10 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/snapshots/exp_cas4_new/nb-3-big-Digest.crc32 -rw-rw-r-- 2 cassandra4 cassandra4 16 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/snapshots/exp_cas4_new/nb-3-big-Filter.db -rw-rw-r-- 2 cassandra4 cassandra4 16 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/snapshots/exp_cas4_new/nb-3-big-Index.db -rw-rw-r-- 2 cassandra4 cassandra4 4763 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/snapshots/exp_cas4_new/nb-3-big-Statistics.db -rw-rw-r-- 2 cassandra4 cassandra4 56 Dec 15 16:32 /home/cassandra4/apache-cassandra-4.0.1/data/data/nishant/employee-932e34204cf511ecad596bbf203e140e/snapshots/exp_cas4_new/nb-3-big-Summary.db All the other sstables have their TOC files present. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17214) Cannot restart a node when there are other nodes being down in in-jvm dtest framework
Jacek Lewandowski created CASSANDRA-17214:
-
Summary: Cannot restart a node when there are other nodes being
down in in-jvm dtest framework
Key: CASSANDRA-17214
URL: https://issues.apache.org/jira/browse/CASSANDRA-17214
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/java
Reporter: Jacek Lewandowski
Assignee: Jacek Lewandowski
Such scenario:
{code:java}
@Test
public void test() throws Exception
{
try (Cluster cluster =
init(Cluster.build(2).withDataDirCount(1)).start()))
{
FBUtilities.waitOnFuture(cluster.get(2).shutdown());
FBUtilities.waitOnFuture(cluster.get(1).shutdown());
cluster.get(1).startup();
cluster.get(2).startup();
}
}
{code}
throws
{noformat}
java.lang.IllegalStateException: Can't use shut down instances, delegate is null
at
org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:210)
at
org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.getMessagingVersion(DelegatingInvokableInstance.java:90)
at
org.apache.cassandra.distributed.action.GossipHelper.unsafeStatusToNormal(GossipHelper.java:95)
at
org.apache.cassandra.distributed.impl.Instance.lambda$null$10(Instance.java:640)
{noformat}
when we do not use {{Gossiper}} feature flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460437#comment-17460437
]
Tibor Repasi commented on CASSANDRA-16378:
--
As a reasonable alternative, we could capture all options from STARTUP MESSAGE
into a hash and output that via the clients virtual table as a collection. That
could be more versatile but add more complexity. That would also need to
clarify of transporting all options or just those not consumed otherwise.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17195) Migrate thresholds for number of keyspaces and tables to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460413#comment-17460413
]
Ekaterina Dimitrova edited comment on CASSANDRA-17195 at 12/16/21, 4:34 AM:
Thanks [~adelapena] , overall looks good and the logging improvement seems
reasonable. Thanks!
I left a few small suggestions and questions on the PR.
The CI run looks fine. Only that materialized view related test I can't
remember seeing it failing but I am not sure also it can be related. As a
minimum we need to open at least a ticket for it.
was (Author: e.dimitrova):
Thanks [~adelapena] , overall looks good and the logging improvement seems
reasonable. Thanks!
I left a few small suggestions and questions on the PR.
The CI run look fine. Only that materialized view related test I can't remember
seeing it failing but I am not sure also it can be related. Probably as a
minimum we need to open at least a ticket for it.
> Migrate thresholds for number of keyspaces and tables to guardrails
> ---
>
> Key: CASSANDRA-17195
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17195
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Migrate the existing thresholds for the number of keyspaces and tables:
> {code}
> # table_count_warn_threshold: 150
> # keyspace_count_warn_threshold: 40
> {code}
> to a new guardrail under the guardrails section, for example:
> {code}
> guardrails:
> keyspaces:
> warn_threshold: 40
> abort_threshold: -1
> tables:
> warn_threshold: 150
> abort_threshold: -1
> {code}
> Please note that CASSANDRA-17147 has already added a guardrail for the number
> of tables, but the previous not-guardrail threshold for warning about the
> number of tables still exists.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17195) Migrate thresholds for number of keyspaces and tables to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460413#comment-17460413
]
Ekaterina Dimitrova commented on CASSANDRA-17195:
-
Thanks [~adelapena] , overall looks good and the logging improvement seems
reasonable. Thanks!
I left a few small suggestions and questions on the PR.
The CI run look fine. Only that materialized view related test I can't remember
seeing it failing but I am not sure also it can be related. Probably as a
minimum we need to open at least a ticket for it.
> Migrate thresholds for number of keyspaces and tables to guardrails
> ---
>
> Key: CASSANDRA-17195
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17195
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Migrate the existing thresholds for the number of keyspaces and tables:
> {code}
> # table_count_warn_threshold: 150
> # keyspace_count_warn_threshold: 40
> {code}
> to a new guardrail under the guardrails section, for example:
> {code}
> guardrails:
> keyspaces:
> warn_threshold: 40
> abort_threshold: -1
> tables:
> warn_threshold: 150
> abort_threshold: -1
> {code}
> Please note that CASSANDRA-17147 has already added a guardrail for the number
> of tables, but the previous not-guardrail threshold for warning about the
> number of tables still exists.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460356#comment-17460356
]
Caleb Rackliffe edited comment on CASSANDRA-17212 at 12/16/21, 1:54 AM:
Just an aside, there's a mechanism in CASSANDRA-15234 to automatically
translate old YAML option names to new ones, the {{@Replaces}} annotation. I'm
not sure if it works translating from non-nested to nested though...
was (Author: maedhroz):
Just an aside, there's [a
mechanism|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files?authenticity_token=sJmDGDBnNmsM1hvUl53SB%2BLF1Wu3figjB1J36vgRc3daSXvF%2FLdEBfHFVAKs%2BnMIS60xF178btDObW4YmbzEXA%3D%3D%5B%5D=.java%5B%5D=.rst%5B%5D=.sh%5B%5D=.spec%5B%5D=.txt%5B%5D=.yaml%5B%5D=.yml=true#diff-c0183ea76992a610729dcd0482fc92842d9e19e1d8bc1692944bcab153ecc134R34]
in CASSANDRA-15234 to automatically translate old YAML option names to new
ones, the {{@Replaces}} annotation. I'm not sure if it works translating from
non-nested to nested though...
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460356#comment-17460356
]
Caleb Rackliffe commented on CASSANDRA-17212:
-
Just an aside, there's [a
mechanism|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files?authenticity_token=sJmDGDBnNmsM1hvUl53SB%2BLF1Wu3figjB1J36vgRc3daSXvF%2FLdEBfHFVAKs%2BnMIS60xF178btDObW4YmbzEXA%3D%3D%5B%5D=.java%5B%5D=.rst%5B%5D=.sh%5B%5D=.spec%5B%5D=.txt%5B%5D=.yaml%5B%5D=.yml=true#diff-c0183ea76992a610729dcd0482fc92842d9e19e1d8bc1692944bcab153ecc134R34]
in CASSANDRA-15234 to automatically translate old YAML option names to new
ones, the {{@Replaces}} annotation. I'm not sure if it works translating from
non-nested to nested though...
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460231#comment-17460231 ] Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 12/15/21, 8:38 PM: Thank you [~maedhroz] I made all changes as per the review comments and our discussions. I also left responses on the PR. I have three commits on [this|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] new PR, as we talked (The old PR stays there, nothing added, nothing squashed; kept for reference) Next round of review on the [new |https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] PR, the following commits: * [the custom types and the related tests|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf]. All tests pass * [The annotations and converters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b] for backward compatibility. I [ran |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1253/workflows/864beb33-9051-4ef7-a96d-4e235fa96e4e] the test suite to ensure any changes in the YAML loader didn't break anything. From what I see the only failures are known ones which after rebase of the patch should go away, most of them. * [The big change |https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3]- all the parameters plus adding backward compatibility for virtual tables. [CI run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1255/workflows/89b0d74c-f745-436a-b2bb-bc7b5ea721e6] Java 8 (I will run again also Java 11 later but there was no reason to waste resources now). The only related to this patch failure is the one of _test_sstablelevelreset ._ I have to adjust the warning pattern in the dtest repo. Side Note: There are two circle ci related commits for testing purposes. Please ignore them. I will remove them at the end. I haven't touched the docs as they will have to be reworked after the migration to adoc. JMX methods conversion to the old units is in there but I will add new JMX methods in a separate commit. (There is another ticket linked to this one for that but there was a discussion better to add them here) This doesn't stop the rest of the work from being revised in the meantime. I have to add also that warning we discussed in case some parameters are set more than once in cassandra.yaml. I will do it in a separate commit. After we confirm the current work, I will do new rebase and change any new parameters in trunk to the new format (we still don't have alpha version so it is safe to just change the names and types and no backward compatibility is needed). Order of commits for now should be: 1) Cassandra repo [(the custom types and related tests)|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf] 2) Cassandra repo ([The backward compatibility framework |https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b]) 3) CCM patch 4) dtest patch 5) The [big change of parameters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3] was (Author: e.dimitrova): Thank you [~maedhroz] I made all changes as per the review comments and our discussions. I also left responses on the PR. I have three commits on [this|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] new PR, as we talked (The old PR stays there, nothing added, nothing squashed; kept for reference) Next round of review on the [new |https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] PR, the following commits: * [the custom types and the related tests|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf]. All tests pass * [The annotations and converters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b] for backward compatibility. I [ran |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1253/workflows/864beb33-9051-4ef7-a96d-4e235fa96e4e] the test suite to ensure any changes in the YAML loader didn't break anything. From what I see the only failures are known ones which after rebase of the patch should go away, most of them. * [The big change |https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3]- all the parameters plus adding backward compatibility for virtual tables. [CI run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1255/workflows/89b0d74c-f745-436a-b2bb-bc7b5ea721e6] Java 8 (I will run again also Java 11 later but there
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460231#comment-17460231
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
Thank you [~maedhroz]
I made all changes as per the review comments and our discussions. I also left
responses on the PR. I have three commits on
[this|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] new PR,
as we talked (The old PR stays there, nothing added, nothing squashed; kept for
reference) Next round of review on the [new
|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] PR, the
following commits:
* [the custom types and the related
tests|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf].
All tests pass
* [The annotations and
converters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b]
for backward compatibility. I [ran
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1253/workflows/864beb33-9051-4ef7-a96d-4e235fa96e4e]
the test suite to ensure any changes in the YAML loader didn't break anything.
From what I see the only failures are known ones which after rebase of the
patch should go away, most of them.
* [The big change
|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3]-
all the parameters plus adding backward compatibility for virtual tables. [CI
run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1255/workflows/89b0d74c-f745-436a-b2bb-bc7b5ea721e6]
Java 8 (I will run again also Java 11 later but there was no reason to waste
resources now). The only related to this patch failure is the one of
_test_sstablelevelreset ._ I have to adjust the warning pattern in the dtest
repo.
Side Note: There are two circle ci related commits for testing purposes. Please
ignore them at the end.
I haven't touched the docs as they will have to be reworked after the migration
to adoc.
JMX methods convert to the old unit is in there but I will add new JMX method
in a separate commit. (There is another ticket linked to this one for that but
there was a discussion better to add them here) This doesn't stop the rest of
the work from being revised in the meantime.
I have to add also that warning we discussed in case some parameters are set
more than once in cassandra.yaml. I will do it in a separate commit.
After we confirm the current work, I will do new rebase and change any new
parameters in trunk to the new format (we still don't have alpha version so it
is safe to just change the names and types and no backward compatibility is
needed).
Order of commits for now should be:
1) Cassandra repo [(the custom types and related
tests)|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf]
2) Cassandra repo ([The backward compatibility framework
|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b])
3) CCM patch
4) dtest patch
5) The [big change of
parameters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3]
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460204#comment-17460204
]
Benedict Elliott Smith commented on CASSANDRA-17212:
Is {{guardrails}} the best namespace for these limits? The feature might be
called guardrails, but intuitively I attribute to this user/session limits not
global restrictions for e.g. reporting errors. I also think there's no reason
to separate this kind of limit from e.g. concurrency limits for reads and
writes, and other settings that are unlikely to be a part of the guardrails
framework.
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460202#comment-17460202
]
Brandon Williams commented on CASSANDRA-17204:
--
It looks like something changed and
cql3.validation.operations.AggregationTest.testLogbackReload will have to be
updated.
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to upgrading to
> version 1.2.8, we also recommend users to set their logback configuration
> files as read-only.
> {quote}
> This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should
> probably be fixed anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460200#comment-17460200
]
Stefan Miklosovic commented on CASSANDRA-17212:
---
Yeah I do not think 14557 is released.
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17209) Avoid unecessary array allocations and initializations in RequestValidations
[
https://issues.apache.org/jira/browse/CASSANDRA-17209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17209:
Reviewers: Caleb Rackliffe
> Avoid unecessary array allocations and initializations in RequestValidations
>
>
> Key: CASSANDRA-17209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17209
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> {{RequestValidations}} methods used extensively varargs. As the array
> creation is necessary only when the check fail we endup creating most of the
> time unecessary array. This can easily be avoided by overloading the
> different methods with a number of message argument from zero to three.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460195#comment-17460195
]
Andres de la Peña commented on CASSANDRA-17212:
---
I guess that if it were in any public release we would have to keep the old
property marking it as deprecated. But I think that there isn't any release
with it, is it? In that case we can just replace it.
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460181#comment-17460181
]
C. Scott Andreas commented on CASSANDRA-17212:
--
Will the property be respected if declared as it exists in the yaml today?
Would like to make sure that compatibility with existing config files is
preserved.
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460154#comment-17460154
]
Sam Tunnicliffe commented on CASSANDRA-16378:
-
Yep, I understand the motivation and how {{StartupMessage}} handles the unknown
options. Essentially, all I'm saying is that the identifier the client supplies
here may include more than just the "name" of the app, so why not name it
accordingly.
For example, if the way you identify your application has 3 elements, like
{{{}Name{}}}, {{Version}} and {{{}Environment{}}}, you'd probably end up
encoding multiple items together like:
{{APPLICATION_NAME: someapp/qa, APPLICATION_VERSION: 1.0}}
{{APPLICATION_NAME: someapp/prod, APPLICATION_VERSION: 1.0}}
in which case isn't it more accurate to represent it:
{{APPLICATION_ID: someapp/prod, APPLICATION_VERSION: 1.0}}
It's a pretty minor consideration at the end of the day, but as we have a free
choice of which name to pick it feels worth raising the question.
Finally, maybe it's too extreme for some tastes, but you could go further and
combine the app version into the identifier, seeing as that too is completely
opaque from a Cassandra perspective.
{{APPLICATION_ID: someapp/prod;1.0}}
For this last part though, you would need to do some munging on the server side
to consume the name/version pairs that some clients will be already sending, so
maybe it's not worth the effort.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Source Control Link:
https://github.com/apache/cassandra/commit/75482d0a8ccd0b0d370aeb7ee60c72cd47a191b0
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Patch committed into trunk at 75482d0a8ccd0b0d370aeb7ee60c72cd47a191b0
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x, 4.x
>
> Attachments: CASSANDRA-17181-4.0.patch
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460139#comment-17460139
]
Benjamin Lerer commented on CASSANDRA-17181:
[~bkowalczyyk] Thanks a lot for the patch :)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x, 4.x
>
> Attachments: CASSANDRA-17181-4.0.patch
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Status: Ready to Commit (was: Changes Suggested)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x, 4.x
>
> Attachments: CASSANDRA-17181-4.0.patch
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17154) Guardrail to disable read-before-write list operations
[
https://issues.apache.org/jira/browse/CASSANDRA-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17154:
--
Fix Version/s: 4.1
> Guardrail to disable read-before-write list operations
> --
>
> Key: CASSANDRA-17154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17154
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
>
> Add guardrail to disable list operations implying read-before-write. For
> example:
> {code}
> # Whether read-before-write operation is allowed, eg. setting list element by
> index, removing list element.
> # Defaults to true to allow read before write operations
> read_before_write_list_operations_enabled: true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17189) Guardrail for page size
[
https://issues.apache.org/jira/browse/CASSANDRA-17189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17189:
--
Reviewers: Andres de la Peña
Status: Review In Progress (was: Patch Available)
> Guardrail for page size
> ---
>
> Key: CASSANDRA-17189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17189-trunk.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add guardrail limiting the query page size, for example:
> {code}
> # Guardrail to warn about or reject page sizes greater than threshold.
> # The two thresholds default to -1 to disable.
> page_size:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> Initially this can be based on the specified number of rows used as page
> size, although it would be ideal to also limit the actual size in bytes of
> the returned pages.
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on page size in the guardrails
> section of cassandra.yaml.
> # Add a getPageSize method in GuardrailsConfig returning a Threshold.Config
> object
> # Implement that method in GuardrailsOptions, which is the default yaml-based
> implementation of GuardrailsConfig
> # Add a Threshold guardrail named pageSize in Guardrails, using the
> previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails.pageSize#guard method with the page size
> that each query is going to use. The DataLimits#forPaging methods look like
> good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17189) Guardrail for page size
[
https://issues.apache.org/jira/browse/CASSANDRA-17189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17189:
--
Test and Documentation Plan: The patch includes new tests
Status: Patch Available (was: In Progress)
> Guardrail for page size
> ---
>
> Key: CASSANDRA-17189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17189-trunk.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add guardrail limiting the query page size, for example:
> {code}
> # Guardrail to warn about or reject page sizes greater than threshold.
> # The two thresholds default to -1 to disable.
> page_size:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> Initially this can be based on the specified number of rows used as page
> size, although it would be ideal to also limit the actual size in bytes of
> the returned pages.
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on page size in the guardrails
> section of cassandra.yaml.
> # Add a getPageSize method in GuardrailsConfig returning a Threshold.Config
> object
> # Implement that method in GuardrailsOptions, which is the default yaml-based
> implementation of GuardrailsConfig
> # Add a Threshold guardrail named pageSize in Guardrails, using the
> previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails.pageSize#guard method with the page size
> that each query is going to use. The DataLimits#forPaging methods look like
> good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17154) Guardrail to disable read-before-write list operations
[
https://issues.apache.org/jira/browse/CASSANDRA-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17154:
--
Test and Documentation Plan: The PR includes new unit tests for the new
guardrail
Status: Patch Available (was: In Progress)
> Guardrail to disable read-before-write list operations
> --
>
> Key: CASSANDRA-17154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17154
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrail to disable list operations implying read-before-write. For
> example:
> {code}
> # Whether read-before-write operation is allowed, eg. setting list element by
> index, removing list element.
> # Defaults to true to allow read before write operations
> read_before_write_list_operations_enabled: true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Simplify SchemaCQLHelperTest methods
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 75482d0 Simplify SchemaCQLHelperTest methods
75482d0 is described below
commit 75482d0a8ccd0b0d370aeb7ee60c72cd47a191b0
Author: Kowalczyk
AuthorDate: Mon Dec 6 22:07:13 2021 +0100
Simplify SchemaCQLHelperTest methods
Patch by Bartlomiej Kowalczyk; reviewed by Ekaterina Dimitrova and
Benjamin Lerer for CASSANDRA-17181
---
.../org/apache/cassandra/db/SchemaCQLHelper.java | 50 +++---
.../org/apache/cassandra/schema/TableMetadata.java | 12 +++---
.../org/apache/cassandra/cql3/ViewSchemaTest.java | 3 +-
.../cql3/validation/entities/TupleTypeTest.java| 1 -
.../validation/operations/CompactStorageTest.java | 14 +++---
.../apache/cassandra/db/SchemaCQLHelperTest.java | 8 ++--
.../cassandra/utils/CassandraGenerators.java | 2 +-
7 files changed, 35 insertions(+), 55 deletions(-)
diff --git a/src/java/org/apache/cassandra/db/SchemaCQLHelper.java
b/src/java/org/apache/cassandra/db/SchemaCQLHelper.java
index 5d83a2b..ca9ef25 100644
--- a/src/java/org/apache/cassandra/db/SchemaCQLHelper.java
+++ b/src/java/org/apache/cassandra/db/SchemaCQLHelper.java
@@ -19,6 +19,7 @@
package org.apache.cassandra.db;
import java.nio.ByteBuffer;
+import java.util.function.Function;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.stream.Stream;
@@ -46,34 +47,10 @@ public class SchemaCQLHelper
// Types come first, as table can't be created without them
Stream udts = SchemaCQLHelper.getUserTypesAsCQL(metadata,
types, true);
-return Stream.concat(udts,
- reCreateStatements(metadata,
-true,
-true,
-true,
-true));
-}
-
-public static Stream reCreateStatements(TableMetadata metadata,
-boolean
includeDroppedColumns,
-boolean internals,
-boolean ifNotExists,
-boolean includeIndexes)
-{
-// Record re-create schema statements
-Stream r = Stream.of(metadata)
- .map((tm) ->
SchemaCQLHelper.getTableMetadataAsCQL(tm,
-
includeDroppedColumns,
-
internals,
-
ifNotExists));
-
-if (includeIndexes)
-{
-// Indexes applied as last, since otherwise they may interfere
with column drops / re-additions
-r = Stream.concat(r, SchemaCQLHelper.getIndexesAsCQL(metadata,
ifNotExists));
-}
+Stream tableMatadata =
Stream.of(SchemaCQLHelper.getTableMetadataAsCQL(metadata));
-return r;
+Stream indexes = SchemaCQLHelper.getIndexesAsCQL(metadata,
true);
+return Stream.of(udts, tableMatadata,
indexes).flatMap(Function.identity());
}
/**
@@ -83,20 +60,25 @@ public class SchemaCQLHelper
* that will not contain everything needed for user types.
*/
@VisibleForTesting
-public static String getTableMetadataAsCQL(TableMetadata metadata,
- boolean includeDroppedColumns,
- boolean internals,
- boolean ifNotExists)
+public static String getTableMetadataAsCQL(TableMetadata metadata)
{
if (metadata.isView())
{
KeyspaceMetadata keyspaceMetadata =
Schema.instance.getKeyspaceMetadata(metadata.keyspace);
ViewMetadata viewMetadata =
keyspaceMetadata.views.get(metadata.name).orElse(null);
assert viewMetadata != null;
-return viewMetadata.toCqlString(internals, ifNotExists);
+/*
+ * first argument(withInternals) indicates to include table
metadata id and clustering columns order,
+ * second argument(ifNotExists) instructs to include IF NOT EXISTS
statement within creation statements.
+ */
+return viewMetadata.toCqlString(true, true);
}
-return metadata.toCqlString(includeDroppedColumns, internals,
ifNotExists);
+/*
+ * With addition to withInternals and ifNotExists arguments,
includeDroppedColumns will include dropped
+
[jira] [Comment Edited] (CASSANDRA-16386) Column rpc_address on system_local ignores broadcast_rpc_address yaml setting
[
https://issues.apache.org/jira/browse/CASSANDRA-16386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460119#comment-17460119
]
João Reis edited comment on CASSANDRA-16386 at 12/15/21, 5:26 PM:
--
I believe this may have been fixed by CASSANDRA-11181 from looking at the
comments.
was (Author: joao.reis):
I believe this may have been fixed by
https://issues.apache.org/jira/browse/CASSANDRA-11181 from looking at the
comments.
> Column rpc_address on system_local ignores broadcast_rpc_address yaml setting
> -
>
> Key: CASSANDRA-16386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16386
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: João Reis
>Priority: Normal
>
> While troubleshooting a driver issue I ran into a potential C* issue
> regarding the {{rpc_address}} and {{broadcast_rpc_address}} yaml settings. On
> {{system.peers}} I see that the {{rpc_address}} column is populated with the
> {{broadcast_rpc_address}} setting when {{rpc_address}} is {{0.0.0.0}} but
> this is not the same behavior for the {{system.local}} table.
> On {{system.local}}, {{rpc_address}} is returned as {{0.0.0.0}} even if
> {{broadcast_rpc_address}} is set. In my opinion the {{rpc_address}} on
> {{system.local}} should also be populated with the {{broadcast_rpc_address}}
> setting if {{rpc_address}} is {{0.0.0.0}}.
> I tested this with C* 3.11.8, 4.0-beta2 and 4.0-beta4 so it looks like this
> behavior has been like this for a while now.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16386) Column rpc_address on system_local ignores broadcast_rpc_address yaml setting
[
https://issues.apache.org/jira/browse/CASSANDRA-16386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460119#comment-17460119
]
João Reis commented on CASSANDRA-16386:
---
I believe this may have been fixed by
https://issues.apache.org/jira/browse/CASSANDRA-11181 from looking at the
comments.
> Column rpc_address on system_local ignores broadcast_rpc_address yaml setting
> -
>
> Key: CASSANDRA-16386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16386
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: João Reis
>Priority: Normal
>
> While troubleshooting a driver issue I ran into a potential C* issue
> regarding the {{rpc_address}} and {{broadcast_rpc_address}} yaml settings. On
> {{system.peers}} I see that the {{rpc_address}} column is populated with the
> {{broadcast_rpc_address}} setting when {{rpc_address}} is {{0.0.0.0}} but
> this is not the same behavior for the {{system.local}} table.
> On {{system.local}}, {{rpc_address}} is returned as {{0.0.0.0}} even if
> {{broadcast_rpc_address}} is set. In my opinion the {{rpc_address}} on
> {{system.local}} should also be populated with the {{broadcast_rpc_address}}
> setting if {{rpc_address}} is {{0.0.0.0}}.
> I tested this with C* 3.11.8, 4.0-beta2 and 4.0-beta4 so it looks like this
> behavior has been like this for a while now.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17154) Guardrail to disable read-before-write list operations
[
https://issues.apache.org/jira/browse/CASSANDRA-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460115#comment-17460115
]
Andres de la Peña edited comment on CASSANDRA-17154 at 12/15/21, 5:24 PM:
--
The proposed PR adds a new guardrails named
{{read_before_write_list_operations_enabled}} that disables setting list
elements by index and removing list elements by either index or value.
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1366]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1212/workflows/752519f8-afa1-4813-a9fd-c8b06211854d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1212/workflows/872a9039-86b8-48b5-addd-75099175c490]|
The guardrail itself is quite simple, but getting the {{ClientState}} into the
proper methods in {{Lists}} is a bit noisy.
was (Author: adelapena):
The proposed PR adds a new guardrails named
{{read_before_write_list_operations_enabled}} that disables setting list
elements by index and removing list elements by either index or value.
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1366]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1212/workflows/752519f8-afa1-4813-a9fd-c8b06211854d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1212/workflows/7734e98f-93c2-4bbb-993a-7523d9669a94]|
The guardrail itself is quite simple, but getting the {{ClientState}} into the
proper methods in {{Lists}} is a bit noisy.
> Guardrail to disable read-before-write list operations
> --
>
> Key: CASSANDRA-17154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17154
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrail to disable list operations implying read-before-write. For
> example:
> {code}
> # Whether read-before-write operation is allowed, eg. setting list element by
> index, removing list element.
> # Defaults to true to allow read before write operations
> read_before_write_list_operations_enabled: true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17154) Guardrail to disable read-before-write list operations
[
https://issues.apache.org/jira/browse/CASSANDRA-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460115#comment-17460115
]
Andres de la Peña commented on CASSANDRA-17154:
---
The proposed PR adds a new guardrails named
{{read_before_write_list_operations_enabled}} that disables setting list
elements by index and removing list elements by either index or value.
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1366]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1212/workflows/752519f8-afa1-4813-a9fd-c8b06211854d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1212/workflows/7734e98f-93c2-4bbb-993a-7523d9669a94]|
The guardrail itself is quite simple, but getting the {{ClientState}} into the
proper methods in {{Lists}} is a bit noisy.
> Guardrail to disable read-before-write list operations
> --
>
> Key: CASSANDRA-17154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17154
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrail to disable list operations implying read-before-write. For
> example:
> {code}
> # Whether read-before-write operation is allowed, eg. setting list element by
> index, removing list element.
> # Defaults to true to allow read before write operations
> read_before_write_list_operations_enabled: true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460113#comment-17460113
]
Tibor Repasi commented on CASSANDRA-16378:
--
As I understood the
[native_protocol_v5.spec|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec],
the list of options is already arbitrary, which is comparable to HTTP
X-Headers. StartupMessage is a codec that decodes the payload to get all the
supported options.
DataStax has extended the java-driver to send application_name and
application_version options along. Somewhere I've seen that SpringBoot
automatically fills in these properties, thus they are available, but not yet
appreciated by Apache Cassandra.
When the applications connecting to the Cassandra clusters I run started to
move from named on-prem hosts to Kubernetes, I was wondering how do I find out
which applications are connecting now, as the far side tcp endpoints moved to
some arbitrary worker nodes which may run other applications as well.
So the main objective from the operators point of view is to improve visibility
by exposing what's already provided.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14684:
---
Description:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
+Additional information for newcomers:+
Some checks should be added into {{TokenRestriction}} for the different type of
restrictions when an invalid value is found.
The unit tests should be added within {{SelectOrderedPartitionerTest}}
The problem should be fixed in 3.0. It will merge cleanly to the other branches
was:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
+Additional information for newcomers:+
Some checks should be added into {{TokenRestriction}} for the different type of
restrictions when an invalid value is found.
The unit tests should be added within {{SelectOrderedPartitionerTest}}
The problem should be fixed in 3.0. It should mere cleanly to the other
branches
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
> +Additional information for newcomers:+
> Some checks should be added into {{TokenRestriction}} for the different type
> of restrictions when an invalid value is found.
> The unit tests should be added within {{SelectOrderedPartitionerTest}}
> The problem should be fixed in 3.0. It will merge cleanly to the other
> branches
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14684:
---
Description:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
+Additional information for newcomers:+
Some checks should be added into {{TokenRestriction}} for the different type of
restrictions when an invalid value is found.
The unit tests should be added within {{SelectOrderedPartitionerTest}}
The problem should be fixed in 3.0. It should mere cleanly to the other
branches
was:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
+Additional information for newcomers:+
Some checks should be added into {{TokenRestriction}} for the different type of
restrictions when an invalid value is found.
The unit tests should be added within {{SelectOrderedPartitionerTest}}
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
> +Additional information for newcomers:+
> Some checks should be added into {{TokenRestriction}} for the different type
> of restrictions when an invalid value is found.
> The unit tests should be added within {{SelectOrderedPartitionerTest}}
> The problem should be fixed in 3.0. It should mere cleanly to the other
> branches
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14684:
---
Labels: AdventCalendar2021 lhf (was: lhf)
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
> +Additional information for newcomers:+
> Some checks should be added into {{TokenRestriction}} for the different type
> of restrictions when an invalid value is found.
> The unit tests should be added within {{SelectOrderedPartitionerTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14684:
---
Description:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
Additional information for newcomers:
Some checks should be added into {{TokenRestriction}} for the different type of
restrictions when an invalid value is found.
The unit tests should be added within {{SelectOrderedPartitionerTest}}
was:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
+ Additional information for newcomers:+
Some checks should be added into {{TokenRestriction}} for the different type of
restrictions when an invalid value is found.
The unit tests should be added within {{SelectOrderedPartitionerTest}}
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Low
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
> Additional information for newcomers:
> Some checks should be added into {{TokenRestriction}} for the different type
> of restrictions when an invalid value is found.
> The unit tests should be added within {{SelectOrderedPartitionerTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14684) Queries with a clause involving tokens and Long.MIN_VALUE include rows incorrectly
[
https://issues.apache.org/jira/browse/CASSANDRA-14684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14684:
---
Description:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
+Additional information for newcomers:+
Some checks should be added into {{TokenRestriction}} for the different type of
restrictions when an invalid value is found.
The unit tests should be added within {{SelectOrderedPartitionerTest}}
was:
[cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
When running a CQL query where we filter on a token compared to
-9223372036854775808 (the minimum value for a long), the filter appears to have
no effect.
For example:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
LIMIT 3;
system.token(user_id)
---
-9223371814601747988
-9223371814601747988
-9223371814601747988
{code}
It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
comparison, the results appear the same.
In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as expected:
{code:java}
SELECT token(user_id) FROM events WHERE token(user_id) <= -9223372036854775807
LIMIT 3;
system.token(user_id)
---
(0 rows)
{code}
Additional information for newcomers:
Some checks should be added into {{TokenRestriction}} for the different type of
restrictions when an invalid value is found.
The unit tests should be added within {{SelectOrderedPartitionerTest}}
> Queries with a clause involving tokens and Long.MIN_VALUE include rows
> incorrectly
> --
>
> Key: CASSANDRA-14684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14684
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: George Boyle
>Priority: Low
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> [cqlsh 5.0.1 | Cassandra 2.2.9 | CQL spec 3.3.1 | Native protocol v4]
> When running a CQL query where we filter on a token compared to
> -9223372036854775808 (the minimum value for a long), the filter appears to
> have no effect.
> For example:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) = -9223372036854775808
> LIMIT 3;
> system.token(user_id)
> ---
> -9223371814601747988
> -9223371814601747988
> -9223371814601747988
> {code}
> It doesn't matter whether `=`, `<`, `<=`, `>` or `>=` are used in the
> comparison, the results appear the same.
> In contrast, if using `Long.MIN_VALUE + 1`, it returns no results as
> expected:
> {code:java}
> SELECT token(user_id) FROM events WHERE token(user_id) <=
> -9223372036854775807 LIMIT 3;
> system.token(user_id)
> ---
> (0 rows)
> {code}
>
> +Additional information for newcomers:+
> Some checks should be added into {{TokenRestriction}} for the different type
> of restrictions when an invalid value is found.
> The unit tests should be added within {{SelectOrderedPartitionerTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17204) Upgrade to Logback 1.2.8 (security)
[
https://issues.apache.org/jira/browse/CASSANDRA-17204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459528#comment-17459528
]
Brandon Williams edited comment on CASSANDRA-17204 at 12/15/21, 4:23 PM:
-
It's probably worth considering upgrading all the branches.
||Branch||CI||
|[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17204]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1322/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1322/pipeline]|
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-17204-3.11]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204-3.11],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1323/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1323/pipeline]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17204-4.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204-4.0],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1324/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1324/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17204-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204-trunk],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1326/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1326/pipeline]|
was (Author: brandon.williams):
It's probably worth considering upgrading all the branches.
||Branch||CI||
|[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17204]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1322/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1322/pipeline]|
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-17204-3.11]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204-3.11],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1323/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1323/pipeline]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17204-4.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204-4.0],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1324/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1324/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17204-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17204-trunk],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1325/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1325/pipeline]|
> Upgrade to Logback 1.2.8 (security)
> ---
>
> Key: CASSANDRA-17204
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17204
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Jochen Schalanda
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Logback 1.2.8 has been released with a fix for a potential vulnerability in
> its JNDI lookup.
> * [http://logback.qos.ch/news.html]
> * [https://jira.qos.ch/browse/LOGBACK-1591]
> {quote}*14th of December, 2021, Release of version 1.2.8*
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite.
> * • In response to LOGBACK-1591, we have disabled all JNDI lookup code in
> logback until further notice. This impacts {{ContextJNDISelector}} and
> {{}} element in configuration files.
> * Also in response to LOGBACK-1591, we have removed all database (JDBC)
> related code in the project with no replacement.
> We note that the vulnerability mentioned in LOGBACK-1591 requires write
> access to logback's configuration file as a prerequisite. A successful RCE
> requires all of the following to be true:
> * write access to logback.xml
> * use of versions < 1.2.8
> * reloading of poisoned configuration data, which implies application restart
> or scan="true" set prior to attack
> Therefore and as an additional precaution, in addition to
[jira] [Updated] (CASSANDRA-17154) Guardrail to disable read-before-write list operations
[
https://issues.apache.org/jira/browse/CASSANDRA-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17154:
--
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Guardrail to disable read-before-write list operations
> --
>
> Key: CASSANDRA-17154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17154
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrail to disable list operations implying read-before-write. For
> example:
> {code}
> # Whether read-before-write operation is allowed, eg. setting list element by
> index, removing list element.
> # Defaults to true to allow read before write operations
> read_before_write_list_operations_enabled: true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17154) Guardrail to disable read-before-write list operations
[
https://issues.apache.org/jira/browse/CASSANDRA-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-17154:
-
Assignee: Andres de la Peña
> Guardrail to disable read-before-write list operations
> --
>
> Key: CASSANDRA-17154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17154
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrail to disable list operations implying read-before-write. For
> example:
> {code}
> # Whether read-before-write operation is allowed, eg. setting list element by
> index, removing list element.
> # Defaults to true to allow read before write operations
> read_before_write_list_operations_enabled: true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17180) Implement heartbeat service to know last time Cassandra node was up
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460033#comment-17460033 ] Stefan Miklosovic edited comment on CASSANDRA-17180 at 12/15/21, 3:16 PM: -- I have implemented configurable checks here: [https://github.com/apache/cassandra/pull/1351/files] While doing that, there is FileSystemOwnershipCheck which is reading some system properties in order to configure itself. I have made it configurable too but I left system properties resolution there too to be backward compatible (system properties have precendece) so we will eventually get rid of that way of configuring it. I have created respective properties in CassandraRelevantProperties and aligned all tests. Some checks are not trully checks, they are just setting something or logging. Like jemalloc or inspecting jvm options or so. It is up to following discussion if we make these "checks" unconfigurable (but they will be still executed). was (Author: smiklosovic): I have implemented configurable checks here: [https://github.com/apache/cassandra/pull/1351/files] While doing that, there is FileSystemOwnershipCheck which is reading some system properties in order to configure itself. I have made it configurable too but I left system properties resolution there too to be backward compatible (system properties have precendece) so we will eventually get rid of that way of configuring it. I have created respective properties in CassandraRelevantProperties and aligned all tests. > Implement heartbeat service to know last time Cassandra node was up > --- > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17180) Implement heartbeat service to know last time Cassandra node was up
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460033#comment-17460033 ] Stefan Miklosovic commented on CASSANDRA-17180: --- I have implemented configurable checks here: [https://github.com/apache/cassandra/pull/1351/files] While doing that, there is FileSystemOwnershipCheck which is reading some system properties in order to configure itself. I have made it configurable too but I left system properties resolution there too to be backward compatible (system properties have precendece) so we will eventually get rid of that way of configuring it. I have created respective properties in CassandraRelevantProperties and aligned all tests. > Implement heartbeat service to know last time Cassandra node was up > --- > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460022#comment-17460022
]
Ivan Senic edited comment on CASSANDRA-17202 at 12/15/21, 3:00 PM:
---
Done.
3.11: [https://github.com/apache/cassandra/pull/1364]
4.0: [https://github.com/apache/cassandra/pull/1365]
was (Author: JIRAUSER281556):
Done:
3.11: [https://github.com/apache/cassandra/pull/1364]
4.0: [https://github.com/apache/cassandra/pull/1365]
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460022#comment-17460022
]
Ivan Senic commented on CASSANDRA-17202:
Done:
3.11: [https://github.com/apache/cassandra/pull/1364]
4.0: [https://github.com/apache/cassandra/pull/1365]
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17213) CompactStorageUpgradeTest.compactStorageUpgradeTest fails w/OOM
[ https://issues.apache.org/jira/browse/CASSANDRA-17213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17213: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: Legacy/Local Write-Read Paths Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > CompactStorageUpgradeTest.compactStorageUpgradeTest fails w/OOM > --- > > Key: CASSANDRA-17213 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17213 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Josh McKenzie >Priority: Normal > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/882/testReport/org.apache.cassandra.distributed.upgrade/CompactStorageUpgradeTest/compactStorageUpgradeTest/] > h3. Error Message > GC overhead limit exceeded > h3. Stacktrace > java.lang.OutOfMemoryError: GC overhead limit exceeded at > sun.net.www.ParseUtil.encodePath(ParseUtil.java:105) at > sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:969) at > sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:1056) at > sun.misc.URLClassPath.getResource(URLClassPath.java:249) at > java.net.URLClassLoader$1.run(URLClassLoader.java:366) at > java.net.URLClassLoader$1.run(URLClassLoader.java:363) at > java.security.AccessController.doPrivileged(Native Method) at > java.net.URLClassLoader.findClass(URLClassLoader.java:362) at > org.apache.cassandra.distributed.shared.InstanceClassLoader.findClass(InstanceClassLoader.java:140) > at > org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:123) > at > org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:109) > at > org.codehaus.jackson.map.introspect.BasicClassIntrospector.(BasicClassIntrospector.java:62) > at org.codehaus.jackson.map.ObjectMapper.(ObjectMapper.java:188) at > org.apache.cassandra.utils.FBUtilities.(FBUtilities.java:74) at > org.apache.cassandra.distributed.impl.Instance.(Instance.java:144) at > org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper$$Lambda$21599/1714755496.apply(Unknown > Source) at > org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.newInstance(AbstractCluster.java:247) > at > org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.(AbstractCluster.java:226) > at > org.apache.cassandra.distributed.UpgradeableCluster.newInstanceWrapper(UpgradeableCluster.java:46) > at > org.apache.cassandra.distributed.UpgradeableCluster.newInstanceWrapper(UpgradeableCluster.java:36) > at > org.apache.cassandra.distributed.impl.AbstractCluster.newInstanceWrapperInternal(AbstractCluster.java:515) > at > org.apache.cassandra.distributed.impl.AbstractCluster.(AbstractCluster.java:470) > at > org.apache.cassandra.distributed.UpgradeableCluster.(UpgradeableCluster.java:40) > at > org.apache.cassandra.distributed.UpgradeableCluster.(UpgradeableCluster.java:36) > at > org.apache.cassandra.distributed.UpgradeableCluster$Builder.lambda$new$0(UpgradeableCluster.java:86) > at > org.apache.cassandra.distributed.UpgradeableCluster$Builder$$Lambda$73/1631826609.newCluster(Unknown > Source) at > org.apache.cassandra.distributed.shared.AbstractBuilder.createWithoutStarting(AbstractBuilder.java:158) > at > org.apache.cassandra.distributed.shared.AbstractBuilder.start(AbstractBuilder.java:140) > at > org.apache.cassandra.distributed.UpgradeableCluster.create(UpgradeableCluster.java:73) > at > org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:223) > at > org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageUpgradeTest(CompactStorageUpgradeTest.java:159) > h3. Standard Output > out of memory on output stream > > Appears consistent -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17213) CompactStorageUpgradeTest.compactStorageUpgradeTest fails w/OOM
Josh McKenzie created CASSANDRA-17213: - Summary: CompactStorageUpgradeTest.compactStorageUpgradeTest fails w/OOM Key: CASSANDRA-17213 URL: https://issues.apache.org/jira/browse/CASSANDRA-17213 Project: Cassandra Issue Type: Bug Reporter: Josh McKenzie [https://ci-cassandra.apache.org/job/Cassandra-trunk/882/testReport/org.apache.cassandra.distributed.upgrade/CompactStorageUpgradeTest/compactStorageUpgradeTest/] h3. Error Message GC overhead limit exceeded h3. Stacktrace java.lang.OutOfMemoryError: GC overhead limit exceeded at sun.net.www.ParseUtil.encodePath(ParseUtil.java:105) at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:969) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:1056) at sun.misc.URLClassPath.getResource(URLClassPath.java:249) at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at org.apache.cassandra.distributed.shared.InstanceClassLoader.findClass(InstanceClassLoader.java:140) at org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:123) at org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:109) at org.codehaus.jackson.map.introspect.BasicClassIntrospector.(BasicClassIntrospector.java:62) at org.codehaus.jackson.map.ObjectMapper.(ObjectMapper.java:188) at org.apache.cassandra.utils.FBUtilities.(FBUtilities.java:74) at org.apache.cassandra.distributed.impl.Instance.(Instance.java:144) at org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper$$Lambda$21599/1714755496.apply(Unknown Source) at org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.newInstance(AbstractCluster.java:247) at org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.(AbstractCluster.java:226) at org.apache.cassandra.distributed.UpgradeableCluster.newInstanceWrapper(UpgradeableCluster.java:46) at org.apache.cassandra.distributed.UpgradeableCluster.newInstanceWrapper(UpgradeableCluster.java:36) at org.apache.cassandra.distributed.impl.AbstractCluster.newInstanceWrapperInternal(AbstractCluster.java:515) at org.apache.cassandra.distributed.impl.AbstractCluster.(AbstractCluster.java:470) at org.apache.cassandra.distributed.UpgradeableCluster.(UpgradeableCluster.java:40) at org.apache.cassandra.distributed.UpgradeableCluster.(UpgradeableCluster.java:36) at org.apache.cassandra.distributed.UpgradeableCluster$Builder.lambda$new$0(UpgradeableCluster.java:86) at org.apache.cassandra.distributed.UpgradeableCluster$Builder$$Lambda$73/1631826609.newCluster(Unknown Source) at org.apache.cassandra.distributed.shared.AbstractBuilder.createWithoutStarting(AbstractBuilder.java:158) at org.apache.cassandra.distributed.shared.AbstractBuilder.start(AbstractBuilder.java:140) at org.apache.cassandra.distributed.UpgradeableCluster.create(UpgradeableCluster.java:73) at org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:223) at org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageUpgradeTest(CompactStorageUpgradeTest.java:159) h3. Standard Output out of memory on output stream Appears consistent -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17212:
--
Description:
The config property
[{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
{code}
guardrails:
...
replication_factor:
warn_threshold: 2
abort_threshold: 3
{code}
was:
The config property [{{minimum_keyspace_rf}}|# The minimum allowable
replication factor. Creating a keyspace with a replication factor less than
this value will be rejected.
# This would also apply to system keyspaces.
# Suggested value for use in production: 2 or higher
# minimum_keyspace_rf: 0] that was added by CASSANDRA-14557 can be migrated to
guardrails, for example:
{code}
guardrails:
...
replication_factor:
warn_threshold: 2
abort_threshold: 3
{code}
> Migrate threshold for minimum keyspace replication factor to guardrails
> ---
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17212) Migrate threshold for minimum keyspace replication factor to guardrails
Andres de la Peña created CASSANDRA-17212:
-
Summary: Migrate threshold for minimum keyspace replication factor
to guardrails
Key: CASSANDRA-17212
URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
The config property [{{minimum_keyspace_rf}}|# The minimum allowable
replication factor. Creating a keyspace with a replication factor less than
this value will be rejected.
# This would also apply to system keyspaces.
# Suggested value for use in production: 2 or higher
# minimum_keyspace_rf: 0] that was added by CASSANDRA-14557 can be migrated to
guardrails, for example:
{code}
guardrails:
...
replication_factor:
warn_threshold: 2
abort_threshold: 3
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459989#comment-17459989
]
Benjamin Lerer commented on CASSANDRA-17181:
That look good to me :-)
[CI
run|https://app.circleci.com/pipelines/github/blerer/cassandra/252/workflows/00138f7d-c813-47fa-9b0d-284a059c8d22]
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x, 4.x
>
> Attachments: CASSANDRA-17181-4.0.patch
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17211) java.lang.IllegalStateException while streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-17211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
NISHANT GUPTA updated CASSANDRA-17211:
--
Description:
Getting following exception with latest cassandra 4.0.1
([https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz).]
DEBUG [Stream-Deserializer-/10.14.20.147:7010-bceedc49] 2021-12-15 18:33:45,143
StreamingInboundHandler.java:179 - [Stream channel: bceedc49] Received
keep-alive
INFO [Stream-Deserializer-/10.14.20.147:7010-bceedc49] 2021-12-15 18:33:45,543
StreamResultFuture.java:114 - [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88
ID#0] Creating new streaming plan for Bulk Load from /10.14.20.147:7010
channel.remote /10.14.20.147:36064 channel.local /10.14.20.148:7010 channel.id
bceedc49
DEBUG [Stream-Deserializer-/10.14.20.147:7010-bceedc49] 2021-12-15 18:33:45,544
StreamSession.java:242 - Creating stream session to peer: (/10.14.20.147:7010,
null), framing: null, encryption: unencrypted as follower
INFO [Stream-Deserializer-/10.14.20.147:7010-bceedc49] 2021-12-15 18:33:45,544
StreamResultFuture.java:123 - [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88,
ID#0] Received streaming plan for Bulk Load from /10.14.20.147:7010
channel.remote /10.14.20.147:36064 channel.local /10.14.20.148:7010 channel.id
bceedc49
DEBUG [Stream-Deserializer-/10.14.20.147:7010-bceedc49] 2021-12-15 18:33:45,544
NettyStreamingMessageSender.java:189 - [Stream
#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Scheduling keep-alive
task with 300s period.
DEBUG [Stream-Deserializer-/10.14.20.147:7010-bceedc49] 2021-12-15 18:33:45,545
StreamingInboundHandler.java:187 - [Stream
#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Received
StreamInitMessage: from = /10.14.20.147:7010, planId =
6e073350-5da7-11ec-a3ee-6dd9f5cb6e88, session index = 0
DEBUG [Stream-Deserializer-/10.14.20.147:7010-bceedc49] 2021-12-15 18:33:45,545
StreamingInboundHandler.java:187 - [Stream
#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Received Prepare SYN
(0 requests, 1 files}
DEBUG [Messaging-EventLoop-3-1] 2021-12-15 18:33:45,545
NettyStreamingMessageSender.java:258 - [Stream
#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Sending keep-alive
DEBUG [NonPeriodicTasks:1] 2021-12-15 18:33:45,545
NettyStreamingMessageSender.java:258 - [Stream
#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Sending Prepare SYNACK
( 0 files}
INFO [NonPeriodicTasks:1] 2021-12-15 18:33:45,545 StreamResultFuture.java:178
- [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 ID#0] Prepare completed.
Receiving 1 files(0.000KiB), sending 0 files(0.000KiB)
INFO [Messaging-EventLoop-3-2] 2021-12-15 18:33:45,982
InboundConnectionInitiator.java:400 -
/10.14.20.147:7010(/10.14.20.147:36068)->/10.14.20.148:7010-STREAMING-553b69ef
streaming connection established, version = 12, framing = UNPROTECTED,
encryption = unencrypted
DEBUG [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,383
CassandraIncomingFile.java:70 - Incoming stream entireSSTable=false
components=null
DEBUG [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,383
CassandraCompressedStreamReader.java:73 - [Stream
#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88] Start receiving file #0 from
/10.14.20.147:7010, repairedAt = 0, size = 0, ks =
'nishant_restore_cassandra4', pendingRepair = 'null', table = 'employee'.
DEBUG [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,384
StreamingInboundHandler.java:187 - [Stream
#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: 553b69ef] Received
IncomingStreamMessage\{header=Header (tableId:
fd5f2c70-5da6-11ec-99bb-fd2b97c714b3, #0, repairedAt: 0, pendingRepair: null,
sendByFollower: false),
stream=CassandraIncomingFile{sstable=nishant_restore_cassandra4/employee}}
ERROR [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,384
StreamSession.java:674 - [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88]
Streaming error occurred on session with peer 10.14.20.147:7010
java.lang.IllegalStateException: Stream hasn't been read yet
at
com.google.common.base.Preconditions.checkState(Preconditions.java:507)
at
org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96)
at
org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:787)
at
org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:588)
at
org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
DEBUG [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,384
NettyStreamingMessageSender.java:258 - [Stream
[jira] [Commented] (CASSANDRA-17207) The process cannot access the file because it is being used by another process.
[ https://issues.apache.org/jira/browse/CASSANDRA-17207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459978#comment-17459978 ] Brandon Williams commented on CASSANDRA-17207: -- It is worth mentioning if this is a new installation that Windows support is removed in CASSANDRA-16171. > The process cannot access the file because it is being used by another > process. > --- > > Key: CASSANDRA-17207 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17207 > Project: Cassandra > Issue Type: Bug >Reporter: shravansingh >Priority: Normal > > > ERROR [COMMIT-LOG-ALLOCATOR] 2021-12-11 17:02:00,989 > JVMStabilityInspector.java:140 - JVM state determined to be unstable. > Exiting forcefully due to: > org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException: > \commitlog\CommitLog-6-1636406548826.log: The process cannot access > the file because it is being used by another process. > > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:138) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:155) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:342) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManager$2.run(CommitLogSegmentManager.java:379) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:156) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > [apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) > [apache-cassandra-3.0.14.jar:3.0.14] > at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_301] > Caused by: java.nio.file.FileSystemException: > \commitlog\CommitLog-6-1636406548826.log: The process cannot access > the file because it is being used by another process. > > at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) > ~[na:1.8.0_301] > at java.nio.file.Files.delete(Unknown Source) ~[na:1.8.0_301] > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:132) > ~[apache-cassandra-3.0.14.jar:3.0.14] > ... 7 common frames omitted > It seems similar to https://issues.apache.org/jira/browse/CASSANDRA-8390, but > it was resolved in 2.2 beta, though I am facing this in version 3.0.14 > I am running this on windows server OS and in cassandra.yaml, > disk_access_mode is set to standard -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17210) Not able to override default transport port in cassandra 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-17210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17210: - Bug Category: Parent values: Correctness(12982) Complexity: Normal Discovered By: User Report Fix Version/s: 4.0.x Severity: Low Status: Open (was: Triage Needed) > Not able to override default transport port in cassandra 4.0 > > > Key: CASSANDRA-17210 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17210 > Project: Cassandra > Issue Type: Bug > Components: Tool/bulk load >Reporter: NISHANT GUPTA >Priority: Normal > Fix For: 4.0.x > > > Bulk Loader is not honouring "-p" option given on the command line of the > sstableloader. > The command line used is: > ~/apache-cassandra-4.0.1/bin/sstableloader -d 10.14.20.148 -cph 1 -idct 0 -p > 9942 -ssp 7011 -sp 7010 --verbose ~/cassandra4_experiment/nishant/employee/ > > but the call is still going to /10.14.20.148:9042. We are just passing the > host information to the Cluster.Builder in NativeSSTableLoaderClient.java: > Cluster.Builder builder = > Cluster.builder().addContactPointsWithPorts(hosts).allowBetaProtocolVersion(); > Looks like default port is getting picked inside > com.datastax.driver.core.cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17211) java.lang.IllegalStateException while streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17211: - Bug Category: Parent values: Correctness(12982) Complexity: Normal Discovered By: User Report Severity: Low Status: Open (was: Triage Needed) > java.lang.IllegalStateException while streaming > --- > > Key: CASSANDRA-17211 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17211 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: NISHANT GUPTA >Priority: Normal > > Getting following exception with latest cassandra 4.0.1 > ([https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz).] > ERROR [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 > 18:33:46,384 StreamSession.java:674 - [Stream > #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88|#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88] > Streaming error occurred on session with peer 10.14.20.147:7010 > java.lang.IllegalStateException: Stream hasn't been read yet > at > com.google.common.base.Preconditions.checkState(Preconditions.java:507) > at > org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96) > at > org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:787) > at > org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:588) > at > org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > DEBUG [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 > 18:33:46,384 NettyStreamingMessageSender.java:258 - [Stream > #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Sending Session > Failed > This looks to be related to CASSANDRA-16349. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17211) java.lang.IllegalStateException while streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] NISHANT GUPTA updated CASSANDRA-17211: -- Description: Getting following exception with latest cassandra 4.0.1 ([https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz).] ERROR [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,384 StreamSession.java:674 - [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88|#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88] Streaming error occurred on session with peer 10.14.20.147:7010 java.lang.IllegalStateException: Stream hasn't been read yet at com.google.common.base.Preconditions.checkState(Preconditions.java:507) at org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96) at org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:787) at org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:588) at org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) DEBUG [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,384 NettyStreamingMessageSender.java:258 - [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Sending Session Failed This looks to be related to CASSANDRA-16349. was: Getting following exception with latest cassandra 4.0.1 ([https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz).] ERROR [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,384 StreamSession.java:674 - [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88] Streaming error occurred on session with peer 10.14.20.147:7010 java.lang.IllegalStateException: Stream hasn't been read yet at com.google.common.base.Preconditions.checkState(Preconditions.java:507) at org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96) at org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:787) at org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:588) at org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) This looks to be related to CASSANDRA-16349. DEBUG [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,384 NettyStreamingMessageSender.java:258 - [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Sending Session Failed > java.lang.IllegalStateException while streaming > --- > > Key: CASSANDRA-17211 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17211 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: NISHANT GUPTA >Priority: Normal > > Getting following exception with latest cassandra 4.0.1 > ([https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz).] > ERROR [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 > 18:33:46,384 StreamSession.java:674 - [Stream > #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88|#6e073350-5da7-11ec-a3ee-6dd9f5cb6e88] > Streaming error occurred on session with peer 10.14.20.147:7010 > java.lang.IllegalStateException: Stream hasn't been read yet > at > com.google.common.base.Preconditions.checkState(Preconditions.java:507) > at > org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96) > at > org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:787) > at > org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:588) > at > org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > DEBUG [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 > 18:33:46,384 NettyStreamingMessageSender.java:258 - [Stream > #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Sending Session > Failed > This looks to be related to CASSANDRA-16349. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For
[jira] [Comment Edited] (CASSANDRA-17205) File leaks will not be be detected and released due to strong self-references in the tidier
[
https://issues.apache.org/jira/browse/CASSANDRA-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459954#comment-17459954
]
Benedict Elliott Smith edited comment on CASSANDRA-17205 at 12/15/21, 2:05 PM:
---
We could check {{totalDiskSpaceUsed != null &&
DatabaseDescriptor.isDaemonInitialized()}} if we can assume that it is always
set in the {{Metrics}} object (which today it is), to keep functionality
equivalent.
Otherwise LGTM
was (Author: benedict):
We could check {{totalDiskSpaceUsed != null &&
DatabaseDescriptor.isDaemonInitialized()}} if we can assume that it is always
set in the {{Metrics}} object (which today it is), to keep functionality
equivalent.
> File leaks will not be be detected and released due to strong self-references
> in the tidier
> ---
>
> Key: CASSANDRA-17205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17205
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> LogTransaction.SSTableTidier holds a reference to a {{Tracker}} which holds
> references to both a {{ColumnFamilyStore}} and a {{View}}, both of which hold
> refs to SSTableReaders. As per the comment at the top of the SSTableTidier:
> {quote}// must not retain a reference to the SSTableReader, else leak
> detection cannot kick in
> {quote}
> We shouldn't hold a reference to the Tracker here; long running unit tests
> w/-Dcassandra.debugrefcount=true had this pop up.
> {code}ERROR [Strong-Reference-Leak-Detector:1] 2020-10-27T01:10:12,421
> NoSpamLogger.java:97 - Strong self-ref loop detected{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17211) java.lang.IllegalStateException while streaming
NISHANT GUPTA created CASSANDRA-17211: - Summary: java.lang.IllegalStateException while streaming Key: CASSANDRA-17211 URL: https://issues.apache.org/jira/browse/CASSANDRA-17211 Project: Cassandra Issue Type: Bug Components: Tool/sstable Reporter: NISHANT GUPTA Getting following exception with latest cassandra 4.0.1 ([https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz).] ERROR [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,384 StreamSession.java:674 - [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88] Streaming error occurred on session with peer 10.14.20.147:7010 java.lang.IllegalStateException: Stream hasn't been read yet at com.google.common.base.Preconditions.checkState(Preconditions.java:507) at org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96) at org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:787) at org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:588) at org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) This looks to be related to CASSANDRA-16349. DEBUG [Stream-Deserializer-/10.14.20.147:7010-553b69ef] 2021-12-15 18:33:46,384 NettyStreamingMessageSender.java:258 - [Stream #6e073350-5da7-11ec-a3ee-6dd9f5cb6e88 channel: bceedc49] Sending Session Failed -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17210) Not able to override default transport port in cassandra 4.0
NISHANT GUPTA created CASSANDRA-17210: - Summary: Not able to override default transport port in cassandra 4.0 Key: CASSANDRA-17210 URL: https://issues.apache.org/jira/browse/CASSANDRA-17210 Project: Cassandra Issue Type: Bug Components: Tool/bulk load Reporter: NISHANT GUPTA Bulk Loader is not honouring "-p" option given on the command line of the sstableloader. The command line used is: ~/apache-cassandra-4.0.1/bin/sstableloader -d 10.14.20.148 -cph 1 -idct 0 -p 9942 -ssp 7011 -sp 7010 --verbose ~/cassandra4_experiment/nishant/employee/ but the call is still going to /10.14.20.148:9042. We are just passing the host information to the Cluster.Builder in NativeSSTableLoaderClient.java: Cluster.Builder builder = Cluster.builder().addContactPointsWithPorts(hosts).allowBetaProtocolVersion(); Looks like default port is getting picked inside com.datastax.driver.core.cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17205) File leaks will not be be detected and released due to strong self-references in the tidier
[
https://issues.apache.org/jira/browse/CASSANDRA-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459954#comment-17459954
]
Benedict Elliott Smith commented on CASSANDRA-17205:
We could check {{totalDiskSpaceUsed != null &&
DatabaseDescriptor.isDaemonInitialized()}} if we can assume that it is always
set in the {{Metrics}} object (which today it is), to keep functionality
equivalent.
> File leaks will not be be detected and released due to strong self-references
> in the tidier
> ---
>
> Key: CASSANDRA-17205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17205
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> LogTransaction.SSTableTidier holds a reference to a {{Tracker}} which holds
> references to both a {{ColumnFamilyStore}} and a {{View}}, both of which hold
> refs to SSTableReaders. As per the comment at the top of the SSTableTidier:
> {quote}// must not retain a reference to the SSTableReader, else leak
> detection cannot kick in
> {quote}
> We shouldn't hold a reference to the Tracker here; long running unit tests
> w/-Dcassandra.debugrefcount=true had this pop up.
> {code}ERROR [Strong-Reference-Leak-Detector:1] 2020-10-27T01:10:12,421
> NoSpamLogger.java:97 - Strong self-ref loop detected{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17209) Avoid unecessary array allocations and initializations in RequestValidations
[
https://issues.apache.org/jira/browse/CASSANDRA-17209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459880#comment-17459880
]
Benjamin Lerer edited comment on CASSANDRA-17209 at 12/15/21, 1:51 PM:
---
[PR|https://github.com/apache/cassandra/pull/1363] and [CI
runs|https://app.circleci.com/pipelines/github/blerer/cassandra/251/workflows/383d6001-09a0-4b57-b79b-e4863e6cbdec]
was (Author: blerer):
[PR|https://github.com/apache/cassandra/pull/1363] and CI runs for
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/250/workflows/3586ea2c-b0f9-4b10-a0ee-f3026252d017]
and
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/250/workflows/c3cccf88-ca85-4a53-b02e-4808aee1bedc]
> Avoid unecessary array allocations and initializations in RequestValidations
>
>
> Key: CASSANDRA-17209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17209
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> {{RequestValidations}} methods used extensively varargs. As the array
> creation is necessary only when the check fail we endup creating most of the
> time unecessary array. This can easily be avoided by overloading the
> different methods with a number of message argument from zero to three.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459945#comment-17459945
]
Brandon Williams commented on CASSANDRA-17126:
--
Sure! Assigned to you.
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17126:
Assignee: Venkata Harikrishna Nukala (was: Brandon Williams)
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17126:
Assignee: Brandon Williams
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17189) Guardrail for page size
[
https://issues.apache.org/jira/browse/CASSANDRA-17189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459944#comment-17459944
]
Andres de la Peña commented on CASSANDRA-17189:
---
You are very welcome, and thanks for the PR with tests :)
The PR mostly looks good to me, I have left a few minor suggestions on it.
> Guardrail for page size
> ---
>
> Key: CASSANDRA-17189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17189-trunk.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add guardrail limiting the query page size, for example:
> {code}
> # Guardrail to warn about or reject page sizes greater than threshold.
> # The two thresholds default to -1 to disable.
> page_size:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> Initially this can be based on the specified number of rows used as page
> size, although it would be ideal to also limit the actual size in bytes of
> the returned pages.
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on page size in the guardrails
> section of cassandra.yaml.
> # Add a getPageSize method in GuardrailsConfig returning a Threshold.Config
> object
> # Implement that method in GuardrailsOptions, which is the default yaml-based
> implementation of GuardrailsConfig
> # Add a Threshold guardrail named pageSize in Guardrails, using the
> previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails.pageSize#guard method with the page size
> that each query is going to use. The DataLimits#forPaging methods look like
> good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459943#comment-17459943
]
Benjamin Lerer commented on CASSANDRA-17202:
[~ivansenic] Yes, if you do not mind.
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459937#comment-17459937
]
Ivan Senic commented on CASSANDRA-17202:
The GitHub PR is updated as per request.
[~blerer] Are you saying I should create two more PRs, one targeting the
_cassandra-3.11_ and one _cassandra-4.0_ branch? The current PR targets the
{_}trunk{_}.
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17209) Avoid unecessary array allocations and initializations in RequestValidations
[
https://issues.apache.org/jira/browse/CASSANDRA-17209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459880#comment-17459880
]
Benjamin Lerer commented on CASSANDRA-17209:
[PR|https://github.com/apache/cassandra/pull/1363] and CI runs for
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/250/workflows/3586ea2c-b0f9-4b10-a0ee-f3026252d017]
and
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/250/workflows/c3cccf88-ca85-4a53-b02e-4808aee1bedc]
> Avoid unecessary array allocations and initializations in RequestValidations
>
>
> Key: CASSANDRA-17209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17209
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> {{RequestValidations}} methods used extensively varargs. As the array
> creation is necessary only when the check fail we endup creating most of the
> time unecessary array. This can easily be avoided by overloading the
> different methods with a number of message argument from zero to three.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17209) Avoid unecessary array allocations and initializations in RequestValidations
[
https://issues.apache.org/jira/browse/CASSANDRA-17209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17209:
---
Test and Documentation Plan: No need for new tests
Status: Patch Available (was: Open)
> Avoid unecessary array allocations and initializations in RequestValidations
>
>
> Key: CASSANDRA-17209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17209
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> {{RequestValidations}} methods used extensively varargs. As the array
> creation is necessary only when the check fail we endup creating most of the
> time unecessary array. This can easily be avoided by overloading the
> different methods with a number of message argument from zero to three.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17209) Avoid unecessary array allocations and initializations in RequestValidations
[
https://issues.apache.org/jira/browse/CASSANDRA-17209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17209:
---
Change Category: Performance
Complexity: Low Hanging Fruit
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Avoid unecessary array allocations and initializations in RequestValidations
>
>
> Key: CASSANDRA-17209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17209
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> {{RequestValidations}} methods used extensively varargs. As the array
> creation is necessary only when the check fail we endup creating most of the
> time unecessary array. This can easily be avoided by overloading the
> different methods with a number of message argument from zero to three.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17209) Avoid unecessary array allocation and initialization in RequestValidations
Benjamin Lerer created CASSANDRA-17209:
--
Summary: Avoid unecessary array allocation and initialization in
RequestValidations
Key: CASSANDRA-17209
URL: https://issues.apache.org/jira/browse/CASSANDRA-17209
Project: Cassandra
Issue Type: Improvement
Components: CQL/Interpreter
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
{{RequestValidations}} methods used extensively varargs. As the array creation
is necessary only when the check fail we endup creating most of the time
unecessary array. This can easily be avoided by overloading the different
methods with a number of message argument from zero to three.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17209) Avoid unecessary array allocations and initializations in RequestValidations
[
https://issues.apache.org/jira/browse/CASSANDRA-17209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17209:
---
Summary: Avoid unecessary array allocations and initializations in
RequestValidations (was: Avoid unecessary array allocation and initialization
in RequestValidations)
> Avoid unecessary array allocations and initializations in RequestValidations
>
>
> Key: CASSANDRA-17209
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17209
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> {{RequestValidations}} methods used extensively varargs. As the array
> creation is necessary only when the check fail we endup creating most of the
> time unecessary array. This can easily be avoided by overloading the
> different methods with a number of message argument from zero to three.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459856#comment-17459856
]
Benjamin Lerer commented on CASSANDRA-17202:
In fact it seems that it also affect earlier releases. I think we also need a
patch for 3.0 (it will merge cleanly into 3.11) and the patch for 4.0 (it will
merge cleanly in trunk).
I you can make those patches. I will run CI for them :-)
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17207) The process cannot access the file because it is being used by another process.
[ https://issues.apache.org/jira/browse/CASSANDRA-17207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459789#comment-17459789 ] Benjamin Lerer commented on CASSANDRA-17207: [~JoshuaMcKenzie] You are probably the more knowledgeable regarding those type of problems. > The process cannot access the file because it is being used by another > process. > --- > > Key: CASSANDRA-17207 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17207 > Project: Cassandra > Issue Type: Bug >Reporter: shravansingh >Priority: Normal > > > ERROR [COMMIT-LOG-ALLOCATOR] 2021-12-11 17:02:00,989 > JVMStabilityInspector.java:140 - JVM state determined to be unstable. > Exiting forcefully due to: > org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException: > \commitlog\CommitLog-6-1636406548826.log: The process cannot access > the file because it is being used by another process. > > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:138) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:155) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:342) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManager$2.run(CommitLogSegmentManager.java:379) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:156) > ~[apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > [apache-cassandra-3.0.14.jar:3.0.14] > at > org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79) > [apache-cassandra-3.0.14.jar:3.0.14] > at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_301] > Caused by: java.nio.file.FileSystemException: > \commitlog\CommitLog-6-1636406548826.log: The process cannot access > the file because it is being used by another process. > > at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) > ~[na:1.8.0_301] > at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) > ~[na:1.8.0_301] > at java.nio.file.Files.delete(Unknown Source) ~[na:1.8.0_301] > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:132) > ~[apache-cassandra-3.0.14.jar:3.0.14] > ... 7 common frames omitted > It seems similar to https://issues.apache.org/jira/browse/CASSANDRA-8390, but > it was resolved in 2.2 beta, though I am facing this in version 3.0.14 > I am running this on windows server OS and in cassandra.yaml, > disk_access_mode is set to standard -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17126) Remove use of deprecated Files in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459787#comment-17459787
]
Venkata Harikrishna Nukala commented on CASSANDRA-17126:
Can I pick it?
> Remove use of deprecated Files in tests
> ---
>
> Key: CASSANDRA-17126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17126
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Priority: Normal
>
> From checkstyle:
> {noformat}
> 5 Illegal import - java.io.File. [IllegalImport]
> 3 Illegal import - java.io.FileInputStream. [IllegalImport]
> 2 Illegal import - java.io.FileOutputStream. [IllegalImport]
> 3 Illegal import - java.io.FileWriter. [IllegalImport]
> 16 Illegal import - java.io.RandomAccessFile. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459751#comment-17459751
]
Sam Tunnicliffe commented on CASSANDRA-16378:
-
Apologies for the drive-by comment, but I wonder if rather than a pre-defined
set of attributes on the Cassandra side ({{{}APPLICATION_NAME{}}} and
{{{}APPLICATION_VERSION{}}}), it might be better to define a single, opaque
identifier into which clients can encode whatever info they need to track
according to their specific deployment model(s). Basically, I'm suggesting the
equivalent of HTTP's {{User-Agent}} header.
This may not be _as_ directly queryable via the system table, but it pre-empts
and makes explicit what would need to happen for any model that isn't simply
"name + version". I would argue that the driver ought to adopt the same
approach in future and that in the meantime and for backwards compatibility we
compose the identifier string by concatenating {{APPLICATION_NAME}} and
{{{}APPLICATION_VERSION{}}}.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459440#comment-17459440
]
Tibor Repasi edited comment on CASSANDRA-16378 at 12/15/21, 8:11 AM:
-
The additional information has lowered the threshold to attack my first
contribution to Cassandra.
I've added most of the necessary things as described without breaking any unit
tests so far. Linked the PR.
Got stuck with the unit test, which I'd appreciate some hints how I can inject
driver attributes, application_name and application_version, into the session
to assert the contents of the virtual table.
Still a question if nodetool would need change to expose the data on the
command line.
was (Author: rtib):
The additional information has lowered the threshold to attack my first
contribution to Cassandra.
I've added most of the necessary things as described without breaking any unit
tests so far. Linked the PR.
Got stuck with the unit test, which I'd appreciate some hints how I can inject
driver attributes into the session to assert the contents of the virtual table.
Still a question if nodetool would need change to expose the data on the
command line.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
