[cassandra-website] branch asf-staging updated (a82a908e4 -> 897d235f8)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard a82a908e4 generate docs for 16320f1d new 897d235f8 generate docs for 16320f1d This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (a82a908e4) \ N -- N -- N refs/heads/asf-staging (897d235f8) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724478#comment-17724478 ] Brad Schoening commented on CASSANDRA-15046: I agree about the history order, and have updated the PR with the change so that latest is at the bottom. > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16895: Description: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *May 12th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed to negotiate (netty complains about certificate_unknown). Changes in JDK17 config to be checked EDIT2: CASSANDRA-18540 | |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - 2 tests|CASSANDRA-18180| | |_Unit Tests_| | |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| |7|org.apache.cassandra.cql3.EmptyValuesTest|CASSANDRA-18436| |8|org.apache.cassandra.transport.MessagePayloadTest-.jdk17|CASSANDRA-18437| was: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *May 12th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed to negotiate (netty complains about certificate_unknown). Changes
[jira] [Updated] (CASSANDRA-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16895: Description: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *May 12th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed to negotiate (netty complains about certificate_unknown). Changes in JDK17 config to be checked EDIT2: CASSANDRA-18840 | |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - 2 tests|CASSANDRA-18180| | |_Unit Tests_| | |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| |7|org.apache.cassandra.cql3.EmptyValuesTest|CASSANDRA-18436| |8|org.apache.cassandra.transport.MessagePayloadTest-.jdk17|CASSANDRA-18437| was: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *May 12th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed to negotiate (netty complains about certificate_unknown). Changes
[jira] [Updated] (CASSANDRA-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16895: Description: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *May 12th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed to negotiate (netty complains about certificate_unknown). Changes in JDK17 config to be checked EDIT2: CASSANDRA-just 18840 | |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - 2 tests|CASSANDRA-18180| | |_Unit Tests_| | |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| |7|org.apache.cassandra.cql3.EmptyValuesTest|CASSANDRA-18436| |8|org.apache.cassandra.transport.MessagePayloadTest-.jdk17|CASSANDRA-18437| was: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *May 12th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed to negotiate (netty complains about certificate_unknown).
[jira] [Updated] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18540:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: Unit Test
Severity: Normal
Status: Open (was: Triage Needed)
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Priority: Normal
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, a
> specific JDK8 build (accidentally?) dropped TLSv1.1 (later added again) which
> led to adding some docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18540:
Fix Version/s: 5.x
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, a
> specific JDK8 build (accidentally?) dropped TLSv1.1 (later added again) which
> led to adding some docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724461#comment-17724461
]
Ekaterina Dimitrova commented on CASSANDRA-18540:
-
CC [~mck] (you've been looking into CASSANDRA-16848)
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Priority: Normal
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, a
> specific JDK8 build (accidentally?) dropped TLSv1.1 (later added again) which
> led to adding some docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18084) Introduce tags to snitch for better decision making for replica placement in topology strategies
[
https://issues.apache.org/jira/browse/CASSANDRA-18084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724458#comment-17724458
]
Josh McKenzie commented on CASSANDRA-18084:
---
Missed the ping earlier Stefan; I'm up to my eyeballs in various things right
now. Any chance you have cycles [~paulo] ?
> Introduce tags to snitch for better decision making for replica placement in
> topology strategies
>
>
> Key: CASSANDRA-18084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18084
> Project: Cassandra
> Issue Type: New Feature
> Components: Cluster/Gossip, Cluster/Schema, Legacy/Distributed
> Metadata
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We would like to have extra meta-information in cassandra-rackdc.properties
> which would further differentiate nodes in dc / racks.
> The main motivation behind this is that we have special requirements around
> node's characteristics based on which we want to make further decisions when
> it comes to replica placement in topology strategies. (New topology strategy
> would be mostly derived from NTS / would be extended)
> The most reasonable way to do that is to introduce a new property into
> cassandra-rackdc.properties called "tags"
> {code:java}
> # Arbitrary tag to assign to this node, they serve as additional
> identificator of a node based on which operators might act.
> # Value of this property is meant to be a comma-separated list of strings.
> #tags=tag1,tag2
> {code}
> We also want to introduce new application state called TAGS. On startup of a
> node, this node would advertise its tags to cluster and vice versa, all nodes
> would tell to that respective node what tags they have so everybody would see
> the same state of tags across the cluster based on which topology strategies
> would do same decisions.
> These tags are not meant to be changed during whole runtime of a node,
> similarly as datacenter and rack is not.
> For performance reasons, we might limit the maximum size of tags (sum of
> their lenght), to be, for example, 64 characters and anything bigger would be
> either shortened or the start would fail.
> Once we have tags for all nodes, we can have access to them, cluster-wide,
> from TokenMetadata which is used quite heavily in topology strategies and it
> exposes other relevant topology information (dc's, racks ...). We would just
> add a new way to look at nodes.
> Tags would be a set.
> This would be persisted to the system.local to see what tags a local node has
> and it would be persisted to system.peers_v2 to see what tags all other nodes
> have. Column would be called "tags".
> {code:java}
> admin@cqlsh> select * from system.local ;
> @ Row 1
> key | local
> bootstrapped| COMPLETED
> broadcast_address | 172.19.0.5
> broadcast_port | 7000
> cluster_name| Test Cluster
> cql_version | 3.4.6
> data_center | dc1
> gossip_generation | 1669739177
> host_id | 54f8c6ea-a6ba-40c5-8fa5-484b2b4184c9
> listen_address | 172.19.0.5
> listen_port | 7000
> native_protocol_version | 5
> partitioner | org.apache.cassandra.dht.Murmur3Partitioner
> rack| rack1
> release_version | 4.2-SNAPSHOT
> rpc_address | 172.19.0.5
> rpc_port| 9042
> schema_version | ef865449-2491-33b8-95b0-47c09cb14ea9
> tags| {'tag1', 'tag2'}
> tokens | {'6504358681601109713'}
> {code}
> for system.peers_v2:
> {code:java}
> admin@cqlsh> select peer,tags from system.peers_v2 ;
> @ Row 1
> --+-
> peer | 172.19.0.15
> tags | {'tag2', 'tag3'}
> @ Row 2
> --+-
> peer | 172.19.0.11
> tags | null
> {code}
> the POC implementation doing exactly that is here:
> We do not want to provide our custom topology strategies which are using this
> feature as that will be the most probably a proprietary solution. This might
> indeed change in the future. For now, we just want to implement hooks we can
> base our in-house implementation on. All other people can benefit from this
> as well if they choose so as this feature enables them to do that.
> Adding tags is not only about custom topology strategies. Operators could tag
> their nodes if they wish to make further distinctions on topology level for
> their operational needs.
> [https://github.com/instaclustr/cassandra/commit/eddd4681d8678515454dabb926d5f56b0c225eea]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
dan jatnieks created CASSANDRA-18540:
Summary: negotiatedProtocolMustBeAcceptedProtocolTest tests fail
with "TLSv1.1 failed to negotiate" on JDK17
Key: CASSANDRA-18540
URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
Project: Cassandra
Issue Type: Bug
Components: CI
Reporter: dan jatnieks
Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
tests in {{NativeTransportEncryptionOptionsTest}} and
{{InternodeEncryptionOptionsTest}} are failing due to that issue.
Using the patch for CASSANDRA-18180, the
{{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
{{NativeTransportEncryptionOptionsTest}} and {{InternodeEncryptionOptionsTest}}
fails with "TLSv1.1 failed to negotiate" on JDK17.
>From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
>failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for JDK8
as that will be dropped.
Also, I think the point of the {{negotiatedProtocolMustBeAcceptedProtocolTest}}
is to test that the {{accepted_protocols}} option is working correctly rather
than the choice of _which_ protocol is used. Meaning, I don’t think the intent
was to test TLSv1.1 specifically, rather that the mechanism of accepted
protocols works and choosing TLSv1.1 was at the time convenient - but I could
be wrong.
It also seems to me like bit of a coincidence that these tests are currently
working on JDK11, at least on CI. Indeed, running locally with JDK11, these
fail for me:
{noformat}
$ pwd
/Users/dan.jatnieks/apache/cassandra-4.0
$ java -version
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
$ ant test-jvm-dtest-some
-Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
-Duse.jdk11=true
...
[junit-timeout] Testcase:
negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
FAILED
[junit-timeout] Should be possible to establish a TLSv1.1 connection
expected: but was:
[junit-timeout] junit.framework.AssertionFailedError: Should be possible to
establish a TLSv1.1 connection expected: but
was:
[junit-timeout] at
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{noformat}
I believe these work on CI because of CASSANDRA-16848 - in that ticket, a
specific JDK8 build (accidentally?) dropped TLSv1.1 (later added again) which
led to adding some docker code to make sure TLSv1.1 is accepted.
I say coincidence because this change also makes it work for JDK11 and JDK17,
and I've been able to verify that making a change locally to the JDK
{{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it was
intended for any JDK versions.
The point of mentioning this is that if
{{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2, and
support for JDK8 is dropped, then the changes made in CASSANDRA-16848 could
also be reverted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-50) Remove deprecate health endpoint containing instance segment
[
https://issues.apache.org/jira/browse/CASSANDRASC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-50:
--
Status: Needs Committer (was: Patch Available)
> Remove deprecate health endpoint containing instance segment
>
>
> Key: CASSANDRASC-50
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-50
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> The Cassandra Health endpoint containing the instance segment in the path
> usage is deprecated. This endpoint is currently unused and it is replaced by
> the health endpoint with the {{instanceId}} query string parameter. Since the
> {{instanceId}} is optional we move the path param (mandatory) to the query
> param (optional).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-50) Remove deprecate health endpoint containing instance segment
[
https://issues.apache.org/jira/browse/CASSANDRASC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-50:
--
Test and Documentation Plan: Added unit tests and modified existing unit
tests to capture the behavior change
Status: Patch Available (was: In Progress)
PR: https://github.com/apache/cassandra-sidecar/pull/46
> Remove deprecate health endpoint containing instance segment
>
>
> Key: CASSANDRASC-50
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-50
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> The Cassandra Health endpoint containing the instance segment in the path
> usage is deprecated. This endpoint is currently unused and it is replaced by
> the health endpoint with the {{instanceId}} query string parameter. Since the
> {{instanceId}} is optional we move the path param (mandatory) to the query
> param (optional).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-50) Remove deprecate health endpoint containing instance segment
[
https://issues.apache.org/jira/browse/CASSANDRASC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CASSANDRASC-50:
--
Labels: pull-request-available (was: )
> Remove deprecate health endpoint containing instance segment
>
>
> Key: CASSANDRASC-50
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-50
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> The Cassandra Health endpoint containing the instance segment in the path
> usage is deprecated. This endpoint is currently unused and it is replaced by
> the health endpoint with the {{instanceId}} query string parameter. Since the
> {{instanceId}} is optional we move the path param (mandatory) to the query
> param (optional).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-50) Remove deprecate health endpoint containing instance segment
[
https://issues.apache.org/jira/browse/CASSANDRASC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRASC-50:
--
Change Category: Semantic
Complexity: Low Hanging Fruit
Component/s: Rest API
Status: Open (was: Triage Needed)
> Remove deprecate health endpoint containing instance segment
>
>
> Key: CASSANDRASC-50
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-50
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> The Cassandra Health endpoint containing the instance segment in the path
> usage is deprecated. This endpoint is currently unused and it is replaced by
> the health endpoint with the {{instanceId}} query string parameter. Since the
> {{instanceId}} is optional we move the path param (mandatory) to the query
> param (optional).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-50) Remove deprecate health endpoint containing instance segment
Francisco Guerrero created CASSANDRASC-50:
-
Summary: Remove deprecate health endpoint containing instance
segment
Key: CASSANDRASC-50
URL: https://issues.apache.org/jira/browse/CASSANDRASC-50
Project: Sidecar for Apache Cassandra
Issue Type: Improvement
Reporter: Francisco Guerrero
Assignee: Francisco Guerrero
The Cassandra Health endpoint containing the instance segment in the path usage
is deprecated. This endpoint is currently unused and it is replaced by the
health endpoint with the {{instanceId}} query string parameter. Since the
{{instanceId}} is optional we move the path param (mandatory) to the query
param (optional).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (3e25a07b1 -> a82a908e4)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 3e25a07b1 generate docs for 16320f1d new a82a908e4 generate docs for 16320f1d This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (3e25a07b1) \ N -- N -- N refs/heads/asf-staging (a82a908e4) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16222) CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-16222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724446#comment-17724446 ] Dinesh Joshi commented on CASSANDRA-16222: -- Committed [here|https://github.com/apache/cassandra-sidecar/commit/38cdacb2e7418e2aefbcffb1754dcd324c46028d] and [here|https://github.com/apache/cassandra-analytics/commit/1633cd9c6c3d88d5c66825fab76a369266509f7e]. Thanks, everybody. > CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics > > > Key: CASSANDRA-16222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16222 > Project: Cassandra > Issue Type: New Feature > Components: Tool/external >Reporter: James Berragan >Assignee: Francisco Guerrero >Priority: Normal > Fix For: NA > > Attachments: sparkbulkreader.patch > > > *Description:* > This ticket introduces the Spark-Cassandra Bulk Analytics library and > associated Cassandra Sidecar endpoints. > > Please see > [CEP-28|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics] > for more details, motivation, and available source code links. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16222) CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-16222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16222: - Source Control Link: https://github.com/apache/cassandra-analytics/commit/1633cd9c6c3d88d5c66825fab76a369266509f7e Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics > > > Key: CASSANDRA-16222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16222 > Project: Cassandra > Issue Type: New Feature > Components: Tool/external >Reporter: James Berragan >Assignee: Francisco Guerrero >Priority: Normal > Fix For: NA > > Attachments: sparkbulkreader.patch > > > *Description:* > This ticket introduces the Spark-Cassandra Bulk Analytics library and > associated Cassandra Sidecar endpoints. > > Please see > [CEP-28|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics] > for more details, motivation, and available source code links. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16222) CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-16222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16222: - Status: Ready to Commit (was: Review In Progress) +1 > CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics > > > Key: CASSANDRA-16222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16222 > Project: Cassandra > Issue Type: New Feature > Components: Tool/external >Reporter: James Berragan >Assignee: Francisco Guerrero >Priority: Normal > Fix For: NA > > Attachments: sparkbulkreader.patch > > > *Description:* > This ticket introduces the Spark-Cassandra Bulk Analytics library and > associated Cassandra Sidecar endpoints. > > Please see > [CEP-28|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics] > for more details, motivation, and available source code links. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-analytics] branch trunk created (now 1633cd9)
This is an automated email from the ASF dual-hosted git repository. djoshi pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-analytics.git at 1633cd9 CEP-28: Apache Cassandra Analytics This branch includes the following new commits: new 1633cd9 CEP-28: Apache Cassandra Analytics The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724433#comment-17724433 ] Stefan Miklosovic edited comment on CASSANDRA-15046 at 5/19/23 10:24 PM: - After all, I do not think that numbering is necessary. If people want to copy what they did to some script, they would have numbers at the front which they would need to get rid of first. If we can not reference it then numbering is irrelevant. I do not think that referencing is easy thing to do. was (Author: smiklosovic): After all, I do not think that numbering is necessary. If people want to copy what they did to some script, they would have numbers at the front which they would need to get rid of first. I we can not reference it then numbering is irrelevant. I do not think that referencing is easy thing to do. > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724433#comment-17724433 ] Stefan Miklosovic commented on CASSANDRA-15046: --- After all, I do not think that numbering is necessary. If people want to copy what they did to some script, they would have numbers at the front which they would need to get rid of first. I we can not reference it then numbering is irrelevant. I do not think that referencing is easy thing to do. > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[
https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724429#comment-17724429
]
Stefan Miklosovic edited comment on CASSANDRA-15046 at 5/19/23 10:14 PM:
-
[~bschoeni] thanks for the patch.
I tried it and what I would change is the order. Can not we reverse the output?
history command on Linux gives you the latest commands at the bottom. This
solution place them on top so the oldest is on the bottom. Also, Linux history
prints numbers like this:
{code}
...
2001 date
2002 ls
2003 df -h
{code}
I would focus on the reverse order first so we have the latest command on the
bottom and we do not need to scroll up to see them.
Numbering of lines would be cool too, but if it ends up being too complicated
let it be like it is. What I like about numbering is that people may reference
to it. For example in bash, if you do "history" and you do this in bash:
{code}
user$ !2003
{code}
It will execute "df -h" again.
This would be super cool to have because we do not need to copy it, we can just
reference what command we want to re-execute. Maybe that would be possible too?
I looked into numbering the lines and it does not seem to be overly complicated.
was (Author: smiklosovic):
[~bschoeni] thanks for the patch.
I tried it and what I would change is the order. Can not we reverse the output?
history command on Linux gives you the latest commands at the bottom. This
solution place them on top so the oldest is on the bottom. Also, Linux history
prints numbers like this:
{code}
...
2001 date
2002 ls
2003 df -h
{code}
I would focus on the reverse order first so we have the latest command on the
bottom and we do not need to scroll up to see them.
Numbering of lines would be cool too, but if it ends up being too complicated
let it be like it is.
> Add a "history" command to cqlsh. Perhaps "show history"?
> --
>
> Key: CASSANDRA-15046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15046
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Wes Peters
>Assignee: Brad Schoening
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I was trying to capture some create key space and create table commands from
> a running cqlsh, and found there was no equivalent to the '\s' history
> command in Postgres' psql shell. It's a great tool for figuring out what you
> were doing yesterday.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[
https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724429#comment-17724429
]
Stefan Miklosovic commented on CASSANDRA-15046:
---
[~bschoeni] thanks for the patch.
I tried it and what I would change is the order. Can not we reverse the output?
history command on Linux gives you the latest commands at the bottom. This
solution place them on top so the oldest is on the bottom. Also, Linux history
prints numbers like this:
{code}
...
2001 date
2002 ls
2003 df -h
{code}
I would focus on the reverse order first so we have the latest command on the
bottom and we do not need to scroll up to see them.
Numbering of lines would be cool too, but if it ends up being too complicated
let it be like it is.
> Add a "history" command to cqlsh. Perhaps "show history"?
> --
>
> Key: CASSANDRA-15046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15046
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Wes Peters
>Assignee: Brad Schoening
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I was trying to capture some create key space and create table commands from
> a running cqlsh, and found there was no equivalent to the '\s' history
> command in Postgres' psql shell. It's a great tool for figuring out what you
> were doing yesterday.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18453:
--
Status: Review In Progress (was: Patch Available)
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724422#comment-17724422
]
Bernardo Botella Corbi commented on CASSANDRA-18453:
[~smiklosovic] thanks to your suggestion I spotted a bunch of uses as well.
Just updated the PR
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724395#comment-17724395
]
Ningzi Zhan commented on CASSANDRA-18400:
-
[A new
commit|https://github.com/apache/cassandra/pull/2353/commits/c3cb55b1a4a17ceae6e6224f46e63e1cf9b3929c]
about NaN stuff has been submitted. !Screen Shot 2023-05-19 at
12.59.46.png|width=1066,height=80!
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png, Screen Shot
> 2023-05-19 at 12.59.46.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-18400:
Attachment: Screen Shot 2023-05-19 at 12.59.46.png
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png, Screen Shot
> 2023-05-19 at 12.59.46.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[ https://issues.apache.org/jira/browse/CASSANDRA-18400 ]
Ningzi Zhan deleted comment on CASSANDRA-18400:
-
was (Author: JIRAUSER299826):
[A new
commit|https://github.com/apache/cassandra/pull/2353/commits/c3cb55b1a4a17ceae6e6224f46e63e1cf9b3929c]
about NaN stuff has been submitted.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png, Screen Shot
> 2023-05-19 at 12.59.46.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10175) cassandra-stress should be tolerant when a remote node shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-10175: -- Resolution: Fixed Status: Resolved (was: Open) This seems to not happen anymore after CASSANDRA-12585 was introduced. I tried to turn off a node and JMX metrics just stopped to be collected. After I started that node, it just continued to report them. There was try-catch added here (1) which catches errors which happen here (2). (1) https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/report/StressMetrics.java#L237-L244 (2) https://github.com/apache/cassandra/blob/trunk/tools/stress/src/org/apache/cassandra/stress/util/JmxCollector.java#L112 > cassandra-stress should be tolerant when a remote node shutdown > > > Key: CASSANDRA-10175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10175 > Project: Cassandra > Issue Type: Improvement > Components: Tool/stress >Reporter: Alan Boudreault >Assignee: Stefan Miklosovic >Priority: Normal > Labels: stress > Fix For: 5.x > > > Currently, if we start a stress session with 3 nodes and shutdown one node, > stress will crash. It is caused by the JMX connection lost on the node, which > is use to collect some gc stats IIRC. > backtrace: https://gist.github.com/aboudreault/6cd82bb0acc681992414 > Stress should handle that jmx connection lost in a better way so the session > could continue. Ideally, it should try to *reconnect* to JMX if the node is > back online? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10175) cassandra-stress should be tolerant when a remote node shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-10175: -- Fix Version/s: (was: 5.x) > cassandra-stress should be tolerant when a remote node shutdown > > > Key: CASSANDRA-10175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10175 > Project: Cassandra > Issue Type: Improvement > Components: Tool/stress >Reporter: Alan Boudreault >Assignee: Stefan Miklosovic >Priority: Normal > Labels: stress > > Currently, if we start a stress session with 3 nodes and shutdown one node, > stress will crash. It is caused by the JMX connection lost on the node, which > is use to collect some gc stats IIRC. > backtrace: https://gist.github.com/aboudreault/6cd82bb0acc681992414 > Stress should handle that jmx connection lost in a better way so the session > could continue. Ideally, it should try to *reconnect* to JMX if the node is > back online? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724393#comment-17724393
]
Ningzi Zhan commented on CASSANDRA-18400:
-
[A new
commit|https://github.com/apache/cassandra/pull/2353/commits/c3cb55b1a4a17ceae6e6224f46e63e1cf9b3929c]
about NaN stuff has been submitted.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18400:
-
Status: Needs Committer (was: Review In Progress)
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724392#comment-17724392
]
Brandon Williams commented on CASSANDRA-18400:
--
4.0 is clean aside from CASSANDRA-18336, I created CASSANDRA-18539 for the
unrelated 4.1 failure, and trunk is clean. The NaN stuff can be handled on
commit. +1 from me.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18539) Fix flaky dtest: transient_replication_test.TestTransientReplicationRepairStreamEntireSSTable
[
https://issues.apache.org/jira/browse/CASSANDRA-18539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18539:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Feature/Transient Replication
Discovered By: User Report
Fix Version/s: 4.1.x
Severity: Normal
Status: Open (was: Triage Needed)
> Fix flaky dtest:
> transient_replication_test.TestTransientReplicationRepairStreamEntireSSTable
> -
>
> Key: CASSANDRA-18539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18539
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Transient Replication
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x
>
>
> As seen on
> https://app.circleci.com/pipelines/github/driftx/cassandra/1019/workflows/2c4502d8-52d2-4dc8-a871-ecad2a61645a/jobs/26149/tests
> :
> {noformat}
> failed on setup with "TypeError: 'list' object is not callable"
> self =
> object at 0x7fecd5e4bda0>
> fixture_dtest_setup =
> @pytest.fixture(scope='function', autouse=True)
> def setup_cluster(self, fixture_dtest_setup):
> > self.tokens = self.tokens()
> E TypeError: 'list' object is not callable
> transient_replication_test.py:206: TypeError
> {noformat}
> Looking at the code, I'm not sure how this has been passing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18539) Fix flaky dtest: transient_replication_test.TestTransientReplicationRepairStreamEntireSSTable
[
https://issues.apache.org/jira/browse/CASSANDRA-18539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18539:
-
Summary: Fix flaky dtest:
transient_replication_test.TestTransientReplicationRepairStreamEntireSSTable
(was: Fix flaky dtest:
Fix flaky dtest:
> transient_replication_test.TestTransientReplicationRepairStreamEntireSSTable
> -
>
> Key: CASSANDRA-18539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18539
> Project: Cassandra
> Issue Type: Bug
>Reporter: Brandon Williams
>Priority: Normal
>
> As seen on
> https://app.circleci.com/pipelines/github/driftx/cassandra/1019/workflows/2c4502d8-52d2-4dc8-a871-ecad2a61645a/jobs/26149/tests
> :
> {noformat}
> failed on setup with "TypeError: 'list' object is not callable"
> self =
> object at 0x7fecd5e4bda0>
> fixture_dtest_setup =
> @pytest.fixture(scope='function', autouse=True)
> def setup_cluster(self, fixture_dtest_setup):
> > self.tokens = self.tokens()
> E TypeError: 'list' object is not callable
> transient_replication_test.py:206: TypeError
> {noformat}
> Looking at the code, I'm not sure how this has been passing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18539) Fix flaky dtest:
Brandon Williams created CASSANDRA-18539:
Summary: Fix flaky dtest:
https://issues.apache.org/jira/browse/CASSANDRA-18539
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
As seen on
https://app.circleci.com/pipelines/github/driftx/cassandra/1019/workflows/2c4502d8-52d2-4dc8-a871-ecad2a61645a/jobs/26149/tests
:
{noformat}
failed on setup with "TypeError: 'list' object is not callable"
self =
fixture_dtest_setup =
@pytest.fixture(scope='function', autouse=True)
def setup_cluster(self, fixture_dtest_setup):
> self.tokens = self.tokens()
E TypeError: 'list' object is not callable
transient_replication_test.py:206: TypeError
{noformat}
Looking at the code, I'm not sure how this has been passing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18529) Remove legacy thrift options from cassandra-stress
[ https://issues.apache.org/jira/browse/CASSANDRA-18529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-18529: --- Change Category: Code Clarity Complexity: Low Hanging Fruit Component/s: Tool/stress Fix Version/s: 5.0 Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Remove legacy thrift options from cassandra-stress > -- > > Key: CASSANDRA-18529 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18529 > Project: Cassandra > Issue Type: Improvement > Components: Tool/stress >Reporter: Brad Schoening >Priority: Low > Fix For: 5.0 > > > The cassandra-stress *mode* option allows specifying options for native > protocol and cql3, but these don't seem useful as there would seem to be no > other valid options now that cql3 is the standard and thrift no longer > supported. > -mode "native cql3 user=cassandra password=xx" > While user and password, mode native and cqlsh3 could be removed. Perhaps > change the arguments for user and password to match those used with cqlsh > would align the tools. > I.e., > cassandra-stress -u cassandra -p x > Also, the readme.txt in tools/stress states "cassandra-stress supports > benchmarking any Cassandra cluster of version 2.0+" but maybe should be > updated to a supported Cassandra version, i.e., 3.11.x. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17433) Revise use of pytz in Python >= 3.9
[ https://issues.apache.org/jira/browse/CASSANDRA-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17433: --- Description: PEP 615 – Support for the IANA Time Zone Database in the Standard Library class ZoneInfo PEP 615 (Python 3.9) has obsoleted the 3rd party Olsen tz library 'pytz' with support for the IANA Time Zone Database. The code which imports this in cqlshmain.py and tests in [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] should be updated accordingly. This can be done with: if sys.version_info < (3,9): try: import pytz ... was: PEP 615 – Support for the IANA Time Zone Database in the Standard Library class ZoneInfo PEP 615 (Python 3.9) has obsoleted the 3rd party library pytz with support for the Olsen tz library which previously was needed for the Olsen tz database. The code which imports this in cqlshmain.py and tests in [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] should be updated accordingly. This can be done with: if sys.version_info < (3,9): try: import pytz ... > Revise use of pytz in Python >= 3.9 > > > Key: CASSANDRA-17433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17433 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Low > Fix For: 5.x > > > PEP 615 – Support for the IANA Time Zone Database in the Standard Library > class ZoneInfo > PEP 615 (Python 3.9) has obsoleted the 3rd party Olsen tz library 'pytz' with > support for the IANA Time Zone Database. The code which imports this in > cqlshmain.py and tests in > [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] > should be updated accordingly. > This can be done with: > if sys.version_info < (3,9): > try: > import pytz > ... -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17433) Revise use of pytz in Python >= 3.9
[ https://issues.apache.org/jira/browse/CASSANDRA-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17433: - Fix Version/s: 5.x (was: 5.0) > Revise use of pytz in Python >= 3.9 > > > Key: CASSANDRA-17433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17433 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Low > Fix For: 5.x > > > PEP 615 – Support for the IANA Time Zone Database in the Standard Library > class ZoneInfo > PEP 615 (Python 3.9) has obsoleted the 3rd party library pytz with support > for the Olsen tz library which previously was needed for the Olsen tz > database. The code which imports this in cqlshmain.py and tests in > [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] > should be updated accordingly. > This can be done with: > if sys.version_info < (3,9): > try: > import pytz > ... -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17433) Revise use of pytz in Python >= 3.9
[ https://issues.apache.org/jira/browse/CASSANDRA-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17433: --- Change Category: Code Clarity Complexity: Low Hanging Fruit Component/s: CQL/Interpreter Fix Version/s: 5.0 Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Revise use of pytz in Python >= 3.9 > > > Key: CASSANDRA-17433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17433 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Low > Fix For: 5.0 > > > PEP 615 – Support for the IANA Time Zone Database in the Standard Library > class ZoneInfo > PEP 615 (Python 3.9) has obsoleted the 3rd party library pytz with support > for the Olsen tz library which previously was needed for the Olsen tz > database. The code which imports this in cqlshmain.py and tests in > [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] > should be updated accordingly. > This can be done with: > if sys.version_info < (3,9): > try: > import pytz > ... -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724386#comment-17724386
]
Brad Schoening commented on CASSANDRA-18400:
+1
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724383#comment-17724383
]
Bernardo Botella Corbi commented on CASSANDRA-18453:
I like the suggestion [~smiklosovic]. Will take a look into it.
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724379#comment-17724379
]
Stefan Miklosovic edited comment on CASSANDRA-18453 at 5/19/23 6:55 PM:
You may say that ".clearValue();" is illegal to use in tests unless it is
explicitly allowed (there happens to be a commentary for this at the end of the
line). You need to look into checkstyle_test.xml to see it in action.
was (Author: smiklosovic):
You may say that "clearValue();" is illegal to use in tests unless it is
explicitly allowed (there happens to be a commentary for this at the end of the
line). You need to look into checkstyle_test.xml to see it in action.
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724379#comment-17724379
]
Stefan Miklosovic commented on CASSANDRA-18453:
---
You may say that "clearValue();" is illegal to use in tests unless it is
explicitly allowed (there happens to be a commentary for this at the end of the
line). You need to look into checkstyle_test.xml to see it in action.
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724377#comment-17724377
]
Stefan Miklosovic commented on CASSANDRA-18453:
---
[~bernardo.botella] would it be possible to update our checkstyle_test.xml so
the code you are fixing will not be valid anymore so people are not using this
"wrongly" ever again? We will probably need to be smart about this. Definitely
it is worth to look into this. It is one thing to clean it all up but the next
level is to disallow that to ever happen again.
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-15046: --- Test and Documentation Plan: Original Patch PR: [https://github.com/apache/cassandra/pull/1866/files] [NEW - NEEDS REVIEW] 09/22/22: documentation patch -[https://github.com/apache/cassandra/commit/31f9a566bb70368dbffddeb672196355efe7ebb0]- Unit tests to be implemented: 1. check "history" command outputs correct length of results 2. check "history" command outputs correct contents & order The current patch implements the feature in its minimally viable form. Here's some of my ideas for improvement to current patch: # allow an input argument to control how many commands will be listed. # showing the timestamp of when each command is executed. # showing whether each command is valid/successfully executed, OR, showing only the successfully executed commands. 19 May 2023 New Patch [https://github.com/apache/cassandra/pull/2354] This patch is an update of the original PR create by Yundi Chen. It slightly revises the HISTORY command syntax by adding a optional argument for the number of lines to display. A few implementation notes: * The parser ensures that the value of is a , i.e., a non-negative integer. I tried creating a type, but that caused numerous issues with unit tests. This is implemented similar to 'paging', which specifies also. Zero and less than 10 might not be practical values, but the parsing framework isn't setup to restrict them at the moment. Also, Bash 'history' accepts '1' as an arg, so there are related implementations which don't restrict the range of integer values. * The number of rows to display is a session setting not a permanent one. Typically, a user has a known range of history you wish to look through, such as recent queries, or much older queries (larger value of n). You might want to see the last 10 lines for something you just ran a few minutes ago, or 1000 lines for something you ran last week. was: Original Patch PR: [https://github.com/apache/cassandra/pull/1866/files] [NEW - NEEDS REVIEW] 09/22/22: documentation patch -[https://github.com/apache/cassandra/commit/31f9a566bb70368dbffddeb672196355efe7ebb0]- Unit tests to be implemented: 1. check "history" command outputs correct length of results 2. check "history" command outputs correct contents & order The current patch implements the feature in its minimally viable form. Here's some of my ideas for improvement to current patch: # allow an input argument to control how many commands will be listed. # showing the timestamp of when each command is executed. # showing whether each command is valid/successfully executed, OR, showing only the successfully executed commands. 19 May 2023 New Patch [https://github.com/apache/cassandra/pull/2354] This patch is an update of the original PR create by Yundi Chen. It slightly revises the HISTORY command syntax by adding a optional argument for the number of lines to display. A few implementation notes: * The parser ensures that the value of is a , i.e., a non-negative integer. I tried creating a type, but that caused numerous issues with unit tests. This is implemented similar to 'paging', which specifies also. * The number of rows to display is a session setting not a permanent one. Typically, a user has a known range of history you wish to look through, such as recent queries, or much older queries (larger value of n). You might want to see the last 10 lines for something you just ran a few minutes ago, or 1000 lines for something you ran last week. > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-15046: --- Authors: Brad Schoening, Yundi Chen (was: Brad Schoening) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-15046: --- Test and Documentation Plan: Original Patch PR: [https://github.com/apache/cassandra/pull/1866/files] [NEW - NEEDS REVIEW] 09/22/22: documentation patch [https://github.com/apache/cassandra/commit/31f9a566bb70368dbffddeb672196355efe7ebb0] Unit tests to be implemented: 1. check "history" command outputs correct length of results 2. check "history" command outputs correct contents & order The current patch implements the feature in its minimally viable form. Here's some of my ideas for improvement to current patch: # allow an input argument to control how many commands will be listed. # showing the timestamp of when each command is executed. # showing whether each command is valid/successfully executed, OR, showing only the successfully executed commands. 19 May 2023 New Patch [https://github.com/apache/cassandra/pull/2354] This patch is an update of the original PR create by Yundi Chen. It slightly revises the HISTORY command syntax by adding a optional argument for the number of lines to display. A few implementation notes: * The parser ensures that the value of is a , i.e., a non-negative integer. I tried creating a type, but that caused numerous issues with unit tests. This is implemented similar to 'paging', which specifies also. * The number of rows to display is a session setting not a permanent one. Typically, a user has a known range of history you wish to look through, such as recent queries, or much older queries (larger value of n). You might want to see the last 10 lines for something you just ran a few minutes ago, or 1000 lines for something you ran last week. was: Original Patch PR: [https://github.com/apache/cassandra/pull/1866/files] [NEW - NEEDS REVIEW] 09/22/22: documentation patch [https://github.com/apache/cassandra/commit/31f9a566bb70368dbffddeb672196355efe7ebb0] Unit tests to be implemented: 1. check "history" command outputs correct length of results 2. check "history" command outputs correct contents & order The current patch implements the feature in its minimally viable form. Here's some of my ideas for improvement to current patch: # allow an input argument to control how many commands will be listed. # showing the timestamp of when each command is executed. # showing whether each command is valid/successfully executed, OR, showing only the successfully executed commands. Thoughts? Status: Patch Available (was: In Progress) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-15046: --- Test and Documentation Plan: Original Patch PR: [https://github.com/apache/cassandra/pull/1866/files] [NEW - NEEDS REVIEW] 09/22/22: documentation patch -[https://github.com/apache/cassandra/commit/31f9a566bb70368dbffddeb672196355efe7ebb0]- Unit tests to be implemented: 1. check "history" command outputs correct length of results 2. check "history" command outputs correct contents & order The current patch implements the feature in its minimally viable form. Here's some of my ideas for improvement to current patch: # allow an input argument to control how many commands will be listed. # showing the timestamp of when each command is executed. # showing whether each command is valid/successfully executed, OR, showing only the successfully executed commands. 19 May 2023 New Patch [https://github.com/apache/cassandra/pull/2354] This patch is an update of the original PR create by Yundi Chen. It slightly revises the HISTORY command syntax by adding a optional argument for the number of lines to display. A few implementation notes: * The parser ensures that the value of is a , i.e., a non-negative integer. I tried creating a type, but that caused numerous issues with unit tests. This is implemented similar to 'paging', which specifies also. * The number of rows to display is a session setting not a permanent one. Typically, a user has a known range of history you wish to look through, such as recent queries, or much older queries (larger value of n). You might want to see the last 10 lines for something you just ran a few minutes ago, or 1000 lines for something you ran last week. was: Original Patch PR: [https://github.com/apache/cassandra/pull/1866/files] [NEW - NEEDS REVIEW] 09/22/22: documentation patch [https://github.com/apache/cassandra/commit/31f9a566bb70368dbffddeb672196355efe7ebb0] Unit tests to be implemented: 1. check "history" command outputs correct length of results 2. check "history" command outputs correct contents & order The current patch implements the feature in its minimally viable form. Here's some of my ideas for improvement to current patch: # allow an input argument to control how many commands will be listed. # showing the timestamp of when each command is executed. # showing whether each command is valid/successfully executed, OR, showing only the successfully executed commands. 19 May 2023 New Patch [https://github.com/apache/cassandra/pull/2354] This patch is an update of the original PR create by Yundi Chen. It slightly revises the HISTORY command syntax by adding a optional argument for the number of lines to display. A few implementation notes: * The parser ensures that the value of is a , i.e., a non-negative integer. I tried creating a type, but that caused numerous issues with unit tests. This is implemented similar to 'paging', which specifies also. * The number of rows to display is a session setting not a permanent one. Typically, a user has a known range of history you wish to look through, such as recent queries, or much older queries (larger value of n). You might want to see the last 10 lines for something you just ran a few minutes ago, or 1000 lines for something you ran last week. > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724372#comment-17724372
]
Bernardo Botella Corbi commented on CASSANDRA-18453:
Updated the PR with missing properties
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724351#comment-17724351
]
Brandon Williams edited comment on CASSANDRA-18400 at 5/19/23 6:42 PM:
---
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18400-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1020/workflows/bb2bea4a-6db3-4fb9-a573-144d69e2beb7],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1020/workflows/c65efde2-0707-4f78-95af-60efdb97db67]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18400-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1019/workflows/2c4502d8-52d2-4dc8-a871-ecad2a61645a],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1019/workflows/84560c95-fc53-48b1-ab09-63357d6f943e]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18400-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1021/workflows/47a9d034-9c9a-4c51-a33e-deb1eaa26a91],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1021/workflows/1d58c68c-e978-4481-88b6-b8d31666bc28]|
was (Author: brandon.williams):
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18400-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1018/workflows/6b9bfc18-e5a4-4f9d-8c2f-31a989151d93],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1018/workflows/46c210bd-df56-4940-a49b-f61daad94b29]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18400-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1017/workflows/b694a288-73bb-4594-8d9d-b91a15ea9b05],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1017/workflows/61e1552f-c386-43b5-9383-56f359a869d1]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18400-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1016/workflows/492f6195-0e6d-4ef3-9083-83183b30f252],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1016/workflows/2a597915-f0ce-4f4b-9515-b119b43a8116]|
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18025: -- Fix Version/s: 3.0.30 (was: 3.0.29) > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.10, 4.1.2, 5.0, 3.11.16, 3.0.30 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18025: -- Fix Version/s: 3.0.29 4.0.10 4.1.2 3.11.16 (was: 3.0.x) (was: 3.11.x) (was: 4.0.x) (was: 4.1.x) Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/b828f7ea1b735586da388ddfee17f26685e20cef Resolution: Fixed Status: Resolved (was: Ready to Commit) > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.29, 4.0.10, 4.1.2, 5.0, 3.11.16 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724360#comment-17724360
]
Ningzi Zhan commented on CASSANDRA-18400:
-
I restored the NaN of the hit rate in the [new
commit|https://github.com/apache/cassandra/pull/2353/files#diff-6f350ce37d440d2c826232c1985a3ef63d87d9c9b4a208f6a4ab5227cd55ac82].
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit edd35badaf6e25726b0e46a4cddf9cfe42f0c11a Merge: 0352dbe920 f416a94125 Author: Stefan Miklosovic AuthorDate: Fri May 19 15:16:27 2023 +0200 Merge branch 'cassandra-4.1' into trunk CHANGES.txt| 1 + .../cassandra/stress/settings/StressSettings.java | 3 +-- .../cassandra/stress/util/JavaDriverClient.java| 27 -- 3 files changed, 22 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (b8e21fb80a -> b828f7ea1b)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from b8e21fb80a Validate the existence of a datacenter in nodetool rebuild add b828f7ea1b Pass down all contact points to driver for cassandra-stress No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/stress/settings/StressSettings.java | 3 +-- .../cassandra/stress/util/JavaDriverClient.java| 24 -- 3 files changed, 20 insertions(+), 8 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (0352dbe920 -> edd35badaf)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 0352dbe920 Merge branch 'cassandra-4.1' into trunk add b828f7ea1b Pass down all contact points to driver for cassandra-stress add e1e88e5bc4 Merge branch 'cassandra-3.0' into cassandra-3.11 add dc6ad3f6b1 Merge branch 'cassandra-3.11' into cassandra-4.0 add f416a94125 Merge branch 'cassandra-4.0' into cassandra-4.1 new edd35badaf Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../cassandra/stress/settings/StressSettings.java | 3 +-- .../cassandra/stress/util/JavaDriverClient.java| 27 -- 3 files changed, 22 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (ff820290dd -> dc6ad3f6b1)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from ff820290dd Merge branch 'cassandra-3.11' into cassandra-4.0 add b828f7ea1b Pass down all contact points to driver for cassandra-stress add e1e88e5bc4 Merge branch 'cassandra-3.0' into cassandra-3.11 add dc6ad3f6b1 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/stress/settings/StressSettings.java | 3 +-- .../cassandra/stress/util/JavaDriverClient.java| 27 -- 3 files changed, 22 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (3ca94d65d3 -> e1e88e5bc4)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 3ca94d65d3 Remove unnecessary String.format invocation in QueryProcessor when getting a prepared statement from cache add b828f7ea1b Pass down all contact points to driver for cassandra-stress add e1e88e5bc4 Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/stress/settings/StressSettings.java | 3 +-- .../cassandra/stress/util/JavaDriverClient.java| 24 -- 3 files changed, 20 insertions(+), 8 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (621faf7740 -> f416a94125)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 621faf7740 Merge branch 'cassandra-4.0' into cassandra-4.1 add b828f7ea1b Pass down all contact points to driver for cassandra-stress add e1e88e5bc4 Merge branch 'cassandra-3.0' into cassandra-3.11 add dc6ad3f6b1 Merge branch 'cassandra-3.11' into cassandra-4.0 add f416a94125 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/stress/settings/StressSettings.java | 3 +-- .../cassandra/stress/util/JavaDriverClient.java| 27 -- 3 files changed, 22 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16222) CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-16222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724358#comment-17724358 ] Yifan Cai commented on CASSANDRA-16222: --- I also went over the patch in [https://github.com/frankgh/cassandra-analytics], and submitted a patch with feedbacks directly to the repo. The code example included in the repo runs as expected. I am +1 on the cassandra-analytics patch too. > CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics > > > Key: CASSANDRA-16222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16222 > Project: Cassandra > Issue Type: New Feature > Components: Tool/external >Reporter: James Berragan >Assignee: Francisco Guerrero >Priority: Normal > Fix For: NA > > Attachments: sparkbulkreader.patch > > > *Description:* > This ticket introduces the Spark-Cassandra Bulk Analytics library and > associated Cassandra Sidecar endpoints. > > Please see > [CEP-28|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics] > for more details, motivation, and available source code links. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (d0534a4c5 -> 3e25a07b1)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard d0534a4c5 generate docs for 16320f1d new 3e25a07b1 generate docs for 16320f1d This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (d0534a4c5) \ N -- N -- N refs/heads/asf-staging (3e25a07b1) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724351#comment-17724351
]
Brandon Williams commented on CASSANDRA-18400:
--
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18400-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1018/workflows/6b9bfc18-e5a4-4f9d-8c2f-31a989151d93],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1018/workflows/46c210bd-df56-4940-a49b-f61daad94b29]|
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18400-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1017/workflows/b694a288-73bb-4594-8d9d-b91a15ea9b05],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1017/workflows/61e1552f-c386-43b5-9383-56f359a869d1]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18400-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1016/workflows/492f6195-0e6d-4ef3-9083-83183b30f252],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1016/workflows/2a597915-f0ce-4f4b-9515-b119b43a8116]|
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724349#comment-17724349
]
Brandon Williams commented on CASSANDRA-18400:
--
Nevermind, this applies cleanly to 4.0 and 4.1, I'll get CI up.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18400:
-
Status: Review In Progress (was: Changes Suggested)
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-15046: --- Status: In Progress (was: Changes Suggested) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18400:
-
Reviewers: Brandon Williams
Status: Review In Progress (was: Patch Available)
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18400:
-
Status: Changes Suggested (was: Review In Progress)
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724346#comment-17724346
]
Brandon Williams commented on CASSANDRA-18400:
--
NaN was correct and what we use everywhere else, we should probably keep that.
Otherwise this looks good to me. [~qannap] can you also make PRs for 4.0 and
4.1 and then we'll run CI on them?
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18037) Use snake case for the names of CQL native functions
[
https://issues.apache.org/jira/browse/CASSANDRA-18037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724345#comment-17724345
]
Brad Schoening commented on CASSANDRA-18037:
[~adelapena] I'm seeing new errors in the pytest about missing blob_as_int,
could this the related?
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
* short test summary info
*
ERROR
cqlshlib/test/test_cqlsh_completion.py::{*}TestCqlshCompletion::test_complete_command_words{*}
- cassandra.InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unknown function blob_as_int...
ERROR
cqlshlib/test/test_cqlsh_completion.py::{*}TestCqlshCompletion::test_complete_in_alter_keyspace{*}
- cassandra.InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unknown function blob_as_int...
ERROR
cqlshlib/test/test_cqlsh_completion.py::{*}TestCqlshCompletion::test_complete_in_alter_role{*}
- cassandra.InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unknown function blob_as_int...
ERROR
cqlshlib/test/test_cqlsh_completion.py::{*}TestCqlshCompletion::test_complete_in_alter_table{*}
- cassandra.InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unknown function blob_as_int...
ERROR
cqlshlib/test/test_cqlsh_completion.py::{*}TestCqlshCompletion::test_complete_in_alter_type{*}
- cassandra.InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unknown function blob_as_int...
> Use snake case for the names of CQL native functions
>
>
> Key: CASSANDRA-18037
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18037
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Most native functions are named all lower case, without underscore nor hyphen
> to separate words. That's the case, for example, of "intasblob" or
> "blobasint".
> We also have some functions using camel case, as in "castAsInt" or
> "castAsTimestamp". Note that the came cased names require quoting due to
> CQL's case insensitivity.
> Differently to CQL native functions, system keyspaces, tables and columns
> consistently use snake case. For example, we have "system_schema",
> "dropped_columns", "default_time_to_live".
> As discussed in [this
> thread|https://lists.apache.org/thread/k9ml1k4fg6o7mfby1nr3y0mnq9r90dym], we
> should adopt snake_case for CQL native function names. Also we should provide
> aliases for the current function names, so we don't break compatibility.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-18400:
Test and Documentation Plan: run CI (was: [Patch is
here|https://github.com/apache/cassandra/pull/2353])
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-18400:
Test and Documentation Plan: [Patch is
here|https://github.com/apache/cassandra/pull/2353]
Status: Patch Available (was: In Progress)
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724343#comment-17724343
]
Ningzi Zhan commented on CASSANDRA-18400:
-
1. For network cache info:
{quote}Network Cache should report a line similar to the above:
Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ? requests, ?
recent hit rate
{quote}
Since the Network cache is not precisely a cache, it is more like a pool of
buffers. Only reporting capacity and size should be enough. So the network
cache info looks like this.
{quote}Network Cache : size ? MiB, capacity ? MiB
{quote}
The capacity is the network cache total threshold, which corresponds to
{_}NETWORKING_MEMORY_USAGE_THRESHOLD{_}, and the size is the size of allocated
pooled buffers.
2. The NaN hit rate in the row and the counter cache is caused by dividing by
zero, but the zero comes from {*}_zero requests_{*}. In this case, I changed
the hit rate to 0 when the hit rate was NaN. I am not sure if it is valid to do
that.
After the patch, the final Nodetool info will look like this:
!Screen Shot 2023-05-18 at 13.57.45.png|width=1094,height=83!
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[ https://issues.apache.org/jira/browse/CASSANDRA-18400 ]
Ningzi Zhan deleted comment on CASSANDRA-18400:
-
was (Author: JIRAUSER299826):
1. For network cache info:
{quote}Network Cache should report a line similar to the above:
Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ? requests, ?
recent hit rate
{quote}
Since the Network cache is not precisely a cache, it is more like a pool of
buffers. Only reporting capacity and size should be enough. So the network
cache info looks like this.
{quote}Network Cache : size ? MiB, capacity ? MiB
{quote}
The capacity is the network cache total threshold, which corresponds to
{_}NETWORKING_MEMORY_USAGE_THRESHOLD{_}, and the size is the size of allocated
pooled buffers.
2. The NaN hit rate in the row and the counter cache is caused by dividing by
zero, but the zero comes from {*}_zero requests_{*}. In this case, I changed
the hit rate to 0 when the hit rate was NaN. I am not sure if it is valid to do
that.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan updated CASSANDRA-18400:
Attachment: Screen Shot 2023-05-18 at 13.57.45.png
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Attachments: Screen Shot 2023-05-18 at 13.57.45.png
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18400) Nodetool info should report on the new networking cache
[
https://issues.apache.org/jira/browse/CASSANDRA-18400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724342#comment-17724342
]
Ningzi Zhan commented on CASSANDRA-18400:
-
1. For network cache info:
{quote}Network Cache should report a line similar to the above:
Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ? requests, ?
recent hit rate
{quote}
Since the Network cache is not precisely a cache, it is more like a pool of
buffers. Only reporting capacity and size should be enough. So the network
cache info looks like this.
{quote}Network Cache : size ? MiB, capacity ? MiB
{quote}
The capacity is the network cache total threshold, which corresponds to
{_}NETWORKING_MEMORY_USAGE_THRESHOLD{_}, and the size is the size of allocated
pooled buffers.
2. The NaN hit rate in the row and the counter cache is caused by dividing by
zero, but the zero comes from {*}_zero requests_{*}. In this case, I changed
the hit rate to 0 when the hit rate was NaN. I am not sure if it is valid to do
that.
> Nodetool info should report on the new networking cache
> ---
>
> Key: CASSANDRA-18400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18400
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Ningzi Zhan
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> CASSANDRA-15229 separated the chunk and network cache, creating a new
> network_cache_size parameter.
> However, *nodetool info* does not report the in-use size of this cache or a
> hit ratio as it does for key, row, counter and chunk cache.
> {quote}Exceptions : 4
> Key Cache : entries 2852, size 297.59 KiB, capacity 100 MiB, 2406561 hits,
> 2409424 requests, 0.999 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests,
> NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests,
> NaN recent hit rate, 7200 save period in seconds
> Chunk Cache : entries 1118, size 55.02 MiB, capacity 992 MiB, 4695794 misses,
> 7179421 requests, 0.346 recent hit rate, 24.145 microseconds miss latency
> Percent Repaired : 0.0%
> {quote}
> However, when its full, it will be logged:
> {quote}[INFO ] [epollEventLoopGroup-5-12] cluster_id=1 ip_address=127.1.1.1
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB
> {quote}
> It should report a line similar to the above:
> {quote}Network Cache : entries ?, size ? MiB, capacity ? MiB, ? misses, ?
> requests, ? recent hit rate
> {quote}
> Also, not sure why the above show NaN for row and counter cache, is there is
> a divide by zero error when the entries are zero?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18538: - Resolution: Not A Problem Status: Resolved (was: Open) > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18538: - Status: Open (was: Patch Available) > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724340#comment-17724340 ] Brandon Williams commented on CASSANDRA-18538: -- I confirmed via packet analysis with fql and stress that nothing is phoning home, closing this ticket. > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724337#comment-17724337 ] Ariel Weisberg edited comment on CASSANDRA-18538 at 5/19/23 4:46 PM: - Another way to disable it that works even if someone changes Cassandra's configuration is to put it in a static initializer block. So for example maybe in `DatabaseDescriptor`, `FullQueryLogTool`, `BinLog`, and `AuditLogViewer`. This is still somewhat problematic because a lot of tests will also create queues and there is no guarantee we hit the static initializer block. Also to record context, It looks like we actually never released a version that phones home because https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml#LL708C1-L709C1 excludes the dependency for chronicle-analytics It was added in https://github.com/apache/cassandra/commit/cf39d031279620eb5684ad384dff72f7325104cd#diff-766797f233c18114f9499750c[…]ea50283850619c01bd173132021R585 before 4.0 was released. So we have never released with chronicle phoning home. I only noticed that it has this feature because I was upgrading and changing how we included the dependency and that brought in the analytics library. was (Author: aweisberg): Another way to disable it that works even if someone changes Cassandra's configuration is to put it in a static initializer block. So for example maybe in `DatabaseDescriptor`, `FullQueryLogTool`, `BinLog`, and `AuditLogViewer`. Also to record context, It looks like we actually never released a version that phones home because https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml#LL708C1-L709C1 excludes the dependency for chronicle-analytics It was added in https://github.com/apache/cassandra/commit/cf39d031279620eb5684ad384dff72f7325104cd#diff-766797f233c18114f9499750c[…]ea50283850619c01bd173132021R585 before 4.0 was released. So we have never released with chronicle phoning home. I only noticed that it has this feature because I was upgrading and changing how we included the dependency and that brought in the analytics library. > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724337#comment-17724337 ] Ariel Weisberg commented on CASSANDRA-18538: Another way to disable it that works even if someone changes Cassandra's configuration is to put it in a static initializer block. So for example maybe in `DatabaseDescriptor`, `FullQueryLogTool`, `BinLog`, and `AuditLogViewer`. Also to record context, It looks like we actually never released a version that phones home because https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml#LL708C1-L709C1 excludes the dependency for chronicle-analytics It was added in https://github.com/apache/cassandra/commit/cf39d031279620eb5684ad384dff72f7325104cd#diff-766797f233c18114f9499750c[…]ea50283850619c01bd173132021R585 before 4.0 was released. So we have never released with chronicle phoning home. I only noticed that it has this feature because I was upgrading and changing how we included the dependency and that brought in the analytics library. > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18538: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724336#comment-17724336 ] Brandon Williams commented on CASSANDRA-18538: -- There are a couple choices of where to put this: jvm-server.options or cassandra-env.sh. We want to reach as many installations as we can, but both files are config files, so packaging won't overwrite them if they are modified, and it seems like modification of either is somewhat likely. I think jvm-server.options is probably less likely to be modified (because we have jvm8/11-server.options) than cassandra-env.sh, but that's just my gut feeling. ||Branch||CI|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18538-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1014/workflows/5cf383f7-5d2f-4ad5-8b31-703f813f4fc0], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1014/workflows/52d05569-1d44-4974-b4ce-a0509a874b9f]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18538-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1015/workflows/15f708e4-64ff-4ccb-be50-6a1c73eeb05a], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1015/workflows/59461361-fc1e-43b8-bd90-f9b297844a23]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18538-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1013/workflows/f29cfd7f-d7f1-4fc6-af22-8b18eaec0b1d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1013/workflows/56cd3f0c-d82d-4f72-bfc5-3b0154372f10]| I'll start CI if there is this approach is agreed. > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724336#comment-17724336 ] Brandon Williams edited comment on CASSANDRA-18538 at 5/19/23 4:31 PM: --- There are a couple choices of where to put this: jvm-server.options or cassandra-env.sh. We want to reach as many installations as we can, but both files are config files, so packaging won't overwrite them if they are modified, and it seems like modification of either is somewhat likely. I think jvm-server.options is probably less likely to be modified (because we have jvm8/11-server.options) than cassandra-env.sh, but that's just my gut feeling. ||Branch||CI|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18538-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1014/workflows/5cf383f7-5d2f-4ad5-8b31-703f813f4fc0], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1014/workflows/52d05569-1d44-4974-b4ce-a0509a874b9f]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18538-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1015/workflows/15f708e4-64ff-4ccb-be50-6a1c73eeb05a], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1015/workflows/59461361-fc1e-43b8-bd90-f9b297844a23]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18538-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1013/workflows/f29cfd7f-d7f1-4fc6-af22-8b18eaec0b1d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1013/workflows/56cd3f0c-d82d-4f72-bfc5-3b0154372f10]| I'll start CI if this approach is agreed. was (Author: brandon.williams): There are a couple choices of where to put this: jvm-server.options or cassandra-env.sh. We want to reach as many installations as we can, but both files are config files, so packaging won't overwrite them if they are modified, and it seems like modification of either is somewhat likely. I think jvm-server.options is probably less likely to be modified (because we have jvm8/11-server.options) than cassandra-env.sh, but that's just my gut feeling. ||Branch||CI|| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18538-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1014/workflows/5cf383f7-5d2f-4ad5-8b31-703f813f4fc0], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1014/workflows/52d05569-1d44-4974-b4ce-a0509a874b9f]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18538-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1015/workflows/15f708e4-64ff-4ccb-be50-6a1c73eeb05a], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1015/workflows/59461361-fc1e-43b8-bd90-f9b297844a23]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18538-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1013/workflows/f29cfd7f-d7f1-4fc6-af22-8b18eaec0b1d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1013/workflows/56cd3f0c-d82d-4f72-bfc5-3b0154372f10]| I'll start CI if there is this approach is agreed. > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18538: - Bug Category: Parent values: Security(12985)Level 1 values: Information Leakage(12999) Complexity: Normal Component/s: Dependencies Discovered By: User Report Fix Version/s: 4.0.x 4.1.x 5.x Severity: Normal Status: Open (was: Triage Needed) > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18538) Disable chronicle analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-18538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-18538: Assignee: Brandon Williams > Disable chronicle analytics > --- > > Key: CASSANDRA-18538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > At least chronicle-queue phones home to google analytics: > https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc > but we can disable all chronicle analytics with a single flag: > -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18538) Disable chronicle analytics
Brandon Williams created CASSANDRA-18538: Summary: Disable chronicle analytics Key: CASSANDRA-18538 URL: https://issues.apache.org/jira/browse/CASSANDRA-18538 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams At least chronicle-queue phones home to google analytics: https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.116/DISCLAIMER.adoc but we can disable all chronicle analytics with a single flag: -Dchronicle.analytics.disable=true -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724330#comment-17724330
]
Bernardo Botella Corbi commented on CASSANDRA-18453:
Patch posted
||PR||Circle 8||Circle 11||
|[trunk|https://github.com/apache/cassandra/pull/2352]|[UTests|https://app.circleci.com/pipelines/github/bbotella/cassandra/76/workflows/cfd20f83-a258-479b-b033-99cd15f1961f/jobs/577]|[Utests|https://app.circleci.com/pipelines/github/bbotella/cassandra/76/workflows/5b7d88ea-42a5-40aa-9790-507fc6fc3576/jobs/576]|
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernardo Botella Corbi updated CASSANDRA-18453:
---
Test and Documentation Plan: Added the patch
Status: Patch Available (was: In Progress)
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15598) cassandra-stress in user profile mode fails on handling set> columns
[ https://issues.apache.org/jira/browse/CASSANDRA-15598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724314#comment-17724314 ] Dmitry Kropachev commented on CASSANDRA-15598: -- [~smiklosovic] , it was dangling for 2 years, not sure it is still actual > cassandra-stress in user profile mode fails on handling set> columns > - > > Key: CASSANDRA-15598 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15598 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Dmitry Kropachev >Priority: Normal > Fix For: 5.x > > Attachments: cs_no_mv_basic_profile.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Reason: > c-s reads metadata from database, and build column generator from it. > But this logic is build in a way so that it does not support generator > recursion, which is necessary to support embedded collections. > Fix: > This fix is simple exclude this type of columns from being processed. > Steps to reproduce: > # docker run -d --name cassandra cassandra:latest > # cassandra-stress user profile=cs_no_mv_basic_profile.yaml ops'(insert=1)' > cl=ONE n=20 -pop seq=1..1000 -port jmx=6868 -mode cql3 native -rate > threads=2 -node 172.17.0.2 > # docker exec -ti cassandra cqlsh -e 'ALTER TABLE mview.users ADD ( > asdasdasd set>);' > # cassandra-stress user profile=cs_no_mv_basic_profile.yaml ops'(insert=1)' > cl=ONE n=20 -pop seq=1..1000 -port jmx=6868 -mode cql3 native -rate > threads=2 -node 172.17.0.2 > Result: > Extra Schema Definitions: null > Generator Configs: > password: Size: Fixed: key=80; > last_name: Size: Uniform: min=1,max=32; > id: Size: Uniform: min=1,max=10; > first_name: Size: Fixed: key=16; > email: Size: Uniform: min=16,max=50; > username: Size: Uniform: min=10,max=30; > Query Definitions: > read1: CQL:select * from mview.users where id = ? LIMIT 10;Fields:samerow; > Token Range Queries: > Insert Settings: > partitions: fixed(1) > batchtype: UNLOGGED > Connected to cluster: , max pending requests per connection 128, max > connections per host 8 > Datacenter: datacenter1; Host: /172.17.0.2:9042; Rack: rack1 > Created schema. Sleeping 1s for propagation. > java.lang.NullPointerException > at > org.apache.cassandra.stress.StressProfile$ColumnInfo.getGenerator(StressProfile.java:760) > at > org.apache.cassandra.stress.StressProfile$ColumnInfo.getGenerator(StressProfile.java:800) > at > org.apache.cassandra.stress.StressProfile$ColumnInfo.getGenerator(StressProfile.java:800) > at > org.apache.cassandra.stress.StressProfile$ColumnInfo.getGenerator(StressProfile.java:755) > at > org.apache.cassandra.stress.StressProfile$GeneratorFactory.get(StressProfile.java:733) > at > org.apache.cassandra.stress.StressProfile$GeneratorFactory.newGenerator(StressProfile.java:726) > at > org.apache.cassandra.stress.StressProfile.newGenerator(StressProfile.java:696) > at > org.apache.cassandra.stress.StressProfile.printSettings(StressProfile.java:126) > at > org.apache.cassandra.stress.settings.StressSettings.lambda$printSettings$1(StressSettings.java:311) > at java.util.LinkedHashMap.forEach(LinkedHashMap.java:684) > at > org.apache.cassandra.stress.settings.StressSettings.printSettings(StressSettings.java:311) > at org.apache.cassandra.stress.Stress.run(Stress.java:95) > at org.apache.cassandra.stress.Stress.main(Stress.java:62) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (1e90cb3ed -> d0534a4c5)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 1e90cb3ed generate docs for 16320f1d new d0534a4c5 generate docs for 16320f1d This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (1e90cb3ed) \ N -- N -- N refs/heads/asf-staging (d0534a4c5) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724298#comment-17724298
]
Brandon Williams commented on CASSANDRA-18305:
--
I don't know why (I think maybe they were amended to a merge commit) but your
updates weren't integrating with your PR, so I extracted everything to a single
commit
[here|https://github.com/driftx/cassandra/commit/4bcbbc189952f1be037601e4c5b532407de5c2a2].
Since this ticket targets 4.0 and 4.1 and this patch doesn't apply cleanly to
them, we'll need at least one more PR for 4.0, and another if the same patch
doesn't apply to 4.1.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18346) Error Unknown column during deserialization missing keyspace and table name
[
https://issues.apache.org/jira/browse/CASSANDRA-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18346:
-
Status: Needs Committer (was: Review In Progress)
> Error Unknown column during deserialization missing keyspace and table name
> ---
>
> Key: CASSANDRA-18346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18346
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Low
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The ERROR message generated in ColumnSubselection.java when a column name is
> not found only prints the column name, not the keyspace and table. It can be
> difficult to track down the source when more than one table uses the same
> name. E.g., 'id'.
> {quote}{{if (column == null)}}
> {
> {{ column = metadata.getDroppedColumn(name);}}
> {{ if (column == null)}}
> {{ throw new UnknownColumnException("Unknown column " +
> UTF8Type.instance.getString(name) + " during deserialization");}}
> {{}}}
> {quote}
> Example:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id during deserialization
> Proposed:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id in table cycling.route during deserialization
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18346) Error Unknown column during deserialization missing keyspace and table name
[
https://issues.apache.org/jira/browse/CASSANDRA-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724285#comment-17724285
]
Brandon Williams commented on CASSANDRA-18346:
--
LGTM, +1.
> Error Unknown column during deserialization missing keyspace and table name
> ---
>
> Key: CASSANDRA-18346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18346
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Low
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The ERROR message generated in ColumnSubselection.java when a column name is
> not found only prints the column name, not the keyspace and table. It can be
> difficult to track down the source when more than one table uses the same
> name. E.g., 'id'.
> {quote}{{if (column == null)}}
> {
> {{ column = metadata.getDroppedColumn(name);}}
> {{ if (column == null)}}
> {{ throw new UnknownColumnException("Unknown column " +
> UTF8Type.instance.getString(name) + " during deserialization");}}
> {{}}}
> {quote}
> Example:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id during deserialization
> Proposed:
> [ERROR] cluster_id=15 ip_address=192.168.65.10 java.lang.RuntimeException:
> Unknown column id in table cycling.route during deserialization
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18025: - Reviewers: Brandon Williams > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18025: - Status: Ready to Commit (was: Review In Progress) +1 > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18025: - Status: Review In Progress (was: Needs Committer) > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18025: -- Test and Documentation Plan: CI Status: Patch Available (was: In Progress) > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18025: -- Status: Needs Committer (was: Patch Available) > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
