[cassandra-website] branch asf-staging updated (2ecb0fb0 -> d497fe68)
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 2ecb0fb0 generate docs for 1b144e50 new d497fe68 generate docs for 1b144e50 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 (2ecb0fb0) \ N -- N -- N refs/heads/asf-staging (d497fe68) 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] [Updated] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17997: Reviewers: Andres de la Peña, Berenguer Blasi (was: Andres de la Peña) Status: Review In Progress (was: Needs Committer) > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x, 5.x > > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- 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-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=17729918#comment-17729918
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
Ok, would take care of comments.
> 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.x
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> 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] [Created] (CASSANDRA-18571) CQLSSTableWriter support the generation of secondary index sstable
Maxwell Guo created CASSANDRA-18571: --- Summary: CQLSSTableWriter support the generation of secondary index sstable Key: CASSANDRA-18571 URL: https://issues.apache.org/jira/browse/CASSANDRA-18571 Project: Cassandra Issue Type: Improvement Components: Tool/sstable Reporter: Maxwell Guo CQLSSTableWriter support secondary index' sstable generation , I think it should support all secondary index ,include SAI. -- 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-18285) Add JDK 11 upgrade tests for 4.0+ in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729866#comment-17729866 ] Ekaterina Dimitrova edited comment on CASSANDRA-18285 at 6/6/23 11:58 PM: -- I added for trunk JDK11 upgrade tests, removing JDK 8 upgrade tests - both Java and Python. Unfortunately, 16 new Python upgrade tests are failing in CircleCI. Those are skipped in Jenkins, similar to CASSANDRA-18499. Unfortunately, I cannot load the artifacts page in CircleCI or reproduce the failures locally. Even if I add --force-resource-intensive-tests as suggested in CASSANDRA-18499. What is weird is I found those running with JDK 8 in CircleCI, like for example here test_parallel_upgrade - it seems it was upgrading from 4.1 with JDK8 - [https://app.circleci.com/pipelines/github/bereng/cassandra/970/workflows/2e949ede-cae5-4ab8-a118-43ec6d722b0d/jobs/18811/artifacts] [~mck] do you mind to review if I am doing something stupid and there is some additional check or anything to be added? After we confirm I didn't break anything myself here, I will also go ahead and add JDK11 upgrade tests for 4.0 and 4.1 (without removing JDK 8 upgrade tests which will run all paths where that one is needed - upgrades from 3.0 and 3.11) [CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2362/workflows/fcbacaf2-eacc-491b-a920-07316a9efc73/jobs/24111/tests], [Patch|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18285-trunk-3?expand=1] was (Author: e.dimitrova): I added for trunk JDK11 upgrade tests, removing JDK 8 upgrade tests - both Java and Python. Unfortunately, 16 new Python upgrade tests are failing in CircleCI. Those are skipped in Jenkins, similar to CASSANDRA-18499. Unfortunately, I cannot load the artifacts page in CircleCI and reproduce the failures locally. Even if I add --force-resource-intensive-tests as suggested in CASSANDRA-18499. What is weird is I found those running with JDK 8 in CircleCI, like for example here test_parallel_upgrade - it seems it was upgrading from 4.1 with JDK8 - [https://app.circleci.com/pipelines/github/bereng/cassandra/970/workflows/2e949ede-cae5-4ab8-a118-43ec6d722b0d/jobs/18811/artifacts] [~mck] do you mind to review if I am doing something stupid and there is some additional check or anything to be added? After we confirm I didn't break anything myself here, I will also go ahead and add JDK11 upgrade tests for 4.0 and 4.1 (without removing JDK 8 upgrade tests which will run all paths where that one is needed - upgrades from 3.0 and 3.11) [CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2362/workflows/fcbacaf2-eacc-491b-a920-07316a9efc73/jobs/24111/tests], [Patch|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18285-trunk-3?expand=1] > Add JDK 11 upgrade tests for 4.0+ in CircleCI > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- 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-18285) Add JDK 11 upgrade tests for 4.0+ in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-18285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729866#comment-17729866 ] Ekaterina Dimitrova commented on CASSANDRA-18285: - I added for trunk JDK11 upgrade tests, removing JDK 8 upgrade tests - both Java and Python. Unfortunately, 16 new Python upgrade tests are failing in CircleCI. Those are skipped in Jenkins, similar to CASSANDRA-18499. Unfortunately, I cannot load the artifacts page in CircleCI and reproduce the failures locally. Even if I add --force-resource-intensive-tests as suggested in CASSANDRA-18499. What is weird is I found those running with JDK 8 in CircleCI, like for example here test_parallel_upgrade - it seems it was upgrading from 4.1 with JDK8 - [https://app.circleci.com/pipelines/github/bereng/cassandra/970/workflows/2e949ede-cae5-4ab8-a118-43ec6d722b0d/jobs/18811/artifacts] [~mck] do you mind to review if I am doing something stupid and there is some additional check or anything to be added? After we confirm I didn't break anything myself here, I will also go ahead and add JDK11 upgrade tests for 4.0 and 4.1 (without removing JDK 8 upgrade tests which will run all paths where that one is needed - upgrades from 3.0 and 3.11) [CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2362/workflows/fcbacaf2-eacc-491b-a920-07316a9efc73/jobs/24111/tests], [Patch|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18285-trunk-3?expand=1] > Add JDK 11 upgrade tests for 4.0+ in CircleCI > - > > Key: CASSANDRA-18285 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18285 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Currently we test upgrades with Java 8, in preparation to drop it we need > first to ensurer we test with 11. This has to be added not only in trunk,, > but also 4.1 > I believe [~mck] has this ready to push in Jenkins at some point so this > ticket should accommodate the addition of those upgrade tests in CircleCI for > 4.1 and trunk. -- 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-18570) Fix org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-18570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729862#comment-17729862
]
Brandon Williams commented on CASSANDRA-18570:
--
CASSANDRA-18025 only touched stress which I don't see this test importing, so
it seems an unlikely candidate to me.
> Fix
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
>
> ---
>
> Key: CASSANDRA-18570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18570
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> h1.
> {code:java}
> Regression
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
> (from org.apache.cassandra.transport.DriverBurnTest-.jdk17)
> Failing for the past 1 build (Since #1590 ) Took 30 sec. Failed 5 times
> in the last 30 runs. Flakiness: 24%, Stability: 83% Stacktrace
> junit.framework.AssertionFailedError at
> org.apache.cassandra.transport.DriverBurnTest.perfTest(DriverBurnTest.java:425)
> at
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression(DriverBurnTest.java:316)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> {code}
> The test is flaky since recently, failing every other time in Jenkins (burn
> tests are not running in CircleCI) First seen with run #1572 this commit -
> CASSANDRA-18025
> CC [~stefan.miklosovic] and [~brandon.williams]
>
--
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-18504) Added support for type VECTOR
[ https://issues.apache.org/jira/browse/CASSANDRA-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729861#comment-17729861 ] David Capwell commented on CASSANDRA-18504: --- TIL: tinyint is variable length and not fixed length... > Added support for type VECTOR > -- > > Key: CASSANDRA-18504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18504 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema, CQL/Syntax >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > Time Spent: 8h 10m > Remaining Estimate: 0h > > Based off several mailing list threads (see "[POLL] Vector type for ML”, > "[DISCUSS] New data type for vector search”, and "Adding vector search to SAI > with heirarchical navigable small world graph index”), its desirable to add a > new type “VECTOR” that has the following properties > 1) fixed length array > 2) elements may not be null > 3) flatten array (aka multi-cell = false) -- 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 *June 6th 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| | |_Burn tests_| | |1|org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression|CASSANDRA-18570| 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
[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| | |_Burn tests_| | |1|org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression|CASSANDRA-18570| 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
[jira] [Updated] (CASSANDRA-18570) Fix org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-18570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18570:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Fix
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
>
> ---
>
> Key: CASSANDRA-18570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18570
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> h1.
> {code:java}
> Regression
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
> (from org.apache.cassandra.transport.DriverBurnTest-.jdk17)
> Failing for the past 1 build (Since #1590 ) Took 30 sec. Failed 5 times
> in the last 30 runs. Flakiness: 24%, Stability: 83% Stacktrace
> junit.framework.AssertionFailedError at
> org.apache.cassandra.transport.DriverBurnTest.perfTest(DriverBurnTest.java:425)
> at
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression(DriverBurnTest.java:316)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> {code}
> The test is flaky since recently, failing every other time in Jenkins (burn
> tests are not running in CircleCI) First seen with run #1572 this commit -
> CASSANDRA-18025
> CC [~stefan.miklosovic] and [~brandon.williams]
>
--
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-18570) Fix org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-18570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18570:
Epic Link: CASSANDRA-16895
> Fix
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
>
> ---
>
> Key: CASSANDRA-18570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18570
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> h1.
> {code:java}
> Regression
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
> (from org.apache.cassandra.transport.DriverBurnTest-.jdk17)
> Failing for the past 1 build (Since #1590 ) Took 30 sec. Failed 5 times
> in the last 30 runs. Flakiness: 24%, Stability: 83% Stacktrace
> junit.framework.AssertionFailedError at
> org.apache.cassandra.transport.DriverBurnTest.perfTest(DriverBurnTest.java:425)
> at
> org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression(DriverBurnTest.java:316)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> {code}
> The test is flaky since recently, failing every other time in Jenkins (burn
> tests are not running in CircleCI) First seen with run #1572 this commit -
> CASSANDRA-18025
> CC [~stefan.miklosovic] and [~brandon.williams]
>
--
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-18570) Fix org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
Ekaterina Dimitrova created CASSANDRA-18570:
---
Summary: Fix
org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
Key: CASSANDRA-18570
URL: https://issues.apache.org/jira/browse/CASSANDRA-18570
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
h1.
{code:java}
Regression
org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-.jdk17
(from org.apache.cassandra.transport.DriverBurnTest-.jdk17)
Failing for the past 1 build (Since #1590 ) Took 30 sec. Failed 5 times in
the last 30 runs. Flakiness: 24%, Stability: 83% Stacktrace
junit.framework.AssertionFailedError at
org.apache.cassandra.transport.DriverBurnTest.perfTest(DriverBurnTest.java:425)
at
org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression(DriverBurnTest.java:316)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
The test is flaky since recently, failing every other time in Jenkins (burn
tests are not running in CircleCI) First seen with run #1572 this commit -
CASSANDRA-18025
CC [~stefan.miklosovic] and [~brandon.williams]
--
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
[GitHub] [cassandra-analytics] frankgh closed pull request #1: CASSANDRA-18545: Provide a SecretsProvider interface to abstract the secret provisioning
frankgh closed pull request #1: CASSANDRA-18545: Provide a SecretsProvider interface to abstract the secret provisioning URL: https://github.com/apache/cassandra-analytics/pull/1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[GitHub] [cassandra-analytics] frankgh commented on pull request #1: CASSANDRA-18545: Provide a SecretsProvider interface to abstract the secret provisioning
frankgh commented on PR #1: URL: https://github.com/apache/cassandra-analytics/pull/1#issuecomment-1579551639 Merged in https://github.com/apache/cassandra-analytics/commit/b87b0edd310d1ef93c5071ae51e1b0b319c6 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - 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 (92c74164 -> 2ecb0fb0)
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 92c74164 generate docs for 1b144e50 new 2ecb0fb0 generate docs for 1b144e50 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 (92c74164) \ N -- N -- N refs/heads/asf-staging (2ecb0fb0) 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] [Updated] (CASSANDRA-18545) [Analytics] Abstract mTLS provisioning via a SecretsProvider
[
https://issues.apache.org/jira/browse/CASSANDRA-18545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-18545:
--
Fix Version/s: NA
Source Control Link:
https://github.com/apache/cassandra-analytics/commit/b87b0edd310d1ef93c5071ae51e1b0b319c6
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into cassandra analytics trunk as
[b87b0ed|https://github.com/apache/cassandra-analytics/commit/b87b0edd310d1ef93c5071ae51e1b0b319c6]
> [Analytics] Abstract mTLS provisioning via a SecretsProvider
>
>
> Key: CASSANDRA-18545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18545
> Project: Cassandra
> Issue Type: Task
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: NA
>
>
> This enhancement allows us to abstract the mTLS secrets provisioning through
> a {{SecretsProvider}} interface. This will allow custom implementations of
> the {{SecretsProvider}} to be able to hook into the secrets provisioning. We
> need to provide a default implementation {{SslConfigSecretsProvider}} which
> provides secrets via the {{SslConfig}} which is parsed from the reader
> options.
--
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 updated: CASSANDRA-18545: Provide a SecretsProvider interface to abstract the secret provisioning
This is an automated email from the ASF dual-hosted git repository.
ycai pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-analytics.git
The following commit(s) were added to refs/heads/trunk by this push:
new b87b0ed CASSANDRA-18545: Provide a SecretsProvider interface to
abstract the secret provisioning
b87b0ed is described below
commit b87b0edd310d1ef93c5071ae51e1b0b319c6
Author: Francisco Guerrero
AuthorDate: Tue May 23 13:56:48 2023 -0700
CASSANDRA-18545: Provide a SecretsProvider interface to abstract the secret
provisioning
This commit introduces the SecretsProvider interface that abstracts the
secrets provisioning.
This way different implementations of the SecretsProvider can be used to
provide SSL secrets
for the Analytics job. We provide an implementation,
SslConficSecretsProvider, which provides
secrets based on the configuration for the job.
Patch by Francisco Guerrero; Reviewed by Dinesh Joshi, Yifan Cai for
CASSANDRA-18545
---
.../java/org/apache/cassandra/clients/Sidecar.java | 17 +-
.../apache/cassandra/secrets/SecretsProvider.java | 108 +
.../cassandra/{clients => secrets}/SslConfig.java | 85 +++
.../secrets/SslConfigSecretsProvider.java | 198 +++
.../org/apache/cassandra/spark/KryoRegister.java | 2 +-
.../cassandra/spark/data/CassandraDataLayer.java | 5 +-
.../spark/data/CassandraDataSourceHelper.java | 2 +-
.../secrets/SslConfigSecretsProviderTest.java | 270 +
.../{clients => secrets}/SslConfigTest.java| 14 +-
.../cassandra/spark/KryoSerializationTests.java| 2 +-
.../data/CassandraDataSourceHelperCacheTest.java | 2 +-
.../data/partitioner/JDKSerializationTests.java| 2 +-
.../secrets/fakecerts/client-keystore-password | 1 +
.../secrets/fakecerts/client-keystore.p12 | Bin 0 -> 2576 bytes
.../secrets/fakecerts/client-truststore-password | 1 +
.../secrets/fakecerts/client-truststore.jks| Bin 0 -> 1094 bytes
16 files changed, 639 insertions(+), 70 deletions(-)
diff --git
a/cassandra-analytics-core/src/main/java/org/apache/cassandra/clients/Sidecar.java
b/cassandra-analytics-core/src/main/java/org/apache/cassandra/clients/Sidecar.java
index 71d8f43..bac09e2 100644
---
a/cassandra-analytics-core/src/main/java/org/apache/cassandra/clients/Sidecar.java
+++
b/cassandra-analytics-core/src/main/java/org/apache/cassandra/clients/Sidecar.java
@@ -37,6 +37,7 @@ import org.slf4j.LoggerFactory;
import o.a.c.sidecar.client.shaded.io.vertx.core.Vertx;
import o.a.c.sidecar.client.shaded.io.vertx.core.VertxOptions;
+import org.apache.cassandra.secrets.SecretsProvider;
import org.apache.cassandra.sidecar.client.HttpClientConfig;
import org.apache.cassandra.sidecar.client.SidecarClient;
import org.apache.cassandra.sidecar.client.SidecarConfig;
@@ -78,7 +79,7 @@ public final class Sidecar
public static SidecarClient from(SidecarInstancesProvider
sidecarInstancesProvider,
ClientConfig config,
- SslConfig sslConfig) throws IOException
+ SecretsProvider secretsProvider) throws
IOException
{
Vertx vertx = Vertx.vertx(new
VertxOptions().setUseDaemonThread(true).setWorkerPoolSize(config.maxPoolSize()));
@@ -90,16 +91,16 @@ public final class Sidecar
.maxChunkSize((int) config.maxBufferSize())
.userAgent(BuildInfo.READER_USER_AGENT);
-if (sslConfig != null)
+if (secretsProvider != null)
{
builder = builder
.ssl(true)
-.keyStoreInputStream(sslConfig.keyStoreInputStream())
-.keyStorePassword(sslConfig.keyStorePassword())
-.keyStoreType(sslConfig.keyStoreType())
-.trustStoreInputStream(sslConfig.trustStoreInputStream())
-.trustStorePassword(sslConfig.trustStorePassword())
-.trustStoreType(sslConfig.trustStoreType());
+.keyStoreInputStream(secretsProvider.keyStoreInputStream())
+
.keyStorePassword(String.valueOf(secretsProvider.keyStorePassword()))
+.keyStoreType(secretsProvider.keyStoreType())
+
.trustStoreInputStream(secretsProvider.trustStoreInputStream())
+
.trustStorePassword(String.valueOf(secretsProvider.trustStorePassword()))
+.trustStoreType(secretsProvider.trustStoreType());
}
HttpClientConfig httpClientConfig = builder.build();
diff --git
a/cassandra-analytics-core/src/main/java/org/apache/cassandra/secrets/SecretsProvider.java
b/cassandra-analytics-core/src/main/java/org/apache/cassandra/secrets/SecretsProvider.java
new file mode 100644
index 000..a54b5eb
--- /dev/null
[jira] [Updated] (CASSANDRA-18545) [Analytics] Abstract mTLS provisioning via a SecretsProvider
[
https://issues.apache.org/jira/browse/CASSANDRA-18545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-18545:
--
Status: Ready to Commit (was: Review In Progress)
> [Analytics] Abstract mTLS provisioning via a SecretsProvider
>
>
> Key: CASSANDRA-18545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18545
> Project: Cassandra
> Issue Type: Task
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> This enhancement allows us to abstract the mTLS secrets provisioning through
> a {{SecretsProvider}} interface. This will allow custom implementations of
> the {{SecretsProvider}} to be able to hook into the secrets provisioning. We
> need to provide a default implementation {{SslConfigSecretsProvider}} which
> provides secrets via the {{SslConfig}} which is parsed from the reader
> options.
--
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] (CASSANDRASC-50) Remove deprecate health endpoint containing instance segment
[
https://issues.apache.org/jira/browse/CASSANDRASC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729846#comment-17729846
]
Francisco Guerrero commented on CASSANDRASC-50:
---
CI: https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar/144
> 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
]
Yifan Cai updated CASSANDRASC-50:
-
Status: Ready to Commit (was: Review In Progress)
> 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] [Commented] (CASSANDRASC-50) Remove deprecate health endpoint containing instance segment
[
https://issues.apache.org/jira/browse/CASSANDRASC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729845#comment-17729845
]
Yifan Cai commented on CASSANDRASC-50:
--
+1 on the patch.
> 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] [Commented] (CASSANDRA-18545) [Analytics] Abstract mTLS provisioning via a SecretsProvider
[
https://issues.apache.org/jira/browse/CASSANDRA-18545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729840#comment-17729840
]
Yifan Cai commented on CASSANDRA-18545:
---
+1 on the patch
> [Analytics] Abstract mTLS provisioning via a SecretsProvider
>
>
> Key: CASSANDRA-18545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18545
> Project: Cassandra
> Issue Type: Task
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> This enhancement allows us to abstract the mTLS secrets provisioning through
> a {{SecretsProvider}} interface. This will allow custom implementations of
> the {{SecretsProvider}} to be able to hook into the secrets provisioning. We
> need to provide a default implementation {{SslConfigSecretsProvider}} which
> provides secrets via the {{SslConfig}} which is parsed from the reader
> options.
--
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 (2597e05c -> 92c74164)
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 2597e05c generate docs for 1b144e50 new 92c74164 generate docs for 1b144e50 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 (2597e05c) \ N -- N -- N refs/heads/asf-staging (92c74164) 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729822#comment-17729822 ] Jaydeepkumar Chovatia commented on CASSANDRA-18555: --- [~smiklosovic] [~maxwellguo] I am fine with [https://github.com/apache/cassandra/pull/2390]. Let's go with it. Jaydeep > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729822#comment-17729822 ] Jaydeepkumar Chovatia edited comment on CASSANDRA-18555 at 6/6/23 6:12 PM: --- [~smiklosovic] [~maxwellguo] I am fine with [https://github.com/apache/cassandra/pull/2390]. Let's go with it. Jaydeep was (Author: chovatia.jayd...@gmail.com): [~smiklosovic] [~maxwellguo] I am fine with [https://github.com/apache/cassandra/pull/2390]. Let's go with it. Jaydeep > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729822#comment-17729822 ] Jaydeepkumar Chovatia edited comment on CASSANDRA-18555 at 6/6/23 6:12 PM: --- [~smiklosovic] [~maxwellguo] I am fine with [https://github.com/apache/cassandra/pull/2390]. Let's go with it. was (Author: chovatia.jayd...@gmail.com): [~smiklosovic] [~maxwellguo] I am fine with [https://github.com/apache/cassandra/pull/2390]. Let's go with it. Jaydeep > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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 (3be0cf6c -> 2597e05c)
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 3be0cf6c generate docs for 1b144e50 new 2597e05c generate docs for 1b144e50 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 (3be0cf6c) \ N -- N -- N refs/heads/asf-staging (2597e05c) 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] [Comment Edited] (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=17729800#comment-17729800
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/6/23 4:12 PM:
---
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors2
pending compaction tasks 8
ks tb 3
ks tb2 5
compactions completed51
minute rate 0.31/second
5 minute rate0.38/second
15 minute rate 0.39/second
mean rate0.09/second
compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors2
pending compaction tasks 8
ks tb 3
ks tb2 5
compactions completed57
minute rate 0.46/second
5 minute rate1.25/second
15 minute rate 1.47/second
mean rate0.10/second
compaction throughput (MBps) 64.0
compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) [https://github.com/apache/cassandra/pull/2393/files]
was (Author: smiklosovic):
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors2
pending tasks
count8
ks tb 3
ks tb2 5
compactions completed51
minute rate 0.31/second
5 minute rate0.38/second
15 minute rate 0.39/second
mean rate0.09/second
compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors2
pending tasks
count8
ks tb 3
ks tb2 5
compactions completed57
minute rate 0.46/second
5 minute rate1.25/second
15 minute rate 1.47/second
mean rate0.10/second
compaction throughput (MBps) 64.0
compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) [https://github.com/apache/cassandra/pull/2393/files]
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL:
[jira] [Comment Edited] (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=17729800#comment-17729800
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/6/23 4:07 PM:
---
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors2
pending tasks
count8
ks tb 3
ks tb2 5
compactions completed51
minute rate 0.31/second
5 minute rate0.38/second
15 minute rate 0.39/second
mean rate0.09/second
compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors2
pending tasks
count8
ks tb 3
ks tb2 5
compactions completed57
minute rate 0.46/second
5 minute rate1.25/second
15 minute rate 1.47/second
mean rate0.10/second
compaction throughput (MBps) 64.0
compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) [https://github.com/apache/cassandra/pull/2393/files]
was (Author: smiklosovic):
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
compaction throughput (MBps) 64.0
compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) [https://github.com/apache/cassandra/pull/2393/files]
> Enhance
[jira] [Comment Edited] (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=17729800#comment-17729800
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/6/23 4:06 PM:
---
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
compaction throughput (MBps) 64.0
compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) [https://github.com/apache/cassandra/pull/2393/files]
was (Author: smiklosovic):
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
actual compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are
[jira] [Comment Edited] (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=17729800#comment-17729800
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/6/23 4:04 PM:
---
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
actual compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) [https://github.com/apache/cassandra/pull/2393/files]
was (Author: smiklosovic):
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
actual compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use
[jira] [Comment Edited] (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=17729800#comment-17729800
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/6/23 4:04 PM:
---
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
actual compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) [https://github.com/apache/cassandra/pull/2393/files]
EDIT:
btw I am not sure that the figure
1.47/second
or similar is correct. Why is that "/second" ? As I understand that figure,
1.47 is the number of total compactions completed in 15 minutes. (looking into
the second example). Similarly, it would be "1.25 total compactions completed
in 5 minutes". I think that "/second" is misleading as that number is related
to the specific time window, no? Or maybe I am completely wrong here and it is
truly "per second in that specific time window".
was (Author: smiklosovic):
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed
[jira] [Comment Edited] (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=17729800#comment-17729800
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/6/23 4:02 PM:
---
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
actual compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) [https://github.com/apache/cassandra/pull/2393/files]
EDIT:
btw I am not sure that the figure
1.47/second
or similar is correct. Why is that "/second" ? As I understand that figure,
1.47 is the number of total compactions completed in 15 minutes. (looking into
the second example). Similarly, it would be "1.25 total compactions completed
in 5 minutes". I think that "/second" is misleading as that number is related
to the specific time window, no?
was (Author: smiklosovic):
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
[jira] [Commented] (CASSANDRA-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729801#comment-17729801
]
Ekaterina Dimitrova commented on CASSANDRA-18423:
-
{quote}Thanks for the fix.
{quote}
Unfortunately, this was not a fix but a revert of the original patch from
CASSANDRA-18262 (at least the part where we run checkstyle only with J8), so we
still need to fix checkstyle for JDK11. This becomes a blocker to drop JDK8.
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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-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=17729800#comment-17729800
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/6/23 3:55 PM:
---
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code:java}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code:java}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
actual compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) [https://github.com/apache/cassandra/pull/2393/files]
was (Author: smiklosovic):
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
actual compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
"--" is just placeholder for any pending compactions on
[jira] [Comment Edited] (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=17729800#comment-17729800
]
Stefan Miklosovic edited comment on CASSANDRA-18305 at 6/6/23 3:54 PM:
---
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code}
concurrent compactors 2
pending tasks
count 8
ks tb 3
ks tb2 5
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
actual compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
"--" is just placeholder for any pending compactions on some specific keyspace
and table if there are any
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) https://github.com/apache/cassandra/pull/2393/files
was (Author: smiklosovic):
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code}
concurrent compactors 2
pending tasks
count 0
-- here keyspace table will be printed
-- here keyspace2 table2 will be printed
-- here keyspace3 table3 will be printed
-- here keyspace4 table4 will be printed
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code}
concurrent compactors 2
pending tasks
count 0
ks tb 3
ks tb 3
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
[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=17729800#comment-17729800
]
Stefan Miklosovic commented on CASSANDRA-18305:
---
Hi [~manish.c.ghildi...@gmail.com]
first of all thank your for your contribution.
I look at 4.0 patch and what I would prefer to see is the usage of TableBuilder
instead of just printing lines to output. TableBuilder is used across the
codebase in nodetool and it is just better way to handle the output as it is
automatically aligned depending on the width of each line.
For example, instead of this (current state of 4.0 branch)
{code}
2 concurrent compactors, 0 pending tasks
compactions completed: 80
minute rate:.12/second
5 minute rate:.54/second
15 minute rate:.70/second
Mean rate:.14/second
compaction throughput ratio: 64.0 MBps / 64.0 MBps (100.0%)
{code}
Now it looks like this (1)
{code}
concurrent compactors 2
pending tasks
count 0
-- here keyspace table will be printed
-- here keyspace2 table2 will be printed
-- here keyspace3 table3 will be printed
-- here keyspace4 table4 will be printed
compactions completed 51
minute rate 0.31/second
5 minute rate 0.38/second
15 minute rate 0.39/second
mean rate 0.09/second
actual compaction throughput (MBps) throttling disabled (0)
{code}
or
{code}
concurrent compactors 2
pending tasks
count 0
ks tb 3
ks tb 3
compactions completed 57
minute rate 0.46/second
5 minute rate 1.25/second
15 minute rate 1.47/second
mean rate 0.10/second
actual compaction throughput (MBps) 64.0
actual compaction throughput ratio 64.0 MBps / 64.0 MBps (100.0%)
{code}
"--" is just placeholder for any pending compactions on some specific keyspace
and table if there are any
Do you think it is something which we could use instead?
You are welcome to build on top of what I did (you may just git cherry-pick
that commit).
(1) https://github.com/apache/cassandra/pull/2393/files
> 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.x
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> 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] [Commented] (CASSANDRA-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729795#comment-17729795
]
Brandon Williams commented on CASSANDRA-18423:
--
Not at all, I've left it open intentionally so we can properly solve this.
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729792#comment-17729792
]
Maxim Muzafarov commented on CASSANDRA-18423:
-
Thanks for the fix.
Would you mind keeping this issue open to find the root cause of such an issue
once CASSANDRA-18565 is resolved? Just to avoid having to deal with the same
issue again and again in the future.
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-1.png, image.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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=17729763#comment-17729763
]
Stefan Miklosovic commented on CASSANDRA-18346:
---
+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] [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=17729764#comment-17729764
]
Stefan Miklosovic commented on CASSANDRA-18346:
---
[~manish.c.ghildi...@gmail.com] thank you for your contribution!
> 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.16, 4.0.11, 4.1.3, 5.0
>
> 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-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
]
Stefan Miklosovic updated CASSANDRA-18346:
--
Fix Version/s: 3.11.16
4.0.11
4.1.3
5.0
(was: 3.11.x)
(was: 5.x)
(was: 4.0.x)
(was: 4.1.x)
Since Version: 3.11.0
Source Control Link:
https://github.com/apache/cassandra/commit/03da864bab9740c067363a8dcce13db2bfd47ce2
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> 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.16, 4.0.11, 4.1.3, 5.0
>
> 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-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
]
Stefan Miklosovic updated CASSANDRA-18346:
--
Status: Ready to Commit (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
[cassandra] branch cassandra-4.1 updated (aa7ed179d3 -> 867c074dda)
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 aa7ed179d3 Merge branch 'cassandra-4.0' into cassandra-4.1 add 03da864bab Add keyspace and table name to exception message during ColumnSubselection deserialization add f368b9dc1e Merge branch 'cassandra-3.11' into cassandra-4.0 add 867c074dda Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/db/filter/ColumnSubselection.java | 8 ++-- 2 files changed, 7 insertions(+), 2 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 (5655a33bc0 -> f368b9dc1e)
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 5655a33bc0 Fix Down nodes counter in nodetool describecluster add 03da864bab Add keyspace and table name to exception message during ColumnSubselection deserialization add f368b9dc1e Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/db/filter/ColumnSubselection.java | 8 ++-- 2 files changed, 7 insertions(+), 2 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 (9c970cc117 -> 03da864bab)
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 9c970cc117 Merge branch 'cassandra-3.0' into cassandra-3.11 add 03da864bab Add keyspace and table name to exception message during ColumnSubselection deserialization No new revisions were added by this update. Summary of changes: CHANGES.txt | 2 +- src/java/org/apache/cassandra/db/filter/ColumnSubselection.java | 8 ++-- 2 files changed, 7 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (a2dc44f072 -> 984f519bd9)
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 a2dc44f072 Remove dependency on pytz library for setting CQLSH timezones on Python version >= 3.9 add 03da864bab Add keyspace and table name to exception message during ColumnSubselection deserialization add f368b9dc1e Merge branch 'cassandra-3.11' into cassandra-4.0 add 867c074dda Merge branch 'cassandra-4.0' into cassandra-4.1 add 984f519bd9 Merge branch 'cassandra-4.1' into trunk No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/db/filter/ColumnSubselection.java | 8 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18133) In-tree build scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729751#comment-17729751
]
Ekaterina Dimitrova commented on CASSANDRA-18133:
-
{quote} I have no objections to my suggestion :)
{quote}
Me too :)
> In-tree build scripts
> -
>
> Key: CASSANDRA-18133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18133
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Bring the artifact/deb/rpm build scripts (and associated docker images) from
> cassandra-builds repo to the .build directory.
> The declarative Jenkinsfile can then directly declare the artifacts jobs in
> its pipeline. And the packaging jobs can be separated and run in parallel.
> This addresses the epic's stated existing problems:
> - difficult to pre-commit test jenkins and cassandra-build changes,
> - CI development efforts is split between ci-cassandra and circleci, despite
> ci-cassandra being our canonical and non-commercial CI,
> - lacking parity of what is tested between ci-cassandra and circleci
> - cassandra-builds as a separate repo (without release branches matching
> in-tree) adds complexity to changing matrix values (jdks, pythons, dist)
> - mixture of jenkins dsl groovy, declarative and scripting pipeline.
> - different pre-commit and post-commit jenkins pipelines are used.
> In addition it addresses:
> - stage jobs don't always running on the same SHA as the pipeline's run,
> - infra issues around networking, specifically git cloning additional
> cassandra-builds repository,
> - a more readable Jenkinsfile
> - more UX friendly build and test scripts
--
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-18567) Add jobs for resource-intensive Python upgrade tests
[ https://issues.apache.org/jira/browse/CASSANDRA-18567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729748#comment-17729748 ] Ekaterina Dimitrova commented on CASSANDRA-18567: - Currently, we don't :) Jenkins does not have enough energy for all of them (for reference CASSANDRA-18499) My plan Is to add them and they can be optional pre-commit in CircleCI but always run in Jenkins post-commit. Same as the current Python upgrade tests We do not have in Jenkins tests that run on a particular cadence. Everything runs post-commit there, as far as I know. > Add jobs for resource-intensive Python upgrade tests > > > Key: CASSANDRA-18567 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18567 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > As it was noticed in CASSANDRA-18499, Python upgrade tests should include > resource-intensive ones. Some are run in CircleCI but skipped in Jenkins (see > CASSANDRA-18499 for reference). > We should add --skip-resource-intensive-tests to the current Python upgrade > tests jobs and create new jobs dedicated to the resource-intensive upgrade > tests — the way we do it for the regular Python Dtests(for reference - large > DTests). -- 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
]
Stefan Miklosovic updated CASSANDRA-18346:
--
Reviewers: Brandon Williams, Stefan Miklosovic (was: Brandon Williams)
> 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-18567) Add jobs for resource-intensive Python upgrade tests
[ https://issues.apache.org/jira/browse/CASSANDRA-18567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729743#comment-17729743 ] Josh McKenzie commented on CASSANDRA-18567: --- bq. create new jobs dedicated to the resource-intensive upgrade tests Do you know off the top of your head if / when we run these in an automated fashion? Is that per-commit, or on a particular cadence, or before releases? (ping [~mck]) > Add jobs for resource-intensive Python upgrade tests > > > Key: CASSANDRA-18567 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18567 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > As it was noticed in CASSANDRA-18499, Python upgrade tests should include > resource-intensive ones. Some are run in CircleCI but skipped in Jenkins (see > CASSANDRA-18499 for reference). > We should add --skip-resource-intensive-tests to the current Python upgrade > tests jobs and create new jobs dedicated to the resource-intensive upgrade > tests — the way we do it for the regular Python Dtests(for reference - large > DTests). -- 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-18133) In-tree build scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-18133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729742#comment-17729742
]
Josh McKenzie commented on CASSANDRA-18133:
---
{quote}I'm going to split the Jenkinsfile update out to a separate ticket. It
is proving difficult to test, too many moving pieces.
{quote}
+1 to that change from me.
> In-tree build scripts
> -
>
> Key: CASSANDRA-18133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18133
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Bring the artifact/deb/rpm build scripts (and associated docker images) from
> cassandra-builds repo to the .build directory.
> The declarative Jenkinsfile can then directly declare the artifacts jobs in
> its pipeline. And the packaging jobs can be separated and run in parallel.
> This addresses the epic's stated existing problems:
> - difficult to pre-commit test jenkins and cassandra-build changes,
> - CI development efforts is split between ci-cassandra and circleci, despite
> ci-cassandra being our canonical and non-commercial CI,
> - lacking parity of what is tested between ci-cassandra and circleci
> - cassandra-builds as a separate repo (without release branches matching
> in-tree) adds complexity to changing matrix values (jdks, pythons, dist)
> - mixture of jenkins dsl groovy, declarative and scripting pipeline.
> - different pre-commit and post-commit jenkins pipelines are used.
> In addition it addresses:
> - stage jobs don't always running on the same SHA as the pipeline's run,
> - infra issues around networking, specifically git cloning additional
> cassandra-builds repository,
> - a more readable Jenkinsfile
> - more UX friendly build and test scripts
--
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
]
Stefan Miklosovic updated CASSANDRA-18346:
--
Status: Review In Progress (was: Needs Committer)
> 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
[cassandra-website] branch asf-staging updated (5fd080b5 -> 3be0cf6c)
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 5fd080b5 generate docs for 1b144e50 new 3be0cf6c generate docs for 1b144e50 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 (5fd080b5) \ N -- N -- N refs/heads/asf-staging (3be0cf6c) 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
[cassandra-website] branch asf-staging updated (612adb7b -> 5fd080b5)
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 612adb7b generate docs for 1b144e50 new 5fd080b5 generate docs for 1b144e50 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 (612adb7b) \ N -- N -- N refs/heads/asf-staging (5fd080b5) 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-18119) Handle sstable metadata stats file getting a new mtime after compaction has finished
[
https://issues.apache.org/jira/browse/CASSANDRA-18119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729728#comment-17729728
]
Josh McKenzie commented on CASSANDRA-18119:
---
Just noticed this in my queue [~marcuse]. w/a rebase is this ready to merge?
> Handle sstable metadata stats file getting a new mtime after compaction has
> finished
>
>
> Key: CASSANDRA-18119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18119
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/Startup and Shutdown
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Due to a race between compaction finishing and compaction strategies getting
> reloaded there is a chance that we try to add both the new sstable and the
> old compacted sstable to the compaction strategy, and in the LCS case this
> can cause the old sstable to get sent to L0 to avoid overlap. This changes
> the mtime of the stats metadata file and if the node is shut down before the
> sstable is actually deleted from disk, we fail starting with the following
> exception:
> {code}
> .../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
> REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
> ***Unexpected files detected for sstable [nb-0-big-]: last update
> time [Thu Dec 15 10:24:09 CET 2022] (1671096249000) should have been [Thu Dec
> 15 10:24:07 CET 2022] (1671096247000)
> ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
> {code}
> A workaround for this (until we properly fix the way compaction strategies
> get notified about sstable changes) is to ignore the timestamp of the STATS
> component when cleaning up compaction leftovers on startup.
--
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-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer edited comment on CASSANDRA-17047 at 6/6/23 12:57 PM:
-
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
was (Author: blerer):
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
>
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Epic Link: CASSANDRA-17276
> Dtest cluster reusage
> -
>
> Key: CASSANDRA-16951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16951
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Dtests are very heavy but in some instances most of the time is spent
> restarting nodes in between test methods. Not all of them, but many seem
> could benefit form reusing a common cluster sparing the restarts. Obviously
> that is not the case for tests that manipulate the nodes itself during the
> test. The ones that follow a setup node/do test seem to benefit greatly in
> terms of time execution.
> Some classes run time can be cut form 10m to 1,5m. Others only from 30m to
> 25m. But taking a 5m shave and considering it will probably get ran *
> with/without vnodes * j8/j11/j8j11 * 4.0/trunk turns the 5m cut into a 60m
> cut. That should be a nice reduction in CI usage. Unfortunately run time will
> mostly remain the same until we have a majority of tests reusing nodes as the
> 'longest pole' will be the determining factor.
> How it works? It's an opt-in. Annotate the first test with
> {{@reuse_cluster(new_cluster=True)}} and the following ones with
> {{@reuse_cluster}}. Best effort to reuse the cluster will be made. Stop using
> the annotation at any test method and it will start a new one.
--
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-15196) Unify CommitLogSegment allocation to one hierarchy and remove test-cdc testing target
[
https://issues.apache.org/jira/browse/CASSANDRA-15196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-15196:
--
Epic Link: CASSANDRA-17276
> Unify CommitLogSegment allocation to one hierarchy and remove test-cdc
> testing target
> -
>
> Key: CASSANDRA-15196
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15196
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Commit Log
>Reporter: Joshua McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.x
>
>
> {{April 2023 update}}
> With the push towards stabilizing ASF CI, one of the things we can do is
> remove the total runtime of our tests. CDC's segment allocation has been in
> the ecosystem for a long while now and has proven stable in the "CDC enabled
> on the node but not the table" case, so unifying the hierarchy to a single
> allocator and removing the test-cdc target in ant should both help us clean
> up some debt in the codebase and also streamline our CI processes. Along with
> that, we can take this chance to tidy up some of the internals of the
> implementation as previously mentioned on this ticket.
>
> {{ORIGINAL DESCRIPTION}}
> Back when I wrote CASSANDRA-8844 and CASSANDRA-12148, a few things about the
> CommitLog stood out to me that I wasn't in love with. At the time I was much
> more of the mind of "When in Rome..." regarding some of our structures, our
> naming, and specifically regarding our penchant for inheritance vs.
> composition. Turns out I have an itch here I need to scratch.
> This patch refactors the CommitLog in a few key ways:
> * Removes inheritence for CommitLogSegmentManagerX, instead has a single
> CommitLogSegmentManager and a CommitLogSegmentAllocator interface
> ** This interface is implemented by CommitLogSegmentAllocatorStandard and
> CommitLogSegmentAllocatorCDC
> * Renames a few variables and methods within the segment manager to make
> their purpose and role more clear from names alone (hopefully):
> ** allocatingFrom --> activeSegment
> ** allocatingFrom() --> getActiveSegment()
> ** advanceAllocatingFrom() – switchToNewSegment()
> ** activeSegments --> unflushedSegments
> ** getActiveSegments --> getUnflushedSegments()
> ** awaitAvailableSegment(...) --> awaitSegmentAllocation(...)
> ** isStillAllocating() --> hasRoom()
> * Reorders some of the "allocation-and-compare-in-while-loop-decl) to more
> idiomatic style
> * Adds some comments to various under-documented methods, mostly related to
> CDC and timing
> -As far as we are in the 4.0 testing, I don't expect this to hit pre 4.0.
> Given it's a relatively minor refactor in well-tested code, doesn't change
> functionality, and doesn't impact any of the publicly exposed APIs in the
> CommitLog ecosystem, I'd be comfortable with it going in a minor release
> after 4.0 is out. But I'm open to alternative viewpoints.-
> -Have run unit tests locally w/out issue on both regular and cdc-targets;
> need to get CI against the branch internally for full dtest run and I'll post
> when it's done. Just wanted to get visibility to this out there in case
> anyone was curious or thinking of working on the same thing.-
> [ Link to branch on
> github|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:clean_cl_comp]
--
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-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer edited comment on CASSANDRA-17047 at 6/6/23 12:56 PM:
-
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
was (Author: blerer):
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
>
[jira] [Updated] (CASSANDRA-17276) Cassandra CI Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17276: -- Summary: Cassandra CI Improvements (was: Cassandra CI Process Improvements) > Cassandra CI Improvements > - > > Key: CASSANDRA-17276 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17276 > Project: Cassandra > Issue Type: Epic >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Reference dev [ML > Thread|https://lists.apache.org/thread/bq470ml17g106pwxpvwgws2stxc6d7b9] > Reference cwiki ratified final process: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280 > There are some outstanding infrastructural, documentation, and automation > pieces from the agreed upon CI state we need to implement. -- 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-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer edited comment on CASSANDRA-17047 at 6/6/23 12:55 PM:
-
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11|
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
was (Author: blerer):
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11,
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
>
[jira] [Updated] (CASSANDRA-17276) Cassandra CI Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17276: -- Epic Name: CIImprovements (was: CIProcessImprovements) > Cassandra CI Improvements > - > > Key: CASSANDRA-17276 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17276 > Project: Cassandra > Issue Type: Epic >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Reference dev [ML > Thread|https://lists.apache.org/thread/bq470ml17g106pwxpvwgws2stxc6d7b9] > Reference cwiki ratified final process: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280 > There are some outstanding infrastructural, documentation, and automation > pieces from the agreed upon CI state we need to implement. -- 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-17047) Dropping a column can break queries until the schema is fully propagated (TAKE 2)
[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729727#comment-17729727
]
Benjamin Lerer commented on CASSANDRA-17047:
I rebased the patches, simplified the tests, added new ones and addressed the
review comments.
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1283] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/336/workflows/7fa31999-e9bf-404d-8403-14e3fac4a936]
|
|[3.11|https://github.com/apache/cassandra/pull/1284]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/335/workflows/eef88e85-0daf-4cc1-9e77-43b2555c4023]|
|[4.0|https://github.com/apache/cassandra/pull/1285]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/334/workflows/2d708d8d-2b39-4ebb-bf11-d2d4b557f623]
, [J11,
https://app.circleci.com/pipelines/github/blerer/cassandra/329/workflows/37938a5e-a950-4dd0-80ec-d47df0ed49c9]|
|[4.1|https://github.com/apache/cassandra/pull/2392] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/06f40fef-6a5e-4ddb-8272-8a7fc26727f0],[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/333/workflows/004c37f7-a6ef-44a0-8e45-a9e4fb9b3c52]|
|[trunk|https://github.com/apache/cassandra/pull/1286]|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/954685c0-2102-418d-b713-2eadc69c07ee]
,[
j11|https://app.circleci.com/pipelines/github/blerer/cassandra/332/workflows/0e047501-7559-4382-aa0c-76b6d80a0d72]|
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> -
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> ...
> {code}
> Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
> CASSANDRA-15899 tried to fix the problem when columns are dropped as well as
> when columns are added. Unfortunately the fix introduced an issue and had to
> be reverted in CASSANDRA-16735.
> If the scenario for ADDED columns is tricky, the original scenario for
> DROPPED columns can be solved in a safe way at the {{ColumnFilter}} level.
> By consequence, I think that we should at least solve that scenario.
> [~bdeggleston], [~samt], [~ifesdjeen] does my proposal makes sense to you?
--
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-18569) Bti shouldn't be available in compatibility mode
[ https://issues.apache.org/jira/browse/CASSANDRA-18569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729706#comment-17729706 ] Berenguer Blasi commented on CASSANDRA-18569: - [~adelapena] this one should be a very quick review for you if you find a gap. > Bti shouldn't be available in compatibility mode > > > Key: CASSANDRA-18569 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18569 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0 > > > When having a node in compatibility mode sstable tries shouldn't be an option. -- 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-18569) Bti shouldn't be available in compatibility mode
[ https://issues.apache.org/jira/browse/CASSANDRA-18569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18569: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Local/SSTable Discovered By: User Report Fix Version/s: 5.0 Severity: Normal Status: Open (was: Triage Needed) > Bti shouldn't be available in compatibility mode > > > Key: CASSANDRA-18569 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18569 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0 > > > When having a node in compatibility mode sstable tries shouldn't be an option. -- 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-18569) Bti shouldn't be available in compatibility mode
[ https://issues.apache.org/jira/browse/CASSANDRA-18569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18569: Test and Documentation Plan: See PR Status: Patch Available (was: In Progress) > Bti shouldn't be available in compatibility mode > > > Key: CASSANDRA-18569 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18569 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0 > > > When having a node in compatibility mode sstable tries shouldn't be an option. -- 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 (a3cdbdd2 -> 612adb7b)
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 a3cdbdd2 generate docs for 1b144e50 new 612adb7b generate docs for 1b144e50 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 (a3cdbdd2) \ N -- N -- N refs/heads/asf-staging (612adb7b) 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] [Created] (CASSANDRA-18569) Bti shouldn't be available in compatibility mode
Berenguer Blasi created CASSANDRA-18569: --- Summary: Bti shouldn't be available in compatibility mode Key: CASSANDRA-18569 URL: https://issues.apache.org/jira/browse/CASSANDRA-18569 Project: Cassandra Issue Type: Bug Reporter: Berenguer Blasi Assignee: Berenguer Blasi When having a node in compatibility mode sstable tries shouldn't be an option. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[
https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729662#comment-17729662
]
Stefan Miklosovic commented on CASSANDRA-18555:
---
I have also added this to nodetool info
{code}
$ ./bin/nodetool info
ID : 0ae1c2be-5a7b-477d-9835-a84c7af7a950
Gossip active : true
Native Transport active: true
Load : 208.67 KiB
Uncompressed load : 300.5 KiB
Generation No : 1686041148
Uptime (seconds) : 7
Heap Memory (MB) : 285.82 / 973.00
Off Heap Memory (MB) : 0.00
Data Center: datacenter1
Rack : rack1
Exceptions : 0
Key Cache : entries 20, size 1.66 KiB, capacity 46 MiB, 143 hits,
167 requests, 0.856 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 23 MiB, 0 hits, 0
requests, NaN recent hit rate, 7200 save period in seconds
Network Cache : size 0 bytes, overflow size: 0 bytes, capacity 58 MiB
Percent Repaired : 100.0%
Token : (invoke with -T/--tokens to see all 16 tokens)
Bootstrap state: COMPLETED
{code}
Check the last line.
> A new nodetool/JMX command that tells whether node's decommission failed or
> not
> ---
>
> Key: CASSANDRA-18555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18555
> Project: Cassandra
> Issue Type: Task
> Components: Observability/JMX
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, when a node is being decommissioned and if any failure happens,
> then an exception is thrown back to the caller.
> But Cassandra's decommission takes considerable time ranging from minutes to
> hours to days. There are various scenarios in that the caller may need to
> probe the status again:
> * The caller times out
> * It is not possible to keep the caller hanging for such a long time
> And If the caller does not know what happened internally, then it cannot
> retry, etc., leading to other issues.
> So, in this ticket, I am going to add a new nodetool/JMX command that can be
> invoked by the caller anytime, and it will return the correct status.
> It might look like a smaller change, but when we need to operate Cassandra at
> scale in a large-scale fleet, then this becomes a bottleneck and require
> constant operator intervention.
--
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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729658#comment-17729658 ] Maxwell Guo commented on CASSANDRA-18555: - After reading the code implementation， I am + 1 with you [~smiklosovic], [~chovatia.jayd...@gmail.com] Does this meet your expectations? > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18553) Generate.sh -s param to skip autodetection of tests
[ https://issues.apache.org/jira/browse/CASSANDRA-18553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729659#comment-17729659 ] Berenguer Blasi commented on CASSANDRA-18553: - CASSANDRA-17997 should merge soon. Let's wait and I'll get this done. > Generate.sh -s param to skip autodetection of tests > --- > > Key: CASSANDRA-18553 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18553 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > When using generate.sh auto detection of modified tests always kicks in. That > can be a problem during dev when you want to test a given set of tests > without getting all the others in the way. Also when you want to run the > script without having to checkout the extra branches auto detection needs. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729651#comment-17729651 ] Stefan Miklosovic edited comment on CASSANDRA-18555 at 6/6/23 8:14 AM: --- [~chovatia.jayd...@gmail.com] [~maxwellguo] let me know what you think about this https://github.com/apache/cassandra/pull/2390 The idea is that DECOMMISSION_FAILED will be written into system.local so you can just query it ... was (Author: smiklosovic): [~chovatia.jayd...@gmail.com] [~maxwellguo] let me know what you think about this https://github.com/apache/cassandra/pull/2390 The idea is that DECOMISSION_FAILED will be written into system.local so you can just query it ... > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729651#comment-17729651 ] Stefan Miklosovic commented on CASSANDRA-18555: --- [~chovatia.jayd...@gmail.com] [~maxwellguo] let me know what you think about this https://github.com/apache/cassandra/pull/2390 The idea is that DECOMISSION_FAILED will be written into system.local so you can just query it ... > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729637#comment-17729637 ] Stefan Miklosovic commented on CASSANDRA-18555: --- Actually, as I looked more into it, the ability to retrieve the failed decommission state in something like "nodetool status" would mean that we would need to introduce this "state" into TokenMetadata and "topology" and this stuff would need to be propagated via Gossip etc. Think about it ... if we are about to know that decommission has failed on some node _from whatever node_, the only way a node knows that such and such node failed to decommission is to get this information from Gossip. I think that is way too much work ... On the other hand, if I understand this correctly, this (1) is a Runnable which is passed to this method (2) where the actual decommission is done and it is run here (3) at the very end. So, as native transport is being shut down as part of that Runnable here (4), that means that if something goes wrong with decommission and it throw an exception, thar Runnable is never called which means that NativeTransport / CQL together with Gossip is never stopped either so we do have ability to connect to CQL even if decommission fails, no? That means that we might reflect the fact that decommission has failed by writing it to some table - even a virtual one - and we do not need to depend on JMX nor on any nodetool. (1) https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageService.java#L5189 (2) https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageService.java#L5210 (3) https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageService.java#L5293 (4) https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageService.java#L5193-L5194 > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729621#comment-17729621 ] Maxwell Guo commented on CASSANDRA-18555: - Totally agree with what [~smiklosovic] said, we can't add a nodetool command for every new requirement.It is a good choice to converge the newly added needs to the existing commands > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729613#comment-17729613 ] Stefan Miklosovic edited comment on CASSANDRA-18555 at 6/6/23 6:58 AM: --- In general, we try to move away from the introduction of any new nodetool commands and we try to do it via cql instead. However, here it is a little bit problematic as CQL will probably not be available anymore upon decomission as it would be already turned off so we can not connect to it anymore and only JMX is available. That being said, could not we somehow reuse already existing nodetool command and we could put this information into it instead of creating brand new nodetool command? Something like "info", "status" or "describecluster"? If there are various statuses in "status" command like UJ, UN, UL ... can not be there some status which reflects the fact that such node has failed to decommission itself? The advantage of seeing it in "nodetool status" is that you would know _all nodes which failed to decommission_ instead of going to that particular node asking its decommission status via the proposed command. was (Author: smiklosovic): In general, we try to move away from the introduction of any new nodetool commands and we try to do it via cql instead. However, here it is a little bit problematic as CQL will probably not be available anymore upon decomission as it would be already turned off so we can not connect to it anymore and only JMX is available. That being said, could not we somehow reuse already existing nodetool command and we could put this information into it instead of creating brand new nodetool command? Something like "info", "status" or "describecluster"? If there are various statuses in "status" command like UJ, UN, UL ... can not be there some status which reflects the fact that such node has failed to decommission itself? > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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-18555) A new nodetool/JMX command that tells whether node's decommission failed or not
[ https://issues.apache.org/jira/browse/CASSANDRA-18555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729613#comment-17729613 ] Stefan Miklosovic commented on CASSANDRA-18555: --- In general, we try to move away from the introduction of any new nodetool commands and we try to do it via cql instead. However, here it is a little bit problematic as CQL will probably not be available anymore upon decomission as it would be already turned off so we can not connect to it anymore and only JMX is available. That being said, could not we somehow reuse already existing nodetool command and we could put this information into it instead of creating brand new nodetool command? Something like "info", "status" or "describecluster"? If there are various statuses in "status" command like UJ, UN, UL ... can not be there some status which reflects the fact that such node has failed to decommission itself? > A new nodetool/JMX command that tells whether node's decommission failed or > not > --- > > Key: CASSANDRA-18555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18555 > Project: Cassandra > Issue Type: Task > Components: Observability/JMX >Reporter: Jaydeepkumar Chovatia >Assignee: Jaydeepkumar Chovatia >Priority: Normal > > Currently, when a node is being decommissioned and if any failure happens, > then an exception is thrown back to the caller. > But Cassandra's decommission takes considerable time ranging from minutes to > hours to days. There are various scenarios in that the caller may need to > probe the status again: > * The caller times out > * It is not possible to keep the caller hanging for such a long time > And If the caller does not know what happened internally, then it cannot > retry, etc., leading to other issues. > So, in this ticket, I am going to add a new nodetool/JMX command that can be > invoked by the caller anytime, and it will return the correct status. > It might look like a smaller change, but when we need to operate Cassandra at > scale in a large-scale fleet, then this becomes a bottleneck and require > constant operator intervention. -- 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 (ccc0a468 -> a3cdbdd2)
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 ccc0a468 generate docs for 1b144e50 new a3cdbdd2 generate docs for 1b144e50 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 (ccc0a468) \ N -- N -- N refs/heads/asf-staging (a3cdbdd2) 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
