[jira] [Comment Edited] (CASSANDRA-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730376#comment-17730376
]
Maxwell Guo edited comment on CASSANDRA-17698 at 6/8/23 4:05 AM:
-
[pr-trunk-update|https://github.com/apache/cassandra/pull/2118]
[j8-prcommit|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/446/workflows/4570a05e-49e9-438d-8119-6fe96ffeaed9]
[j11-precommit|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/446/workflows/ddbf467a-efb2-4de1-bc35-1b9890cb76e8]
java8 and java11's uts are all green ,but some dtest is not green . I took a
look at the failed cases, most of which are related to insufficient resources.
[~adelapena]
was (Author: maxwellguo):
[pr-trunk-update|https://github.com/apache/cassandra/pull/2118]
[j8-prcommit|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/446/workflows/4570a05e-49e9-438d-8119-6fe96ffeaed9]
[j11-precommit|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/446/workflows/ddbf467a-efb2-4de1-bc35-1b9890cb76e8]
java8 and java11's uts are all green ,but some dtest is not green . Those
failed cases seem to be caused by insufficient resources.
[~adelapena]
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730376#comment-17730376
]
Maxwell Guo commented on CASSANDRA-17698:
-
[pr-trunk-update|https://github.com/apache/cassandra/pull/2118]
[j8-prcommit|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/446/workflows/4570a05e-49e9-438d-8119-6fe96ffeaed9]
[j11-precommit|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/446/workflows/ddbf467a-efb2-4de1-bc35-1b9890cb76e8]
java8 and java11's uts are all green ,but some dtest is not green . Those
failed cases seem to be caused by insufficient resources.
[~adelapena]
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (d763ce8b8 -> 3ca5b0bd9)
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 d763ce8b8 generate docs for 1b144e50 new 3ca5b0bd9 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 (d763ce8b8) \ N -- N -- N refs/heads/asf-staging (3ca5b0bd9) 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-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730331#comment-17730331
]
Ekaterina Dimitrova commented on CASSANDRA-18180:
-
Thanks, [~djatnieks] , I will try to take a look at this tomorrow afternoon. CC
[~benedict]
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class
> sun.nio.ch.DirectBuffer (org.apache.cassandra.utils.memory.BufferPool$Chunk
> is in unnamed module of loader 'app'; sun.nio.ch.DirectBuffer is in module
> java.base of loader 'bootstrap')\n\tat
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMEngine.overlapDetection(GaloisCounterMode.java:865)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt.doFinal(GaloisCounterMode.java:1502)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode.engineDoFinal(GaloisCounterMode.java:447)\n\tat
>
> {code}
> -The issue is exposed with JDK 17, trunk; if interested, ping- [~e.dimitrova]
> -for current branch as there is no feature branch at the moment- we can
> build and start from trunk with JDK17 already. Circle CI can be run for JDK17
> too. For more information how to do that - .circleci/readme.md
> CC [~benedict]
--
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=17730329#comment-17730329 ] Ekaterina Dimitrova commented on CASSANDRA-18285: - I forgot to mention earlier. Jenkins currently skips 346 Python upgrade tests while in CircleCI 301 skipped and 16 failed out of 1827 identified to run in both CI systems. So we have 45 skipped tests, 16 of which are currently failing. > 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] [Assigned] (CASSANDRA-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-18077: --- Assignee: (was: Ekaterina Dimitrova) > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Priority: Normal > Fix For: 5.x > > Attachments: spotbugs.html > > Time Spent: 1h > Remaining Estimate: 0h > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-18077: --- Assignee: Ekaterina Dimitrova > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Attachments: spotbugs.html > > Time Spent: 1h > Remaining Estimate: 0h > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
[ https://issues.apache.org/jira/browse/CASSANDRA-18575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18575: - Description: Cassandra 3.0 has ciphers hard coded and thus not allow more recent and secure ciphers for storage connections complicating migrations to later versions. (was: Cassandra 3.0 has ciphers hard coded and thus not allow more recent and secure ciphers for gossip connections complicating migrations to later versions.) > Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols > -- > > Key: CASSANDRA-18575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18575 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: German Eichberger >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x > > > Cassandra 3.0 has ciphers hard coded and thus not allow more recent and > secure ciphers for storage connections complicating migrations to later > versions. -- 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 (c2f665f16 -> d763ce8b8)
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 c2f665f16 generate docs for 1b144e50 new d763ce8b8 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 (c2f665f16) \ N -- N -- N refs/heads/asf-staging (d763ce8b8) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
[ https://issues.apache.org/jira/browse/CASSANDRA-18575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730296#comment-17730296 ] Brandon Williams commented on CASSANDRA-18575: -- ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18575-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/1046/workflows/b0b8a6d7-5941-45e3-b82a-662ddb7f7692], [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2507/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2507/pipeline] | > Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols > -- > > Key: CASSANDRA-18575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18575 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: German Eichberger >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x > > > Cassandra 3.0 has ciphers hard coded and thus not allow more recent and > secure ciphers for gossip connections complicating migrations to later > versions. -- 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-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
[ https://issues.apache.org/jira/browse/CASSANDRA-18575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18575: - Reviewers: Brandon Williams, Brandon Williams Brandon Williams, Brandon Williams (was: Brandon Williams) Status: Review In Progress (was: Patch Available) > Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols > -- > > Key: CASSANDRA-18575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18575 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: German Eichberger >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x > > > Cassandra 3.0 has ciphers hard coded and thus not allow more recent and > secure ciphers for gossip connections complicating migrations to later > versions. -- 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-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
[ https://issues.apache.org/jira/browse/CASSANDRA-18575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18575: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols > -- > > Key: CASSANDRA-18575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18575 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: German Eichberger >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x > > > Cassandra 3.0 has ciphers hard coded and thus not allow more recent and > secure ciphers for gossip connections complicating migrations to later > versions. -- 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-18574) [Analytics] Fix example documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730295#comment-17730295
]
Yifan Cai commented on CASSANDRA-18574:
---
+1
> [Analytics] Fix example documentation
> --
>
> Key: CASSANDRA-18574
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18574
> Project: Cassandra
> Issue Type: Improvement
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation for the example job for Cassandra Analytics
> [link|https://github.com/apache/cassandra-analytics/blob/trunk/cassandra-analytics-core-example/README.md]
> configures Sidecar to use the local CCM cluster. This documentation is
> however broken since some feedback during the review of the Sidecar PR
> changed one of the yaml options from {{uploads_staging_dir}} to
> {{staging_dir}}.
> We need to update the documentation to reflect that change.
--
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-18574) [Analytics] Fix example documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-18574:
--
Reviewers: Yifan Cai
Status: Review In Progress (was: Needs Committer)
> [Analytics] Fix example documentation
> --
>
> Key: CASSANDRA-18574
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18574
> Project: Cassandra
> Issue Type: Improvement
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation for the example job for Cassandra Analytics
> [link|https://github.com/apache/cassandra-analytics/blob/trunk/cassandra-analytics-core-example/README.md]
> configures Sidecar to use the local CCM cluster. This documentation is
> however broken since some feedback during the review of the Sidecar PR
> changed one of the yaml options from {{uploads_staging_dir}} to
> {{staging_dir}}.
> We need to update the documentation to reflect that change.
--
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-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
[ https://issues.apache.org/jira/browse/CASSANDRA-18575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18575: - Bug Category: Parent values: Security(12985) Complexity: Normal Component/s: Messaging/Internode Discovered By: User Report Fix Version/s: 3.0.x Severity: Normal Status: Open (was: Triage Needed) > Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols > -- > > Key: CASSANDRA-18575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18575 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: German Eichberger >Assignee: German Eichberger >Priority: Normal > Fix For: 3.0.x > > > Cassandra 3.0 has ciphers hard coded and thus not allow more recent and > secure ciphers for gossip connections complicating migrations to later > versions. -- 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-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
[ https://issues.apache.org/jira/browse/CASSANDRA-18575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730293#comment-17730293 ] German Eichberger commented on CASSANDRA-18575: --- [[CASSANDRA-18575] Backport remove hard-coded SSL cipher suites and protocols by xgerman · Pull Request #2397 · apache/cassandra (github.com)|https://github.com/apache/cassandra/pull/2397] > Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols > -- > > Key: CASSANDRA-18575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18575 > Project: Cassandra > Issue Type: Bug >Reporter: German Eichberger >Assignee: German Eichberger >Priority: Normal > > Cassandra 3.0 has ciphers hard coded and thus not allow more recent and > secure ciphers for gossip connections complicating migrations to later > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
[ https://issues.apache.org/jira/browse/CASSANDRA-18575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] German Eichberger reassigned CASSANDRA-18575: - Assignee: German Eichberger > Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols > -- > > Key: CASSANDRA-18575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18575 > Project: Cassandra > Issue Type: Bug >Reporter: German Eichberger >Assignee: German Eichberger >Priority: Normal > > Cassandra 3.0 has ciphers hard coded and thus not allow more recent and > secure ciphers for gossip connections complicating migrations to later > versions. -- 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-18575) Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols
German Eichberger created CASSANDRA-18575: - Summary: Backport Cassandra-10508 Remove hard-coded SSL cipher suites and protocols Key: CASSANDRA-18575 URL: https://issues.apache.org/jira/browse/CASSANDRA-18575 Project: Cassandra Issue Type: Bug Reporter: German Eichberger Cassandra 3.0 has ciphers hard coded and thus not allow more recent and secure ciphers for gossip connections complicating migrations to later versions. -- 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-10508) Remove hard-coded SSL cipher suites and protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-10508:
-
Fix Version/s: (was: 3.0.x)
> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
> Labels: lhf
> Fix For: 3.6
>
> Attachments: 10508-trunk.patch
>
>
> Currently each SSL connections will be initialized using a hard-coded list of
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We
> now require Java 8 which comes with solid defaults for these kind of SSL
> settings and I'm wondering if the current behavior shouldn't be re-evaluated.
> In my impression the way cipher suites are currently whitelisted is
> problematic, as this will prevent the JVM from using more recent and more
> secure suites that haven't been added to the hard-coded list. JVM updates may
> also cause issues in case the limited number of ciphers cannot be used, e.g.
> see CASSANDRA-6613.
> -Looking at the source I've also stumbled upon a bug in the
> {{filterCipherSuites()}} method that would return the filtered list of
> ciphers in undetermined order where the result is passed to
> {{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the
> order of preference
> ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) and therefore you
> may end up with weaker algorithms on the top. Currently it's not that
> critical, as we only whitelist a couple of ciphers anyway. But it adds to the
> question if it still really makes sense to work with the cipher list at all
> in the Cassandra code base.- (fixed in CASSANDRA-11164)
> Another way to effect used ciphers is by changing the security properties.
> This is a more versatile way to work with cipher lists instead of relying on
> hard-coded values, see
> [here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
> for details.
> The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent
> SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted
> anyway and will stop using safer protocol sets on new JVM releases or user
> request. Again, we should stick with the JVM defaults. Using the
> {{jdk.tls.client.protocols}} systems property will always allow to restrict
> the set of protocols in case another emergency fix is needed.
--
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-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730281#comment-17730281
]
dan jatnieks edited comment on CASSANDRA-18180 at 6/7/23 9:20 PM:
--
I think that's a good suggestion. So the idea I have for that is to add a class
like:
{noformat}
DirectBufferRef extends Ref implements DirectBuffer
{noformat}
This can use used in {{BufferPool.setAttachment}} , like so:
{noformat}
MemoryUtil.setAttachment(buffer, new DirectBufferRef<>(this, null));
{noformat}
Here's a patch with that approach; let me know if it matches the suggestion or
I could try something else: [^cassandra-18180-directbufferref.diff]
I also noticed that {{MerkleTree}} has some similar code that sets a {{Ref}} as
a {{ByteBuffer}} attachment, and in fact, I think any caller of
{{MemoryUtil.setAttachment}} probably needs to ensure that the attachment
object implements {{DirectBuffer}} in case it gets used with encryption enabled.
The {{MerkleTree}} case is a bit easier than {{BufferPool}} because it only
uses a {{null}} referent, so it's enough just to use something like the
{{DirectBufferRef}} mentioned above (no need to implement {{DirectBuffer}} in
{{MerkleTree}} afaict). [This is not included yet in the patch]
I thought that perhaps it would be a good idea to even enforce it in
{{{}MemoryUtil{}}}, something like:
{noformat}
public static void setAttachment(ByteBuffer
instance, T next)
{noformat}
However, then I found that {{SyncUtil.force}} uses {{MemoryUtil.getAttachment}}
and expects that the attachment may be {{{}Runnable{}}}. I'm not sure yet how
that gets set though - I didn't any other {{setAttachment}} calls with
{{Runnable}} except in a unit test. Right now I'm not sure what to do about
this one - and I'm concerned that when encryption is being used, this could
again lead to a {{{}ClassCastException{}}}.
was (Author: djatnieks):
I think that's a good suggestion. So the idea I have for that is to add a class
like:
{noformat}
DirectBufferRef extends Ref implements DirectBuffer
{noformat}
This can use used in {{BufferPool.setAttachment}} , like so:
{noformat}
MemoryUtil.setAttachment(buffer, new DirectBufferRef<>(this, null));
{noformat}
Here's a patch with that approach; let me know if it matches the suggestion or
I could try something else: [^cassandra-18180-directbufferref.diff]
I also noticed that {{MerkleTree}} has some similar code that sets a {{Ref}} as
a {{ByteBuffer}} attachment, and in fact, I think any caller of
{{MemoryUtil.setAttachment}} probably needs to ensure that the attachment
object implements {{DirectBuffer}} in case it gets used with encryption enabled.
The {{MerkleTree}} case is a bit easier than {{BufferPool}} because it only
uses a {{null}} referent, so it's enough just to use something like the
{{DirectBufferRef}} mentioned above (no need to implement {{DirectBuffer}} in
{{MerkleTree}} afaict).
I thought that perhaps it would be a good idea to even enforce it in
{{{}MemoryUtil{}}}, something like:
{noformat}
public static void setAttachment(ByteBuffer
instance, T next)
{noformat}
However, then I found that {{SyncUtil.force}} uses {{MemoryUtil.getAttachment}}
and expects that the attachment may be {{{}Runnable{}}}. I'm not sure yet how
that gets set though - I didn't any other {{setAttachment}} calls with
{{Runnable}} except in a unit test. Right now I'm not sure what to do about
this one - and I'm concerned that when encryption is being used, this could
again lead to a {{{}ClassCastException{}}}.
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class
> sun.nio.ch.DirectBuffer (org.apache.cassandra.utils.memory.BufferPool$Chunk
> is in unnamed module of loader 'app'; sun.nio.ch.DirectBuffer is in module
> java.base of loader 'bootstrap')\n\tat
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMEngine.overlapDetection(GaloisCounterMode.java:865)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt.doFinal(GaloisCounterMode.java:1502)\n\tat
>
>
[jira] [Commented] (CASSANDRA-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730281#comment-17730281
]
dan jatnieks commented on CASSANDRA-18180:
--
I think that's a good suggestion. So the idea I have for that is to add a class
like:
{noformat}
DirectBufferRef extends Ref implements DirectBuffer
{noformat}
This can use used in {{BufferPool.setAttachment}} , like so:
{noformat}
MemoryUtil.setAttachment(buffer, new DirectBufferRef<>(this, null));
{noformat}
Here's a patch with that approach; let me know if it matches the suggestion or
I could try something else: [^cassandra-18180-directbufferref.diff]
I also noticed that {{MerkleTree}} has some similar code that sets a {{Ref}} as
a {{ByteBuffer}} attachment, and in fact, I think any caller of
{{MemoryUtil.setAttachment}} probably needs to ensure that the attachment
object implements {{DirectBuffer}} in case it gets used with encryption enabled.
The {{MerkleTree}} case is a bit easier than {{BufferPool}} because it only
uses a {{null}} referent, so it's enough just to use something like the
{{DirectBufferRef}} mentioned above (no need to implement {{DirectBuffer}} in
{{MerkleTree}} afaict).
I thought that perhaps it would be a good idea to even enforce it in
{{{}MemoryUtil{}}}, something like:
{noformat}
public static void setAttachment(ByteBuffer
instance, T next)
{noformat}
However, then I found that {{SyncUtil.force}} uses {{MemoryUtil.getAttachment}}
and expects that the attachment may be {{{}Runnable{}}}. I'm not sure yet how
that gets set though - I didn't any other {{setAttachment}} calls with
{{Runnable}} except in a unit test. Right now I'm not sure what to do about
this one - and I'm concerned that when encryption is being used, this could
again lead to a {{{}ClassCastException{}}}.
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class
> sun.nio.ch.DirectBuffer (org.apache.cassandra.utils.memory.BufferPool$Chunk
> is in unnamed module of loader 'app'; sun.nio.ch.DirectBuffer is in module
> java.base of loader 'bootstrap')\n\tat
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMEngine.overlapDetection(GaloisCounterMode.java:865)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt.doFinal(GaloisCounterMode.java:1502)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode.engineDoFinal(GaloisCounterMode.java:447)\n\tat
>
> {code}
> -The issue is exposed with JDK 17, trunk; if interested, ping- [~e.dimitrova]
> -for current branch as there is no feature branch at the moment- we can
> build and start from trunk with JDK17 already. Circle CI can be run for JDK17
> too. For more information how to do that - .circleci/readme.md
> CC [~benedict]
--
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-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dan jatnieks updated CASSANDRA-18180:
-
Attachment: cassandra-18180-directbufferref.diff
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class
> sun.nio.ch.DirectBuffer (org.apache.cassandra.utils.memory.BufferPool$Chunk
> is in unnamed module of loader 'app'; sun.nio.ch.DirectBuffer is in module
> java.base of loader 'bootstrap')\n\tat
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMEngine.overlapDetection(GaloisCounterMode.java:865)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt.doFinal(GaloisCounterMode.java:1502)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode.engineDoFinal(GaloisCounterMode.java:447)\n\tat
>
> {code}
> -The issue is exposed with JDK 17, trunk; if interested, ping- [~e.dimitrova]
> -for current branch as there is no feature branch at the moment- we can
> build and start from trunk with JDK17 already. Circle CI can be run for JDK17
> too. For more information how to do that - .circleci/readme.md
> CC [~benedict]
--
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-14667) Upgrade Dropwizard Metrics to 4.x
[ https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730279#comment-17730279 ] Stefan Miklosovic commented on CASSANDRA-14667: --- Let's give it a shot! I guess we need to see this first. > Upgrade Dropwizard Metrics to 4.x > - > > Key: CASSANDRA-14667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14667 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Stig Rohde Døssing >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: signature.asc > > Time Spent: 20m > Remaining Estimate: 0h > > Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for > Java 9 compatibility. It would be good to upgrade the Metrics library as part > of the version of Cassandra that adds Java 9 compatibility > (https://issues.apache.org/jira/browse/CASSANDRA-9608). -- 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-10508) Remove hard-coded SSL cipher suites and protocols
[
https://issues.apache.org/jira/browse/CASSANDRA-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
German Eichberger updated CASSANDRA-10508:
--
Fix Version/s: 3.0.x
> Remove hard-coded SSL cipher suites and protocols
> -
>
> Key: CASSANDRA-10508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10508
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.6
>
> Attachments: 10508-trunk.patch
>
>
> Currently each SSL connections will be initialized using a hard-coded list of
> protocols ("SSLv2Hello", "TLSv1", "TLSv1.1", "TLSv1.2") and cipher suites. We
> now require Java 8 which comes with solid defaults for these kind of SSL
> settings and I'm wondering if the current behavior shouldn't be re-evaluated.
> In my impression the way cipher suites are currently whitelisted is
> problematic, as this will prevent the JVM from using more recent and more
> secure suites that haven't been added to the hard-coded list. JVM updates may
> also cause issues in case the limited number of ciphers cannot be used, e.g.
> see CASSANDRA-6613.
> -Looking at the source I've also stumbled upon a bug in the
> {{filterCipherSuites()}} method that would return the filtered list of
> ciphers in undetermined order where the result is passed to
> {{setEnabledCipherSuites()}}. However, the list of ciphers will reflect the
> order of preference
> ([source|https://bugs.openjdk.java.net/browse/JDK-8087311]) and therefore you
> may end up with weaker algorithms on the top. Currently it's not that
> critical, as we only whitelist a couple of ciphers anyway. But it adds to the
> question if it still really makes sense to work with the cipher list at all
> in the Cassandra code base.- (fixed in CASSANDRA-11164)
> Another way to effect used ciphers is by changing the security properties.
> This is a more versatile way to work with cipher lists instead of relying on
> hard-coded values, see
> [here|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms]
> for details.
> The same applies to the protocols. Introduced in CASSANDRA-8265 to prevent
> SSLv3 attacks, this is not necessary anymore as SSLv3 is now blacklisted
> anyway and will stop using safer protocol sets on new JVM releases or user
> request. Again, we should stick with the JVM defaults. Using the
> {{jdk.tls.client.protocols}} systems property will always allow to restrict
> the set of protocols in case another emergency fix is needed.
--
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-18574) [Analytics] Fix example documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-18574:
---
Test and Documentation Plan: No tests were added, but the documentation to
run the sample job for Cassandra Analytics has been fixed.
Status: Patch Available (was: In Progress)
PR: https://github.com/apache/cassandra-analytics/pull/3
> [Analytics] Fix example documentation
> --
>
> Key: CASSANDRA-18574
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18574
> Project: Cassandra
> Issue Type: Improvement
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation for the example job for Cassandra Analytics
> [link|https://github.com/apache/cassandra-analytics/blob/trunk/cassandra-analytics-core-example/README.md]
> configures Sidecar to use the local CCM cluster. This documentation is
> however broken since some feedback during the review of the Sidecar PR
> changed one of the yaml options from {{uploads_staging_dir}} to
> {{staging_dir}}.
> We need to update the documentation to reflect that change.
--
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-18574) [Analytics] Fix example documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-18574:
---
Status: Needs Committer (was: Patch Available)
> [Analytics] Fix example documentation
> --
>
> Key: CASSANDRA-18574
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18574
> Project: Cassandra
> Issue Type: Improvement
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation for the example job for Cassandra Analytics
> [link|https://github.com/apache/cassandra-analytics/blob/trunk/cassandra-analytics-core-example/README.md]
> configures Sidecar to use the local CCM cluster. This documentation is
> however broken since some feedback during the review of the Sidecar PR
> changed one of the yaml options from {{uploads_staging_dir}} to
> {{staging_dir}}.
> We need to update the documentation to reflect that change.
--
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 opened a new pull request, #3: CASSANDRA-18574: Fix sample job documentation after Sidecar changes
frankgh opened a new pull request, #3: URL: https://github.com/apache/cassandra-analytics/pull/3 This commit fixes the README file with documentation to setup and run the Sample job provided in the repository. During Sidecar review, there was a suggestion to change the yaml property `uploads_staging_dir` to `staging_dir`. That change however was not reflected as part of the sample job README.md. -- 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
[jira] [Commented] (CASSANDRA-14667) Upgrade Dropwizard Metrics to 4.x
[ https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730255#comment-17730255 ] Maxim Muzafarov commented on CASSANDRA-14667: - [~smiklosovic] Yes. I haven't tested it for all cases except the distributed/stress tests, but option #4 works. We will need to remove these classes as soon as we update the driver version to 4.x, at no extra cost before then. If this is OK, I can submit the patch and check the CI results to check the rest of the cases. > Upgrade Dropwizard Metrics to 4.x > - > > Key: CASSANDRA-14667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14667 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Stig Rohde Døssing >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: signature.asc > > Time Spent: 20m > Remaining Estimate: 0h > > Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for > Java 9 compatibility. It would be good to upgrade the Metrics library as part > of the version of Cassandra that adds Java 9 compatibility > (https://issues.apache.org/jira/browse/CASSANDRA-9608). -- 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-18574) [Analytics] Fix example documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-18574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-18574:
---
Change Category: Semantic
Complexity: Low Hanging Fruit
Component/s: Analytics Library
Status: Open (was: Triage Needed)
> [Analytics] Fix example documentation
> --
>
> Key: CASSANDRA-18574
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18574
> Project: Cassandra
> Issue Type: Improvement
> Components: Analytics Library
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> The documentation for the example job for Cassandra Analytics
> [link|https://github.com/apache/cassandra-analytics/blob/trunk/cassandra-analytics-core-example/README.md]
> configures Sidecar to use the local CCM cluster. This documentation is
> however broken since some feedback during the review of the Sidecar PR
> changed one of the yaml options from {{uploads_staging_dir}} to
> {{staging_dir}}.
> We need to update the documentation to reflect that change.
--
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-18574) [Analytics] Fix example documentation
Francisco Guerrero created CASSANDRA-18574:
--
Summary: [Analytics] Fix example documentation
Key: CASSANDRA-18574
URL: https://issues.apache.org/jira/browse/CASSANDRA-18574
Project: Cassandra
Issue Type: Improvement
Reporter: Francisco Guerrero
Assignee: Francisco Guerrero
The documentation for the example job for Cassandra Analytics
[link|https://github.com/apache/cassandra-analytics/blob/trunk/cassandra-analytics-core-example/README.md]
configures Sidecar to use the local CCM cluster. This documentation is however
broken since some feedback during the review of the Sidecar PR changed one of
the yaml options from {{uploads_staging_dir}} to {{staging_dir}}.
We need to update the documentation to reflect that change.
--
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 (fa28e0a46 -> c2f665f16)
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 fa28e0a46 generate docs for 1b144e50 new c2f665f16 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 (fa28e0a46) \ N -- N -- N refs/heads/asf-staging (c2f665f16) 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-14667) Upgrade Dropwizard Metrics to 4.x
[ https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] miklosovic updated CASSANDRA-14667: --- Attachment: signature.asc Option 4) would work too imho. So this would make metrics functional in tests? If it is just about copying a class and moving it to appropriate package, that seems to me like the least invasive change plus metrics would work too. That is better than metrics not working and putting withoutMetrics everywhere. What is the cost of that custom class (classes) in the repo from the maintenance perspective? Just copy? Sent from ProtonMail mobile \ > Upgrade Dropwizard Metrics to 4.x > - > > Key: CASSANDRA-14667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14667 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Stig Rohde Døssing >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: signature.asc > > Time Spent: 20m > Remaining Estimate: 0h > > Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for > Java 9 compatibility. It would be good to upgrade the Metrics library as part > of the version of Cassandra that adds Java 9 compatibility > (https://issues.apache.org/jira/browse/CASSANDRA-9608). -- 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=17730238#comment-17730238
]
ASF subversion and git services commented on CASSANDRASC-50:
Commit 5d2cbaf5cb810f53689bf227e2c1f78a9a2b2e9f in cassandra-sidecar's branch
refs/heads/trunk from Francisco Guerrero
[ https://gitbox.apache.org/repos/asf?p=cassandra-sidecar.git;h=5d2cbaf ]
CASSANDRASC-50: Deprecate the sidecar cassandra health endpoint containing
instance segment
This commit deprecates the Cassandra Health endpoint containing the instance
segment
in the path. 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 commit also moves the CassandraHealthService from jax RS to a vertx
Handler.
It also moves the HealthService to a inlined handler, simplifying the service.
patch by Francisco Guerrero; reviewed by Yifan Cai, Dinesh Joshi for
CASSANDRASC-50
> 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
> Fix For: 1.0
>
>
> The Cassandra Health endpoint containing the instance segment in the path
> usage is deprecated. This endpoint is currently unused and it is replaced by
> the health endpoint with the {{instanceId}} query string parameter. Since the
> {{instanceId}} is optional we move the path param (mandatory) to the query
> param (optional).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-sidecar] branch trunk updated: CASSANDRASC-50: Deprecate the sidecar cassandra health endpoint containing instance segment
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-sidecar.git The following commit(s) were added to refs/heads/trunk by this push: new 5d2cbaf CASSANDRASC-50: Deprecate the sidecar cassandra health endpoint containing instance segment 5d2cbaf is described below commit 5d2cbaf5cb810f53689bf227e2c1f78a9a2b2e9f Author: Francisco Guerrero AuthorDate: Fri May 5 10:48:02 2023 -0700 CASSANDRASC-50: Deprecate the sidecar cassandra health endpoint containing instance segment This commit deprecates the Cassandra Health endpoint containing the instance segment in the path. 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 commit also moves the CassandraHealthService from jax RS to a vertx Handler. It also moves the HealthService to a inlined handler, simplifying the service. patch by Francisco Guerrero; reviewed by Yifan Cai, Dinesh Joshi for CASSANDRASC-50 --- CHANGES.txt| 1 + .../cassandra/sidecar/common/ApiEndpointsV1.java | 4 + .../org/apache/cassandra/sidecar/MainModule.java | 23 -- .../cassandra/sidecar/cluster/InstancesConfig.java | 7 +- .../sidecar/cluster/InstancesConfigImpl.java | 12 ++- .../cassandra/sidecar/routes/AbstractHandler.java | 4 +- .../sidecar/routes/CassandraHealthHandler.java | 93 ++ .../cassandra/sidecar/routes/HealthService.java| 50 .../sidecar/routes/SwaggerOpenApiResource.java | 3 +- .../sidecar/utils/InstanceMetadataFetcher.java | 4 +- .../routes/SnapshotsHandlerIntegrationTest.java| 30 +++ .../sidecar/AbstractHealthServiceTest.java | 31 12 files changed, 159 insertions(+), 103 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index aec5dc7..73870a7 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,5 +1,6 @@ 1.0.0 - + * Deprecate the sidecar cassandra health endpoint containing instance segment (CASSANDRASC-50) * Add an endpoint that gives information about the release version & partitioner name of a node (CASSANDRASC-48) * Introduce JMX foundation in Sidecar (CASSANDRASC-47) * Delegate methods to the RateLimiter (CASSANDRASC-45) diff --git a/common/src/main/java/org/apache/cassandra/sidecar/common/ApiEndpointsV1.java b/common/src/main/java/org/apache/cassandra/sidecar/common/ApiEndpointsV1.java index e159433..f68c469 100644 --- a/common/src/main/java/org/apache/cassandra/sidecar/common/ApiEndpointsV1.java +++ b/common/src/main/java/org/apache/cassandra/sidecar/common/ApiEndpointsV1.java @@ -26,6 +26,7 @@ public final class ApiEndpointsV1 public static final String API = "/api"; public static final String API_V1 = API + "/v1"; +public static final String HEALTH = "/__health"; public static final String CASSANDRA = "/cassandra"; public static final String KEYSPACE_PATH_PARAM = ":keyspace"; public static final String TABLE_PATH_PARAM = ":table"; @@ -39,6 +40,9 @@ public final class ApiEndpointsV1 public static final String PER_COMPONENT = "/components/" + COMPONENT_PATH_PARAM; public static final String PER_UPLOAD = "/uploads/" + UPLOAD_ID_PATH_PARAM; +public static final String HEALTH_ROUTE = API_V1 + HEALTH; +public static final String CASSANDRA_HEALTH_ROUTE = API_V1 + CASSANDRA + HEALTH; + @Deprecated // NOTE: Uses singular forms of "keyspace" and "table" public static final String DEPRECATED_SNAPSHOTS_ROUTE = API_V1 + "/keyspace/" + KEYSPACE_PATH_PARAM + "/table/" + TABLE_PATH_PARAM + diff --git a/src/main/java/org/apache/cassandra/sidecar/MainModule.java b/src/main/java/org/apache/cassandra/sidecar/MainModule.java index 581692b..fa0e196 100644 --- a/src/main/java/org/apache/cassandra/sidecar/MainModule.java +++ b/src/main/java/org/apache/cassandra/sidecar/MainModule.java @@ -19,6 +19,8 @@ package org.apache.cassandra.sidecar; import java.io.IOException; +import java.util.Collections; +import java.util.Map; import java.util.concurrent.TimeUnit; import com.google.common.util.concurrent.SidecarRateLimiter; @@ -46,10 +48,9 @@ import org.apache.cassandra.sidecar.common.CassandraVersionProvider; import org.apache.cassandra.sidecar.common.dns.DnsResolver; import org.apache.cassandra.sidecar.common.utils.ValidationConfiguration; import org.apache.cassandra.sidecar.logging.SidecarLoggerHandler; -import org.apache.cassandra.sidecar.routes.CassandraHealthService; +import org.apache.cassandra.sidecar.routes.CassandraHealthHandler; import org.apache.cassandra.sidecar.routes.FileStreamHandler; import
[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:
-
Fix Version/s: 1.0
Source Control Link:
https://github.com/apache/cassandra-sidecar/commit/5d2cbaf5cb810f53689bf227e2c1f78a9a2b2e9f
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[5d2cbaf5|https://github.com/apache/cassandra-sidecar/commit/5d2cbaf5cb810f53689bf227e2c1f78a9a2b2e9f]
> 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
> Fix For: 1.0
>
>
> 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-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=17730209#comment-17730209 ] Ekaterina Dimitrova commented on CASSANDRA-18285: - With that I suggest we keep test fixes separate from this patch. I will add 4.0 and 4.1 missing jobs and open follow up ticket to fix upgrade_through_versions.py > 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] [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=17730204#comment-17730204
]
Ekaterina Dimitrova edited comment on CASSANDRA-18285 at 6/7/23 5:01 PM:
-
I managed to reproduce the issue with JDK 11 upgrade tests locally by just
commenting out for now
{code:java}
@pytest.mark.skip("Fake skip so that this isn't run outside of a generated
class that removes this annotation"){code}
in upgrade_through_versions_test.py.
I can see in the logs
{code:java}
intx ThreadPriorityPolicy=42 is outside the allowed range [ 0 ... 1 ]
Improperly specified VM option 'ThreadPriorityPolicy=42.'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. The program will exit.
{code}
ThreadPriorityPolicy is an option we use with JDK8. The
upgrade_through_versions_test.py tests use [this multiupgrade
matrix|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_through_versions_test.py#L903-L920]
which starts from versions that do not support JDK11
This issue is only with upgrade_through_versions.py, and it was not initially
seen in CASSANDRA-17869 because those are skipped to run at all in Jenkins and
up to now we were running upgrade tests with JDK8 in CircleCI. It appears from
the test runs that the rest of the tests are run with JDK 11 and the suitable
options(no issue around ThreadPriorityPolicy observed).
was (Author: e.dimitrova):
I managed to reproduce the issue with JDK 11 upgrade tests locally by just
commenting out for now
{code:java}
@pytest.mark.skip("Fake skip so that this isn't run outside of a generated
class that removes this annotation"){code}
in upgrade_through_versions_test.py.
I can see in the logs
{code:java}
intx ThreadPriorityPolicy=42 is outside the allowed range [ 0 ... 1 ]
Improperly specified VM option 'ThreadPriorityPolicy=42.'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. The program will exit.
{code}
ThreadPriorityPolicy is an option we use with JDK8. The
upgrade_through_versions_test.py tests use [this multiupgrade
matrix|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_through_versions_test.py#L903-L920]
which starts from versions that do not support JDK11
This issue is only with upgrade_through_versions.py, and it was not initially
seen in CASSANDRA-17869 because those are skipped to run at all in Jenkins. It
appears from the test runs that the rest of the tests are run with JDK 11 and
the suitable options(no issue around ThreadPriorityPolicy observed).
> 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=17730204#comment-17730204
]
Ekaterina Dimitrova commented on CASSANDRA-18285:
-
I managed to reproduce the issue with JDK 11 upgrade tests locally by just
commenting out for now
{code:java}
@pytest.mark.skip("Fake skip so that this isn't run outside of a generated
class that removes this annotation"){code}
in upgrade_through_versions_test.py.
I can see in the logs
{code:java}
intx ThreadPriorityPolicy=42 is outside the allowed range [ 0 ... 1 ]
Improperly specified VM option 'ThreadPriorityPolicy=42.'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. The program will exit.
{code}
ThreadPriorityPolicy is an option we use with JDK8. The
upgrade_through_versions_test.py tests use [this multiupgrade
matrix|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_through_versions_test.py#L903-L920]
which starts from versions that do not support JDK11
This issue is only with upgrade_through_versions.py, and it was not initially
seen in CASSANDRA-17869 because those are skipped to run at all in Jenkins. It
appears from the test runs that the rest of the tests are run with JDK 11 and
the suitable options(no issue around ThreadPriorityPolicy observed).
> 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-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=17730205#comment-17730205
]
Marcus Eriksson commented on CASSANDRA-18119:
-
there might have been a followup patch we need? I'll double check
> 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-14667) Upgrade Dropwizard Metrics to 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730196#comment-17730196
]
Maxim Muzafarov edited comment on CASSANDRA-14667 at 6/7/23 4:58 PM:
-
Hello everyone,
I have researched the problem and found a few options that might also work
(none of which are good). Firstly, the problem with just bumping up the
Dropwizard version is that the {{JmxPerporter}} class has moved from the
{{com.codahale.metrics}} package in the 3.x version to the
{{com.codahale.metrics.*jmx*}} package in the 4.x version. We can remove the
dependency of the Cassandra itself from the {{JmxPerporter}} class (I've done
this in the PR), but the cassandra-driver-core 3.1.1 (used in tests now)
requires this class in the classpath to run and as the class has changed the
package we are seeing the ClassNotFoundException.
So what we can do here:
# Stefan has mentioned adding the _withoutMetrics()_, this will solve the
problem, I guess this limits us to using metrics in tests until the driver is
updated;
# I've linked the problems to the driver upgrade: CASSANDRA-15750,
CASSANDRA-17231. This will allow us to easily update the Dropwizard right after
the driver version changes;
# We can use the maven-shade-plugin to relocate classes from the metrics-jmx
(the {{JmxPerporter}} has been moved to it) from com.codahale.metrics.*jmx* to
the com.codahale.metrics package. This copies the classes bytecode into a new
package and create an additional jar. As these classes are fully compatible
(only the package has changed), they can be used by the 3.1.1 driver from the
classpath as they are now used. Drawbacks: maven is used for the build, I
haven't found a corresponding ant for it;
# I've been thinking that as the Dropwizard has the Apache 2.0 licences, we can
copy the {{JmxPerporter}} to our tests (and to the classpath accordingly) with
the _right_ package, so that the required classes will be in the classpath to
run our tests with the old driver until the driver is updated.
I think the first option is our best choice, right?
Thoughts?
was (Author: mmuzaf):
Hello everyone,
I have researched the problem and found a few options that might also work
(none of which are good). Firstly, the problem with just bumping up the
Dropwizard version is that the {{JmxPerporter}} class has moved from the
{{com.codahale.metrics}} package in the 3.x version to the
{{com.codahale.metrics.*jmx*}} package in the 4.x version. We can remove the
dependency of the Cassandra itself from the {{JmxPerporter}} class (I've done
this in the PR), but the cassandra-driver-core 3.1.1 (used in tests now)
requires this class in the classpath to run and as the class has changed the
package we are seeing the ClassNotFoundException.
So what we can do here:
# Stefan has mentioned adding the _withoutMetrics()_, this will solve the
problem, I guess this limits us to using metrics in tests until the driver is
updated;
# I've linked the problems to the driver upgrade: CASSANDRA-15750,
CASSANDRA-17231. This will allow us to easily update the Dropwizard right after
the driver version changes;
# We can use the maven-shade-plugin to relocate classes from the metrics-jmx
(the {{JmxPerporter}} has been moved to it) from com.codahale.metrics.*jmx* to
the com.codahale.metrics package. This copies the classes bytecode into a new
package and create an additional jar. As these classes are fully compatible
(only the package has changed), they can be used by the 3.1.1 driver from the
classpath as they are now used. Drawbacks: maven is used for the build, I
haven't found a corresponding ant for it;
I think the first option is our best choice, right?
Thoughts?
> Upgrade Dropwizard Metrics to 4.x
> -
>
> Key: CASSANDRA-14667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14667
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Stig Rohde Døssing
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for
> Java 9 compatibility. It would be good to upgrade the Metrics library as part
> of the version of Cassandra that adds Java 9 compatibility
> (https://issues.apache.org/jira/browse/CASSANDRA-9608).
--
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=17730201#comment-17730201
]
Yifan Cai commented on CASSANDRASC-50:
--
Some test failures showed on CI. They are unrelated with the patch. Both me and
Francisco ran the test locally and cannot reproduce. I am going ahead to
commit.
> 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-14667) Upgrade Dropwizard Metrics to 4.x
[
https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730196#comment-17730196
]
Maxim Muzafarov commented on CASSANDRA-14667:
-
Hello everyone,
I have researched the problem and found a few options that might also work
(none of which are good). Firstly, the problem with just bumping up the
Dropwizard version is that the {{JmxPerporter}} class has moved from the
{{com.codahale.metrics}} package in the 3.x version to the
{{com.codahale.metrics.*jmx*}} package in the 4.x version. We can remove the
dependency of the Cassandra itself from the {{JmxPerporter}} class (I've done
this in the PR), but the cassandra-driver-core 3.1.1 (used in tests now)
requires this class in the classpath to run and as the class has changed the
package we are seeing the ClassNotFoundException.
So what we can do here:
# Stefan has mentioned adding the _withoutMetrics()_, this will solve the
problem, I guess this limits us to using metrics in tests until the driver is
updated;
# I've linked the problems to the driver upgrade: CASSANDRA-15750,
CASSANDRA-17231. This will allow us to easily update the Dropwizard right after
the driver version changes;
# We can use the maven-shade-plugin to relocate classes from the metrics-jmx
(the {{JmxPerporter}} has been moved to it) from com.codahale.metrics.*jmx* to
the com.codahale.metrics package. This copies the classes bytecode into a new
package and create an additional jar. As these classes are fully compatible
(only the package has changed), they can be used by the 3.1.1 driver from the
classpath as they are now used. Drawbacks: maven is used for the build, I
haven't found a corresponding ant for it;
I think the first option is our best choice, right?
Thoughts?
> Upgrade Dropwizard Metrics to 4.x
> -
>
> Key: CASSANDRA-14667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14667
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Stig Rohde Døssing
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for
> Java 9 compatibility. It would be good to upgrade the Metrics library as part
> of the version of Cassandra that adds Java 9 compatibility
> (https://issues.apache.org/jira/browse/CASSANDRA-9608).
--
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 (d497fe682 -> fa28e0a46)
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 d497fe682 generate docs for 1b144e50 new fa28e0a46 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 (d497fe682) \ N -- N -- N refs/heads/asf-staging (fa28e0a46) 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-18573) TBD
Aleksey Yeschenko created CASSANDRA-18573: - Summary: TBD Key: CASSANDRA-18573 URL: https://issues.apache.org/jira/browse/CASSANDRA-18573 Project: Cassandra Issue Type: Improvement Components: Accord Reporter: Aleksey Yeschenko -- 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-18563) Convert AccordStateCache cache from write-through to write-back
[
https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18563:
--
Description:
Pre-requisite work for soon to go up PRs that continue shifting the bulk of
persistence from system tables to {{AccordJournal}}. The switch to write-back
caching should allow to bypass writes to the system tables entirely for some of
the transactions.
Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to load
an object could cause entries to be forever stuck in {{PENDING}} state because
it would never reach the code path that submits the load runnables to the
executor (that is now the job of the cache). Also switched the list
implementation from a hand-rolled ad-hoc one to the pre-existing
{{IntrusiveLinkedList}}, plus various simplifications and cleanup.
was:
Pre-requisite work for soon to go up PRs that continue shifting the bulk of
persistence from system tables to {{AccordJournal}}. The switch to write-back
caching should allow to bypass writes to the system tables entirely for some of
the transactions.
Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to load
an object could cause entries to be forever stuck in {{PENDING}} state because
it would never reach the code path that submits the load runnables to the
executor (that is now the job of the cache). Also switched the list
implementation from a hand-rolled adhoc one to the pre-existing
{{IntrusiveLinkedList}}, plus various simplifications and cleanup.
> Convert AccordStateCache cache from write-through to write-back
> ---
>
> Key: CASSANDRA-18563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18563
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> Pre-requisite work for soon to go up PRs that continue shifting the bulk of
> persistence from system tables to {{AccordJournal}}. The switch to write-back
> caching should allow to bypass writes to the system tables entirely for some
> of the transactions.
> Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to
> load an object could cause entries to be forever stuck in {{PENDING}} state
> because it would never reach the code path that submits the load runnables to
> the executor (that is now the job of the cache). Also switched the list
> implementation from a hand-rolled ad-hoc one to the pre-existing
> {{IntrusiveLinkedList}}, plus various simplifications and cleanup.
--
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-18563) Convert AccordStateCache cache from write-through to write-back
[
https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18563:
--
Description:
Pre-requisite work for soon to go up PRs that continue shifting the bulk of
persistence from system tables to {{AccordJournal}}. The switch to write-back
caching should allow to bypass writes to the system tables entirely for some of
the transactions.
Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to load
an object could cause entries to be forever stuck in {{PENDING}} state because
it would never reach the code path that submits the load runnables to the
executor (that is now the job of the cache). Also switched the list
implementation from a hand-rolled adhoc one to the pre-existing
{{IntrusiveLinkedList}}, plus various simplifications and cleanup.
> Convert AccordStateCache cache from write-through to write-back
> ---
>
> Key: CASSANDRA-18563
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18563
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 5.0
>
>
> Pre-requisite work for soon to go up PRs that continue shifting the bulk of
> persistence from system tables to {{AccordJournal}}. The switch to write-back
> caching should allow to bypass writes to the system tables entirely for some
> of the transactions.
> Additionally fixes some bugs in the cache, e.g. {{AsyncLoader}} failing to
> load an object could cause entries to be forever stuck in {{PENDING}} state
> because it would never reach the code path that submits the load runnables to
> the executor (that is now the job of the cache). Also switched the list
> implementation from a hand-rolled adhoc one to the pre-existing
> {{IntrusiveLinkedList}}, plus various simplifications and cleanup.
--
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-18563) Convert AccordStateCache cache from write-through to write-back
[ https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730124#comment-17730124 ] Aleksey Yeschenko commented on CASSANDRA-18563: --- PR: [https://github.com/apache/cassandra/pull/2395] > Convert AccordStateCache cache from write-through to write-back > --- > > Key: CASSANDRA-18563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18563 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.0 > > -- 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-18563) Convert AccordStateCache cache from write-through to write-back
[ https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18563: -- Test and Documentation Plan: unit tests Status: Patch Available (was: Open) > Convert AccordStateCache cache from write-through to write-back > --- > > Key: CASSANDRA-18563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18563 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.0 > > -- 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-18563) Convert AccordStateCache cache from write-through to write-back
[ https://issues.apache.org/jira/browse/CASSANDRA-18563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18563: -- Change Category: Performance Complexity: Normal Component/s: Accord Fix Version/s: 5.0 Reviewers: Blake Eggleston Status: Open (was: Triage Needed) > Convert AccordStateCache cache from write-through to write-back > --- > > Key: CASSANDRA-18563 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18563 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 5.0 > > -- 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-11745) Add bytes limit to queries and paging
[ https://issues.apache.org/jira/browse/CASSANDRA-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730103#comment-17730103 ] Josh McKenzie commented on CASSANDRA-11745: --- Still valid; I'll take a look by end of week barring any catastrophe. > Add bytes limit to queries and paging > - > > Key: CASSANDRA-11745 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11745 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Richard Low >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > For some data models, values may be of very different sizes. When querying > data, limit by count doesn’t work well and leads to timeouts. It would be > much better to limit by size of the response, probably by stopping at the > first row that goes above the limit. This applies to paging too so you can > safely page through such data without timeout worries. -- 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-18511) Add support for JMX in the in-jvm dtest framework
[ https://issues.apache.org/jira/browse/CASSANDRA-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730099#comment-17730099 ] Stefan Miklosovic commented on CASSANDRA-18511: --- I would consider this as a follow-up https://issues.apache.org/jira/browse/CASSANDRA-18572 > Add support for JMX in the in-jvm dtest framework > - > > Key: CASSANDRA-18511 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18511 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > Fix For: 3.11.16, 4.0.11, 4.1.3, 5.0 > > Time Spent: 5h 50m > Remaining Estimate: 0h > > In many cases, it would be useful to be able to enable JMX endpoints within > the in-jvm dtest framework, including the existing JMX Getter test, which > used to simply spin up a JMX registry and then leave it running. There are > quite a few JMX-related functions that don’t have tests today, and some > external usages of the in-jvm dtest framework could also benefit from > exposing JMX like we did Native before. -- 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 ] Andres de la Peña updated CASSANDRA-18569: -- Reviewers: Andres de la Peña, Andres de la Peña (was: Andres de la Peña) Andres de la Peña, Andres de la Peña (was: Andres de la Peña) Status: Review In Progress (was: Patch Available) > 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] [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=17730092#comment-17730092 ] Berenguer Blasi commented on CASSANDRA-18553: - I was going to, just waiting on your +1 so thanks. I'll do this next :-) > 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] [Updated] (CASSANDRA-18572) Instance.nodetoolResult should connect to JMX if there is such feature enabled in its config
[ https://issues.apache.org/jira/browse/CASSANDRA-18572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18572: -- Test and Documentation Plan: CI Status: Patch Available (was: In Progress) trunk: https://github.com/apache/cassandra/pull/2394 > Instance.nodetoolResult should connect to JMX if there is such feature > enabled in its config > > > Key: CASSANDRA-18572 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18572 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-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:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18555: -- Status: Patch Available (was: Review In Progress) > 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=17730081#comment-17730081 ] Stefan Miklosovic commented on CASSANDRA-18555: --- It is fully implemented and tested here I believe https://github.com/apache/cassandra/pull/2390/files I created this ticket along the way https://issues.apache.org/jira/browse/CASSANDRA-18572 The PR includes the changes but I feel like we should extract the logic related to JMX in InternalNodeProbe and make it happen for all supported branches and then return to this ticket and finish it while it would be included already. > 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-18572) Instance.nodetoolResult should connect to JMX if there is such feature enabled in its config
[
https://issues.apache.org/jira/browse/CASSANDRA-18572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730074#comment-17730074
]
Stefan Miklosovic edited comment on CASSANDRA-18572 at 6/7/23 11:27 AM:
Instance.nodetoolResult is not using JMX internally but it throws
UnsupportedOperationException in InternalNodeProbe.
This makes calls to instance.nodetoolResult("info"), for example, impossible,
because these commands are using JMX / calling methods which are throwing
exception and it makes the testing painful.
There is no reason to not support this if Instance has JMX feature as it was
added recently.
was (Author: smiklosovic):
Instance.nodetoolResult is not using JMX internally but it throws
UnsupportedOperationException in InternalNodeProbe.
This makes calls to instance.nodetoolResult("info"), for example, impossible,
because these commands are using JMX / calling methods which are throwing
exception and it makes the testing painful.
There is no reason to support this if Instance has JMX feature as it was added
recently.
> Instance.nodetoolResult should connect to JMX if there is such feature
> enabled in its config
>
>
> Key: CASSANDRA-18572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18572
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18572) Instance.nodetoolResult should connect to JMX if there is such feature enabled in its config
[
https://issues.apache.org/jira/browse/CASSANDRA-18572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18572:
--
Change Category: Quality Assurance
Complexity: Normal
Component/s: Test/dtest/java
Fix Version/s: 5.x
Assignee: Stefan Miklosovic
Status: Open (was: Triage Needed)
Instance.nodetoolResult is not using JMX internally but it throws
UnsupportedOperationException in InternalNodeProbe.
This makes calls to instance.nodetoolResult("info"), for example, impossible,
because these commands are using JMX / calling methods which are throwing
exception and it makes the testing painful.
There is no reason to support this if Instance has JMX feature as it was added
recently.
> Instance.nodetoolResult should connect to JMX if there is such feature
> enabled in its config
>
>
> Key: CASSANDRA-18572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18572
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18572) Instance.nodetoolResult should connect to JMX if there is such feature enabled in its config
Stefan Miklosovic created CASSANDRA-18572: - Summary: Instance.nodetoolResult should connect to JMX if there is such feature enabled in its config Key: CASSANDRA-18572 URL: https://issues.apache.org/jira/browse/CASSANDRA-18572 Project: Cassandra Issue Type: Improvement Reporter: Stefan Miklosovic -- 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-11745) Add bytes limit to queries and paging
[ https://issues.apache.org/jira/browse/CASSANDRA-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-11745: --- Reviewers: Benjamin Lerer, Josh McKenzie (was: Josh McKenzie) > Add bytes limit to queries and paging > - > > Key: CASSANDRA-11745 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11745 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Richard Low >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > For some data models, values may be of very different sizes. When querying > data, limit by count doesn’t work well and leads to timeouts. It would be > much better to limit by size of the response, probably by stopping at the > first row that goes above the limit. This applies to paging too so you can > safely page through such data without timeout worries. -- 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 ] Andres de la Peña updated CASSANDRA-18569: -- Reviewers: Andres de la Peña > 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-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 ] Andres de la Peña updated CASSANDRA-17997: -- Fix Version/s: 3.0.30 3.11.16 4.0.11 4.1.3 5.0 (was: 3.0.x) (was: 5.x) (was: 4.0.x) (was: 4.1.x) Source Control Link: https://github.com/apache/cassandra/commit/8d3c30dde4b615835073089594003ca40a730992 Resolution: Fixed Status: Resolved (was: Ready to Commit) > 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.30, 3.11.16, 4.0.11, 4.1.3, 5.0 > > > 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-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=17730050#comment-17730050 ] Andres de la Peña commented on CASSANDRA-18553: --- I've just merged CASSANDRA-17997. > 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] [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 ] Andres de la Peña updated CASSANDRA-17997: -- Status: Ready to Commit (was: Review In Progress) > 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-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730049#comment-17730049 ] Andres de la Peña commented on CASSANDRA-17997: --- Committed to 3.0 as [8d3c30dde4b615835073089594003ca40a730992|https://github.com/apache/cassandra/commit/8d3c30dde4b615835073089594003ca40a730992] and merged to [3.11|https://github.com/apache/cassandra/commit/3855c8a194d1d9ac904429407cb9586a6178e2f0], [4.0|https://github.com/apache/cassandra/commit/2393bb16f308d4d51335a97851646973aceb8066], [4.1|https://github.com/apache/cassandra/commit/2b2d9f9b725546c01017d688211931779565f39d] and [trunk|https://github.com/apache/cassandra/commit/e4f31b73c21b04966269c5ac2d3bd2562e5f6c63]. Thanks for the patch. > 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
[cassandra] branch trunk updated (984f519bd9 -> e4f31b73c2)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 984f519bd9 Merge branch 'cassandra-4.1' into trunk new 8d3c30dde4 Validate the comparison git branch when generating CircleCI configs new 3855c8a194 Merge branch 'cassandra-3.0' into cassandra-3.11 new 2393bb16f3 Merge branch 'cassandra-3.11' into cassandra-4.0 new 2b2d9f9b72 Merge branch 'cassandra-4.0' into cassandra-4.1 new e4f31b73c2 Merge branch 'cassandra-4.1' into trunk The 5 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: .circleci/generate.sh | 19 --- .circleci/generate_11_and_17.sh | 19 --- 2 files changed, 32 insertions(+), 6 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 2393bb16f308d4d51335a97851646973aceb8066 Merge: f368b9dc1e 3855c8a194 Author: Andrés de la Peña AuthorDate: Wed Jun 7 11:04:52 2023 +0100 Merge branch 'cassandra-3.11' into cassandra-4.0 .circleci/generate.sh | 19 --- 1 file changed, 16 insertions(+), 3 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 (03da864bab -> 3855c8a194)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 03da864bab Add keyspace and table name to exception message during ColumnSubselection deserialization new 8d3c30dde4 Validate the comparison git branch when generating CircleCI configs new 3855c8a194 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 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: .circleci/generate.sh | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Validate the comparison git branch when generating CircleCI configs
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new 8d3c30dde4 Validate the comparison git branch when generating CircleCI
configs
8d3c30dde4 is described below
commit 8d3c30dde4b615835073089594003ca40a730992
Author: Derek Chen-Becker
AuthorDate: Mon Nov 7 13:32:01 2022 -0700
Validate the comparison git branch when generating CircleCI configs
Allow the user to use a flag to specify a non-default comparison git
branch when detecting changed unit tests to repeat.
Patch by Derek Chen-Becker; reviewed by Andrés de la Peña and Berenguer
Blasi for CASSANDRA-17997
---
.circleci/generate.sh | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/.circleci/generate.sh b/.circleci/generate.sh
index ee62a9b9da..40bdd205db 100755
--- a/.circleci/generate.sh
+++ b/.circleci/generate.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
#
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements. See the NOTICE file
@@ -30,12 +30,15 @@ die ()
print_help()
{
- echo "Usage: $0 [-f|-p|-a|-e|-i]"
+ echo "Usage: $0 [-f|-p|-a|-e|-i|-b]"
echo " -a Generate the config.yml, config.yml.FREE and config.yml.PAID
expanded configuration"
echo " files from the main config_template.yml reusable configuration
file."
echo " Use this for permanent changes in config that will be committed
to the main repo."
echo " -f Generate config.yml for tests compatible with the CircleCI free
tier resources"
echo " -p Generate config.yml for tests compatible with the CircleCI paid
tier resources"
+ echo " -b Specify the base git branch for comparison when determining
changed tests to"
+ echo " repeat. Defaults to ${BASE_BRANCH}. Note that this option is not
used when"
+ echo " the '-a' option is specified."
echo " -e Environment variables to be used in the generated
config.yml, e.g.:"
echo " -e DTEST_BRANCH=CASSANDRA-8272"
echo " -e
DTEST_REPO=https://github.com/adelapena/cassandra-dtest.git;
@@ -71,7 +74,7 @@ paid=false
env_vars=""
has_env_vars=false
check_env_vars=true
-while getopts "e:afpi" opt; do
+while getopts "e:afpib:" opt; do
case $opt in
a ) all=true
;;
@@ -79,6 +82,8 @@ while getopts "e:afpi" opt; do
;;
p ) paid=true
;;
+ b ) BASE_BRANCH="$OPTARG"
+ ;;
e ) if (!($has_env_vars)); then
env_vars="$OPTARG"
else
@@ -169,6 +174,14 @@ fi
# add new or modified tests to the sets of tests to be repeated
if (!($all)); then
+ # Sanity check that the referenced branch exists
+ if ! git show ${BASE_BRANCH} -- >&/dev/null; then
+echo -e "\n\nUnknown base branch: ${BASE_BRANCH}. Unable to detect changed
tests.\n"
+echo"Please use the '-b' option to choose an existing branch name"
+echo"(e.g. origin/${BASE_BRANCH}, apache/${BASE_BRANCH}, etc.)."
+exit 2
+ fi
+
add_diff_tests ()
{
dir="${BASEDIR}/../${2}"
-
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 (867c074dda -> 2b2d9f9b72)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 867c074dda Merge branch 'cassandra-4.0' into cassandra-4.1 new 8d3c30dde4 Validate the comparison git branch when generating CircleCI configs new 3855c8a194 Merge branch 'cassandra-3.0' into cassandra-3.11 new 2393bb16f3 Merge branch 'cassandra-3.11' into cassandra-4.0 new 2b2d9f9b72 Merge branch 'cassandra-4.0' into cassandra-4.1 The 4 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: .circleci/generate.sh | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit e4f31b73c21b04966269c5ac2d3bd2562e5f6c63
Merge: 984f519bd9 2b2d9f9b72
Author: Andrés de la Peña
AuthorDate: Wed Jun 7 11:07:20 2023 +0100
Merge branch 'cassandra-4.1' into trunk
.circleci/generate.sh | 19 ---
.circleci/generate_11_and_17.sh | 19 ---
2 files changed, 32 insertions(+), 6 deletions(-)
diff --cc .circleci/generate.sh
index 300660f384,2046362370..0c8f4b8223
--- a/.circleci/generate.sh
+++ b/.circleci/generate.sh
@@@ -93,6 -98,6 +96,8 @@@ while getopts "e:afpib:" opt; d
fi
has_env_vars=true
;;
++ b ) BASE_BRANCH="$OPTARG"
++ ;;
i ) check_env_vars=false
;;
\?) die "Invalid option: -$OPTARG"
@@@ -183,6 -188,13 +188,14 @@@ f
# add new or modified tests to the sets of tests to be repeated
if (! ($all)); then
+ # Sanity check that the referenced branch exists
+ if ! git show ${BASE_BRANCH} -- >&/dev/null; then
+ echo -e "\n\nUnknown base branch: ${BASE_BRANCH}. Unable to detect
changed tests.\n"
+ echo"Please use the '-b' option to choose an existing branch name"
+ echo"(e.g. origin/${BASE_BRANCH}, apache/${BASE_BRANCH}, etc.)."
+ exit 2
+ fi
++
add_diff_tests ()
{
dir="${BASEDIR}/../${2}"
diff --cc .circleci/generate_11_and_17.sh
index 029d4a11cb,00..c9c190c4ef
mode 100755,00..100755
--- a/.circleci/generate_11_and_17.sh
+++ b/.circleci/generate_11_and_17.sh
@@@ -1,308 -1,0 +1,321 @@@
- #!/bin/sh
++#!/bin/bash
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+BASEDIR=`dirname $0`
+BASE_BRANCH=trunk
+set -e
+
+die ()
+{
+ echo "ERROR: $*"
+ print_help
+ exit 1
+}
+
+print_help()
+{
- echo "Usage: $0 [-f|-p|-a|-e|-i]"
++ echo "Usage: $0 [-f|-p|-a|-e|-i|-b]"
+ echo " -a Generate the config_11_and_17.yml, config_11_and_17.yml.FREE
and config_11_and_17.yml.PAID expanded configuration"
+ echo " files from the main config_template.yml reusable configuration
file."
+ echo " Use this for permanent changes in config_11_and_17.yml that
will be committed to the main repo."
+ echo " -f Generate config.yml for tests compatible with the CircleCI free
tier resources"
+ echo " -p Generate config.yml for tests compatible with the CircleCI paid
tier resources"
++ echo " -b Specify the base git branch for comparison when determining
changed tests to"
++ echo " repeat. Defaults to ${BASE_BRANCH}. Note that this option is
not used when"
++ echo " the '-a' option is specified."
+ echo " -e Environment variables to be used in the generated
config_11_and_17.yml, e.g.:"
+ echo " -e DTEST_BRANCH=CASSANDRA-8272"
+ echo " -e
DTEST_REPO=https://github.com/adelapena/cassandra-dtest.git;
+ echo " -e REPEATED_TESTS_STOP_ON_FAILURE=false"
+ echo " -e
REPEATED_UTESTS=org.apache.cassandra.cql3.ViewTest#testCountersTable"
+ echo " -e REPEATED_UTESTS_COUNT=500"
+ echo " -e
REPEATED_UTESTS_FQLTOOL=org.apache.cassandra.fqltool.FQLCompareTest"
+ echo " -e REPEATED_UTESTS_FQLTOOL_COUNT=500"
+ echo " -e
REPEATED_UTESTS_LONG=org.apache.cassandra.db.commitlog.CommitLogStressTest"
+ echo " -e REPEATED_UTESTS_LONG_COUNT=100"
+ echo " -e
REPEATED_UTESTS_STRESS=org.apache.cassandra.stress.generate.DistributionGaussianTest"
+ echo " -e REPEATED_UTESTS_STRESS_COUNT=500"
+ echo " -e
REPEATED_SIMULATOR_DTESTS=org.apache.cassandra.simulator.test.TrivialSimulationTest"
+ echo " -e REPEATED_SIMULATOR_DTESTS_COUNT=500"
+ echo " -e
REPEATED_JVM_DTESTS=org.apache.cassandra.distributed.test.PagingTest"
+ echo " -e REPEATED_JVM_DTESTS_COUNT=500"
+ echo " -e REPEATED_DTESTS=cdc_test.py
cqlsh_tests/test_cqlsh.py::TestCqlshSmoke"
+
[cassandra] branch cassandra-4.0 updated (f368b9dc1e -> 2393bb16f3)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from f368b9dc1e Merge branch 'cassandra-3.11' into cassandra-4.0 new 8d3c30dde4 Validate the comparison git branch when generating CircleCI configs new 3855c8a194 Merge branch 'cassandra-3.0' into cassandra-3.11 new 2393bb16f3 Merge branch 'cassandra-3.11' into cassandra-4.0 The 3 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: .circleci/generate.sh | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 3855c8a194d1d9ac904429407cb9586a6178e2f0 Merge: 03da864bab 8d3c30dde4 Author: Andrés de la Peña AuthorDate: Wed Jun 7 11:04:01 2023 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 .circleci/generate.sh | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --cc .circleci/generate.sh index 64d443e211,40bdd205db..f6203d8255 --- a/.circleci/generate.sh +++ b/.circleci/generate.sh @@@ -88,6 -91,6 +91,8 @@@ while getopts "e:afpib:" opt; d fi has_env_vars=true ;; ++ b ) BASE_BRANCH="$OPTARG" ++ ;; i ) check_env_vars=false ;; \?) die "Invalid option: -$OPTARG" - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 2b2d9f9b725546c01017d688211931779565f39d
Merge: 867c074dda 2393bb16f3
Author: Andrés de la Peña
AuthorDate: Wed Jun 7 11:06:41 2023 +0100
Merge branch 'cassandra-4.0' into cassandra-4.1
.circleci/generate.sh | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --cc .circleci/generate.sh
index 29f66a2151,6ae3a5d4b6..2046362370
--- a/.circleci/generate.sh
+++ b/.circleci/generate.sh
@@@ -86,7 -86,7 +89,9 @@@ while getopts "e:afpib:" opt; d
;;
p ) paid=true
;;
- e ) if (!($has_env_vars)); then
++ b ) BASE_BRANCH="$OPTARG"
++ ;;
+ e ) if (! ($has_env_vars)); then
env_vars="$OPTARG"
else
env_vars="$env_vars|$OPTARG"
@@@ -182,7 -181,15 +187,14 @@@ elif (! ($has_env_vars)); the
fi
# add new or modified tests to the sets of tests to be repeated
-if (!($all)); then
+if (! ($all)); then
+ # Sanity check that the referenced branch exists
+ if ! git show ${BASE_BRANCH} -- >&/dev/null; then
+ echo -e "\n\nUnknown base branch: ${BASE_BRANCH}. Unable to detect
changed tests.\n"
+ echo"Please use the '-b' option to choose an existing branch name"
+ echo"(e.g. origin/${BASE_BRANCH}, apache/${BASE_BRANCH}, etc.)."
+ exit 2
+ fi
-
add_diff_tests ()
{
dir="${BASEDIR}/../${2}"
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11745) Add bytes limit to queries and paging
[ https://issues.apache.org/jira/browse/CASSANDRA-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730009#comment-17730009 ] Jacek Lewandowski commented on CASSANDRA-11745: --- https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/715/workflows/af0b5096-96a8-4e97-9aab-a24e486bc11e [~jmckenzie] if your offer to review this is still valid - it is ready to review > Add bytes limit to queries and paging > - > > Key: CASSANDRA-11745 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11745 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Richard Low >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > For some data models, values may be of very different sizes. When querying > data, limit by count doesn’t work well and leads to timeouts. It would be > much better to limit by size of the response, probably by stopping at the > first row that goes above the limit. This applies to paging too so you can > safely page through such data without timeout worries. -- 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-11745) Add bytes limit to queries and paging
[ https://issues.apache.org/jira/browse/CASSANDRA-11745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-11745: -- Test and Documentation Plan: regression tests, new tests Status: Patch Available (was: In Progress) > Add bytes limit to queries and paging > - > > Key: CASSANDRA-11745 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11745 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Richard Low >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > For some data models, values may be of very different sizes. When querying > data, limit by count doesn’t work well and leads to timeouts. It would be > much better to limit by size of the response, probably by stopping at the > first row that goes above the limit. This applies to paging too so you can > safely page through such data without timeout worries. -- 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=17730001#comment-17730001 ] Stefan Miklosovic edited comment on CASSANDRA-18555 at 6/7/23 8:29 AM: --- Yes, [~bereng] , test is not written yet, I didn't want to do that unless we reached an agreement how to proceed here. I think that as long as this goes to 5.0 that is ok. The output should not be changed between minors, major are imho just fine, especially if they are about details like this, adding a line wont kill anybody, does it ... was (Author: smiklosovic): Yes, [~bereng] , test is not written yet, I didn't want to do that unless we reached an agreement how to proceed here. > 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=17730001#comment-17730001 ] Stefan Miklosovic commented on CASSANDRA-18555: --- Yes, [~bereng] , test is not written yet, I didn't want to do that unless we reached an agreement how to proceed here. > 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=17729996#comment-17729996 ] Berenguer Blasi commented on CASSANDRA-18555: - PR seems to be missing CI. And what was the conclusion in the ML about changing the output of commands? iirc they were deemed as public API and needed at least a ML ping (I might be misremembering...) > 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] [Updated] (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:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17047:
Reviewers: Berenguer Blasi, Jacek Lewandowski (was: Jacek Lewandowski)
> 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: 2h
> 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-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=17729989#comment-17729989
]
Berenguer Blasi commented on CASSANDRA-17047:
-
Reviewed as when I offered to take over I had already started reviewing.
Dropped some minor comments. If my eyes aren't fooling me the test hasn't been
repeated to test for flakiness. Otherwise lgtm.
> 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: 2h
> 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
