[jira] [Commented] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[ https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334455#comment-17334455 ] Berenguer Blasi commented on CASSANDRA-16625: - Same here, not a formal review but while you're at it you could make j11 unit tests not require user approval. I think that's just a bug on the ci file wdyt [~e.dimitrova]? As per junit tests I would try to avoid the 'count' approach. That is good for slow tests but for quick tests it's a waste of time. I've had to loop sometimes 10K times a test programmatically and it would take a minute. If I had to do that at sh level or start/stop junit 10K times it would take ages imo. My 2cts. > Add a CircleCI job to run some tests repeatedly > --- > > Key: CASSANDRA-16625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16625 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > I think it could be useful to have an optional CircleCI job to run some > specific tests n times. That way, tickets could attach CircleCI runs showing > that the changes don't make a certain ticket flaky or, conversely, that they > fix a flaky test. Doing this systematically should mitigate the risk of > introducing new flaky tests, and I guess it would be more convenient and easy > to share than running the tests locally or on a private CI system. > It would also be nice to have something similar in Jenkins, but I'm focusing > this ticket on CircleCI because it's available also for non-committers, so > assignees can run their tests before setting the tickets as ready for review. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16634) Garbagecollect should not output all tables to L0 with LeveledCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334450#comment-17334450 ] Scott Carey commented on CASSANDRA-16634: - Excellent. Thanks! > Garbagecollect should not output all tables to L0 with > LeveledCompactionStrategy > > > Key: CASSANDRA-16634 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16634 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Scott Carey >Assignee: Scott Carey >Priority: Normal > Fix For: 3.11.11, 4.0-rc2, 4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > nodetool garbagecollect always outputs to L0 with LeveledCompactionStrategy. > This is awful. On a large LCS table, this means that at the end of the > garbagecollect process, all data is in L0. > > This results in an awful sequence of useless temporary space usage and write > amplification: > # L0 is repeatedly size-tiered compacted until it doesn't have too many > SSTables. If the original LCS table had 2000 tables... this takes a long time > # L0 is compacted to L1 in one to a couple very very large compactions > # L1 is compacted to L2, L3 to L4, etc. Write amplification galore > Due to the above, 'nodetool garbagecollect' is close to worthless for large > LCS tables. A full compaction is always less write amplification and similar > temp disk space required. The only exception is if you can use 'nodetool > garbagecolect' part-way, and then use 'nodetool stop' to cancel it before L0 > is too large. In this case if you are lucky, and the order that it chose to > process SSTables coincides with tables that have the most disk space to > clear, you might free up enough disk space to succeed in your original goal. > > However, from what I can tell, there is no good reason to move the output to > L0. Leaving the output table in the same SSTableLevel as the source table > does not violate any of the LeveledCompactionStrategy placement rules, as the > output by definition has a token range equal to or smaller than the source. > The only drawback is if the size of the output files is significantly smaller > than the source, in which case the source level would be under-sized. But > that seems like a problem that LCS has to handle, not garbagecollect. > LCS could have a "pull up" operation where it does something like the > following. Assume a table has L4 as the max level, and L3 and L4 are both > 'under-sized'. L3 can attempt to 'pull up' any tables from L4 that do not > overlap with the token ranges of the L3 tables. After that, it can choose to > do some compactions that mix L3 and L4 to pull up data into L3 if it is still > significantly under-sized. > From what I can tell, garbagecollect should just re-write tables in place, > and leave the compaction strategy to deal with any consequences. > Moving to L0 is a bad idea. In addition to the extra write amplification and > extreme increase in temporary disk space required, I observed the following: > A 'nodetool garbagecollect' was placing a lot of pressure on a L0 of a node. > We stopped it about 20% through the process, and it managed to compact down > the top couple levels. So we tried to run 'garbagecollect' again, but the > first tables it chose to operate on were in L1, not the 'leafs' in L5! This > was because the order of SSTables chosen currently does not consider the > level, and instead looks purely at the max timestamp in the file. But > because we moved _very old_ data from L5 into L0 as a result of the prior > gabagecollect, manytables in L1 and L2 now had very wide ranges between their > min and max timestamps – essentially some of the oldest and newest data all > in one table. This breaks the usual structure of an LCS table where the > oldest data is at the high levels. > > I hope that others agree that this is a bug, and deserving of a fix. > I have a very simple patch for this that I will be creating a PR for soon. 3 > lines for the code change, 70 lines for a new unit test. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16238) Fix flaky jvm-dtests that fail with Unable to contact any seeds
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334402#comment-17334402
]
David Capwell commented on CASSANDRA-16238:
---
If this is a race reading un-committed data, then the patch below might work
around it (double check locking, but with queues)
Patch:
{code}
$ git diff
diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java
b/src/java/org/apache/cassandra/gms/Gossiper.java
index 699f235bd3..e82b107bac 100644
--- a/src/java/org/apache/cassandra/gms/Gossiper.java
+++ b/src/java/org/apache/cassandra/gms/Gossiper.java
@@ -928,6 +928,11 @@ public class Gossiper implements
IFailureDetectionEventListener, GossiperMBean
{
logger.info("FatClient {} has been silent for {}ms,
removing from gossip", endpoint, fatClientTimeout);
runInGossipStageBlocking(() -> {
+if (!isGossipOnlyMember(endpoint))
+{
+// updating gossip and token metadata are not
atomic, but rely on the single threaded gossip stage
+// since status checks are done outside the gossip
stage, need to confirm the state of the endpoint
+// to make sure that the previous read data was
correct
+logger.info("Race condition marking {} as a
FatClient; ignoring", endpoint);
+return;
+}
removeEndpoint(endpoint); // will put it in
justRemovedEndpoints to respect quarantine delay
evictFromMembership(endpoint); // can get rid of the
state immediately
});
{code}
> Fix flaky jvm-dtests that fail with Unable to contact any seeds
> ---
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16465) Increased Read Latency With Cassandra >= 3.11.7
[ https://issues.apache.org/jira/browse/CASSANDRA-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334381#comment-17334381 ] Nicolai Vest commented on CASSANDRA-16465: -- This is showing the impact of the performance regression for the different versions for a selected TWCS table in our test setup (three C* nodes in one cluster and with just little load). I marked the dates I installed the different versions. For versions 3.11.7 to 3.11.10 SSTable reads are related to the number of total SSTables for that table. For us the impact becomes even more dramatic when the load increases. !image-2021-04-28-02-11-27-298.png|width=486,height=460! [~stefan.miklosovic] Regarding -CASSANDRA-15690- versions affected are [3.0.21|https://issues.apache.org/jira/issues/?jql=project+%3D+CASSANDRA+AND+fixVersion+%3D+3.0.21], [3.11.7|https://issues.apache.org/jira/issues/?jql=project+%3D+CASSANDRA+AND+fixVersion+%3D+3.11.7], [4.0|https://issues.apache.org/jira/issues/?jql=project+%3D+CASSANDRA+AND+fixVersion+%3D+4.0], [4.0-beta1|https://issues.apache.org/jira/issues/?jql=project+%3D+CASSANDRA+AND+fixVersion+%3D+4.0-beta1], ... and newer I guess. > Increased Read Latency With Cassandra >= 3.11.7 > --- > > Key: CASSANDRA-16465 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16465 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ahmed ELJAMI >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot from 2021-04-24 20-50-47.png, > image-2021-04-28-02-11-27-298.png > > > After upgrading Cassandra from 3.11.3 to 3.11.9, Cassandra read latency 99% > increased significantly. Getting back to 3.11.3 immediately fixed the issue. > I have observed "SStable reads" increases after upgrading to 3.11.9. > The same behavior was observed by some other users: > [https://www.mail-archive.com/user@cassandra.apache.org/msg61247.html] > According to Paulo Motta's comment, this behavior may be caused by > https://issues.apache.org/jira/browse/CASSANDRA-15690 which was introduced on > 3.11.7 and removed an optimization that may cause a correctness issue when > there are partition deletions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16465) Increased Read Latency With Cassandra >= 3.11.7
[ https://issues.apache.org/jira/browse/CASSANDRA-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolai Vest updated CASSANDRA-16465: - Attachment: image-2021-04-28-02-11-27-298.png > Increased Read Latency With Cassandra >= 3.11.7 > --- > > Key: CASSANDRA-16465 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16465 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ahmed ELJAMI >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot from 2021-04-24 20-50-47.png, > image-2021-04-28-02-11-27-298.png > > > After upgrading Cassandra from 3.11.3 to 3.11.9, Cassandra read latency 99% > increased significantly. Getting back to 3.11.3 immediately fixed the issue. > I have observed "SStable reads" increases after upgrading to 3.11.9. > The same behavior was observed by some other users: > [https://www.mail-archive.com/user@cassandra.apache.org/msg61247.html] > According to Paulo Motta's comment, this behavior may be caused by > https://issues.apache.org/jira/browse/CASSANDRA-15690 which was introduced on > 3.11.7 and removed an optimization that may cause a correctness issue when > there are partition deletions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16575) "compression" configuration in unit tests is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-16575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16575:
---
Status: Review In Progress (was: Changes Suggested)
> "compression" configuration in unit tests is incorrect
> --
>
> Key: CASSANDRA-16575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16575
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When running unit tests with "compression" configuration, we use non-default
> Snappy compressor.
> There is a misleading fragment of {{build.xml}}:
> {code}
>value="${build.test.dir}/cassandra.compressed.yaml"/>
>
>
>
>
> {code}
> {{cassandra.compressed.yaml}} has been replaced in CASSANDRA-14482 by two
> files {{commitlog_compression_LZ4.yaml}} and
> {{commitlog_compression_Zstd.yaml}} without changing build configuration.
> All in all we could fix that but I doubt it makes any sense since {{cdc}}
> configuration already uses compressed commit log anyway so it feels redundant
> to test compression alone for each CI run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333550#comment-17333550
]
Ekaterina Dimitrova edited comment on CASSANDRA-16637 at 4/27/21, 9:06 PM:
---
/CC [~marcuse] in case you have any hints as I see you were the last one
working in that area of the code as part of CASSANDRA-16552. Not saying that
ticket is the reason for the flakiness, but you might have an idea already on
what is going on. :)
was (Author: e.dimitrova):
/CC [~marcuse] in case you have any hints as I see you were the last working in
that area of the code as part of CASSANDRA-16552. Not saying that ticket is the
reason for the flakiness, but you might have an idea already on what is going
on. :)
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333550#comment-17333550
]
Ekaterina Dimitrova commented on CASSANDRA-16637:
-
/CC [~marcuse] in case you have any hints as I see you were the last working in
that area of the code as part of CASSANDRA-16552. Not saying that ticket is the
reason for the flakiness, but you might have an idea already on what is going
on. :)
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333542#comment-17333542
]
Ekaterina Dimitrova commented on CASSANDRA-16637:
-
I can reproduce it locally, haven't worked on that area of the code but I will
give it a try. If anyone has any hints - feel free to chime in, I will work
more actively on it tomorrow afternoon
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-16637:
---
Assignee: Ekaterina Dimitrova
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16613) ProtocolVersion.V4 is still used in places in the code
[ https://issues.apache.org/jira/browse/CASSANDRA-16613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333521#comment-17333521 ] Ekaterina Dimitrova edited comment on CASSANDRA-16613 at 4/27/21, 8:04 PM: --- Work in progress [here|https://github.com/apache/cassandra/commit/d99f056cb8189c157dd76110542817e0981397dd] Seems to me only the tests need update. I am wondering about a few things though: * DriverBurnTest contains perf tests for V4 and V5 (it was actually testing current beta which is already V6) so I changed the tests to test V4, V5, V6 but then I observed that the perf method calls BurnTestUtil#generateQueryMessage for [version 4|https://github.com/apache/cassandra/commit/d99f056cb8189c157dd76110542817e0981397dd#diff-df33e55e1def1329f9f1c37173fd1af732a6fb636545097f65ce0344079a05f7L81]... So I am wondering which versions we want to leave and I guess I have to update also BurnTestUtil#generateQueryMessage. * I added additional test for version 5 in PagingStateTest, not sure whether mixed versions serialize/deserialize should be added too. * ClientWarningsTest - I decided to leave it to test latest current version instead of 4 [~samt], do you mind to take a look, please, when you have a bit of time? Thanks in advance! was (Author: e.dimitrova): Work in progress [here|https://github.com/apache/cassandra/commit/d99f056cb8189c157dd76110542817e0981397dd] Seems to me only the tests need update. I am wondering about a few things though: * DriverBurnTest contains perf tests for V4 and V5 (it was actually testing current beta which is already V6) so I changed the tests to test V4, V5, V6 but then I observed that the perf method is called BurnTestUtil#generateQueryMessage for [version 4|https://github.com/apache/cassandra/commit/d99f056cb8189c157dd76110542817e0981397dd#diff-df33e55e1def1329f9f1c37173fd1af732a6fb636545097f65ce0344079a05f7L81]... So I am wondering which versions we want to leave and I guess I have to update also BurnTestUtil#generateQueryMessage. * I added additional test for version 5 in PagingStateTest, not sure whether mixed versions serialize/deserialize should be added too. * ClientWarningsTest - I decided to leave it to test latest current version instead of 4 [~samt], do you mind to take a look, please, when you have a bit of time? Thanks in advance! > ProtocolVersion.V4 is still used in places in the code > -- > > Key: CASSANDRA-16613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16613 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc > > > While working on CASSANDRA-16567, [~adelapena] observed that > _ProtocolVersion.V4_ is used in _ViewTest_. > I decided to do a quick grep and observed a list of places where we still > refer to V4 and it seems at least in many of the tests that was left not > intentionally. > This ticket is to verify the usage of _ProtocolVersion.V4_ in the codebase > and bump it to V5 or default version, similar to what was done in > CASSANDRA-16567, wherever there is a need. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16613) ProtocolVersion.V4 is still used in places in the code
[ https://issues.apache.org/jira/browse/CASSANDRA-16613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333521#comment-17333521 ] Ekaterina Dimitrova commented on CASSANDRA-16613: - Work in progress [here|https://github.com/apache/cassandra/commit/d99f056cb8189c157dd76110542817e0981397dd] Seems to me only the tests need update. I am wondering about a few things though: * DriverBurnTest contains perf tests for V4 and V5 (it was actually testing current beta which is already V6) so I changed the tests to test V4, V5, V6 but then I observed that the perf method is called BurnTestUtil#generateQueryMessage for [version 4|https://github.com/apache/cassandra/commit/d99f056cb8189c157dd76110542817e0981397dd#diff-df33e55e1def1329f9f1c37173fd1af732a6fb636545097f65ce0344079a05f7L81]... So I am wondering which versions we want to leave and I guess I have to update also BurnTestUtil#generateQueryMessage. * I added additional test for version 5 in PagingStateTest, not sure whether mixed versions serialize/deserialize should be added too. * ClientWarningsTest - I decided to leave it to test latest current version instead of 4 [~samt], do you mind to take a look, please, when you have a bit of time? Thanks in advance! > ProtocolVersion.V4 is still used in places in the code > -- > > Key: CASSANDRA-16613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16613 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc > > > While working on CASSANDRA-16567, [~adelapena] observed that > _ProtocolVersion.V4_ is used in _ViewTest_. > I decided to do a quick grep and observed a list of places where we still > refer to V4 and it seems at least in many of the tests that was left not > intentionally. > This ticket is to verify the usage of _ProtocolVersion.V4_ in the codebase > and bump it to V5 or default version, similar to what was done in > CASSANDRA-16567, wherever there is a need. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16636) IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
[
https://issues.apache.org/jira/browse/CASSANDRA-16636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16636:
-
Resolution: Not A Problem
Status: Resolved (was: Triage Needed)
Closed.
> IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
> -
>
> Key: CASSANDRA-16636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16636
> Project: Cassandra
> Issue Type: Bug
>Reporter: Misagh Moayyed
>Priority: Normal
>
> Hello, I am running a suite of integration tests against Apache Cassandra v4.
> I may have discovered a possible regression that I thought to share/report.
> Running Apache Cassandra as a Docker image using:
> {code:java}
> docker run --rm --name cassandra -d -p 9042:9042 cassandra:4.0{code}
> produces the following error:
> {code:java}
> com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach any
> contact point, make sure you've provided valid addresses (showing first 1
> nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
> hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]com.datastax.oss.driver.api.core.AllNodesFailedException: Could
> not reach any contact point, make sure you've provided valid addresses
> (showing first 1 nodes, use getAllErrors() for more):
> Node(endPoint=localhost/127.0.0.1:9042, hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]
> at
> com.datastax.oss.driver.api.core.AllNodesFailedException.copy(AllNodesFailedException.java:141)
> at
> com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149)
> at
> com.datastax.oss.driver.api.core.session.SessionBuilder.build(SessionBuilder.java:773)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.initializeCassandraSession(DefaultCassandraSessionFactory.java:78)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.(DefaultCassandraSessionFactory.java:39)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactoryTests.verifyOperation(DefaultCassandraSessionFactoryTests.java:52)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:210)
> at
>
[jira] [Updated] (CASSANDRA-16238) Fix flaky jvm-dtests that fail with Unable to contact any seeds
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16238:
Reviewers: David Capwell (was: David Capwell, Ekaterina Dimitrova)
> Fix flaky jvm-dtests that fail with Unable to contact any seeds
> ---
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[ https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333495#comment-17333495 ] Ekaterina Dimitrova edited comment on CASSANDRA-16625 at 4/27/21, 7:12 PM: --- Not a formal review as my understanding is this is still work in progress. In general it looks good to me, but we need to update the patch files, not directly the MIDRES, HIHRES ones. More info on that [here|https://github.com/apache/cassandra/blob/trunk/.circleci/readme.md]. Also, I think it would be nice to update the readme files and the docs with info about this new option when it is done. Great idea, thanks [~adelapena]! was (Author: e.dimitrova): Not a formal review as my understanding is this is still work in progress. In general it looks good to me, but we need to update the patch files, not directly the MIDRES, HIHRES ones. More info on that [here|https://github.com/apache/cassandra/blob/trunk/.circleci/readme.md]. Also, I think it would be nice to update the readme files and the docs with info about those when it is done. Great idea, thanks [~adelapena]! > Add a CircleCI job to run some tests repeatedly > --- > > Key: CASSANDRA-16625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16625 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > I think it could be useful to have an optional CircleCI job to run some > specific tests n times. That way, tickets could attach CircleCI runs showing > that the changes don't make a certain ticket flaky or, conversely, that they > fix a flaky test. Doing this systematically should mitigate the risk of > introducing new flaky tests, and I guess it would be more convenient and easy > to share than running the tests locally or on a private CI system. > It would also be nice to have something similar in Jenkins, but I'm focusing > this ticket on CircleCI because it's available also for non-committers, so > assignees can run their tests before setting the tickets as ready for review. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[ https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333495#comment-17333495 ] Ekaterina Dimitrova commented on CASSANDRA-16625: - Not a formal review as my understanding is this is still work in progress. In general it looks good to me, but we need to update the patch files, not directly the MIDRES, HIHRES ones. More info on that [here|https://github.com/apache/cassandra/blob/trunk/.circleci/readme.md]. Also, I think it would be nice to update the readme files and the docs with info about those when it is done. Great idea, thanks [~adelapena]! > Add a CircleCI job to run some tests repeatedly > --- > > Key: CASSANDRA-16625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16625 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > I think it could be useful to have an optional CircleCI job to run some > specific tests n times. That way, tickets could attach CircleCI runs showing > that the changes don't make a certain ticket flaky or, conversely, that they > fix a flaky test. Doing this systematically should mitigate the risk of > introducing new flaky tests, and I guess it would be more convenient and easy > to share than running the tests locally or on a private CI system. > It would also be nice to have something similar in Jenkins, but I'm focusing > this ticket on CircleCI because it's available also for non-committers, so > assignees can run their tests before setting the tickets as ready for review. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Update NetBeans classpath after CASSANDRA-16570 (jstackunit) and CASSANDRA-16576 (jflex)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 5578627 Update NetBeans classpath after CASSANDRA-16570 (jstackunit)
and CASSANDRA-16576 (jflex)
5578627 is described below
commit 5578627d74d0c06fcc0f8e1f7a63f7105ccb5d94
Author: Aleksei Zotov
AuthorDate: Tue Apr 27 18:06:44 2021 +0400
Update NetBeans classpath after CASSANDRA-16570 (jstackunit) and
CASSANDRA-16576 (jflex)
patch by Aleksei Zotov; reviewed by Mick Semb Wever
---
ide/nbproject/project.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ide/nbproject/project.xml b/ide/nbproject/project.xml
index 434c8fc..719886d 100644
--- a/ide/nbproject/project.xml
+++ b/ide/nbproject/project.xml
@@ -7,7 +7,7 @@
..
-${project.dir}/build/lib/jars/HdrHistogram-2.1.9.jar:${project.dir}/build/lib/jars/ST4-4.0.8.jar:${project.dir}/build/lib/jars/airline-0.8.jar:${project.dir}/build/lib/jars/antlr-3.5.2.jar:${project.dir}/build/lib/jars/antlr-runtime-3.5.2.jar:${project.dir}/build/lib/jars/asm-7.1.jar:${project.dir}/build/lib/jars/assertj-core-3.15.0.jar:${project.dir}/build/lib/jars/byteman-4.0.6.jar:${project.dir}/build/lib/jars/byteman-bmunit-4.
[...]
+${project.dir}/build/lib/jars/HdrHistogram-2.1.9.jar:${project.dir}/build/lib/jars/ST4-4.0.8.jar:${project.dir}/build/lib/jars/airline-0.8.jar:${project.dir}/build/lib/jars/antlr-3.5.2.jar:${project.dir}/build/lib/jars/antlr-runtime-3.5.2.jar:${project.dir}/build/lib/jars/asm-7.1.jar:${project.dir}/build/lib/jars/assertj-core-3.15.0.jar:${project.dir}/build/lib/jars/byteman-4.0.6.jar:${project.dir}/build/lib/jars/byteman-bmunit-4.
[...]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16636) IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
[
https://issues.apache.org/jira/browse/CASSANDRA-16636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333480#comment-17333480
]
Misagh Moayyed commented on CASSANDRA-16636:
Thank you. That certainly looks to be correct issue. Shall I close this ticket?
> IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
> -
>
> Key: CASSANDRA-16636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16636
> Project: Cassandra
> Issue Type: Bug
>Reporter: Misagh Moayyed
>Priority: Normal
>
> Hello, I am running a suite of integration tests against Apache Cassandra v4.
> I may have discovered a possible regression that I thought to share/report.
> Running Apache Cassandra as a Docker image using:
> {code:java}
> docker run --rm --name cassandra -d -p 9042:9042 cassandra:4.0{code}
> produces the following error:
> {code:java}
> com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach any
> contact point, make sure you've provided valid addresses (showing first 1
> nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
> hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]com.datastax.oss.driver.api.core.AllNodesFailedException: Could
> not reach any contact point, make sure you've provided valid addresses
> (showing first 1 nodes, use getAllErrors() for more):
> Node(endPoint=localhost/127.0.0.1:9042, hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]
> at
> com.datastax.oss.driver.api.core.AllNodesFailedException.copy(AllNodesFailedException.java:141)
> at
> com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149)
> at
> com.datastax.oss.driver.api.core.session.SessionBuilder.build(SessionBuilder.java:773)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.initializeCassandraSession(DefaultCassandraSessionFactory.java:78)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.(DefaultCassandraSessionFactory.java:39)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactoryTests.verifyOperation(DefaultCassandraSessionFactoryTests.java:52)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
>
[jira] [Commented] (CASSANDRA-16636) IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
[
https://issues.apache.org/jira/browse/CASSANDRA-16636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333451#comment-17333451
]
Brandon Williams commented on CASSANDRA-16636:
--
Ah, this looks to be https://datastax-oss.atlassian.net/browse/JAVA-2936
> IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
> -
>
> Key: CASSANDRA-16636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16636
> Project: Cassandra
> Issue Type: Bug
>Reporter: Misagh Moayyed
>Priority: Normal
>
> Hello, I am running a suite of integration tests against Apache Cassandra v4.
> I may have discovered a possible regression that I thought to share/report.
> Running Apache Cassandra as a Docker image using:
> {code:java}
> docker run --rm --name cassandra -d -p 9042:9042 cassandra:4.0{code}
> produces the following error:
> {code:java}
> com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach any
> contact point, make sure you've provided valid addresses (showing first 1
> nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
> hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]com.datastax.oss.driver.api.core.AllNodesFailedException: Could
> not reach any contact point, make sure you've provided valid addresses
> (showing first 1 nodes, use getAllErrors() for more):
> Node(endPoint=localhost/127.0.0.1:9042, hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]
> at
> com.datastax.oss.driver.api.core.AllNodesFailedException.copy(AllNodesFailedException.java:141)
> at
> com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149)
> at
> com.datastax.oss.driver.api.core.session.SessionBuilder.build(SessionBuilder.java:773)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.initializeCassandraSession(DefaultCassandraSessionFactory.java:78)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.(DefaultCassandraSessionFactory.java:39)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactoryTests.verifyOperation(DefaultCassandraSessionFactoryTests.java:52)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
>
[cassandra-website] branch asf-site updated: Fix 3.11.10 and 3.0.24 download names, links and dates.
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/asf-site by this push: new 493bdee Fix 3.11.10 and 3.0.24 download names, links and dates. 493bdee is described below commit 493bdee4d4c943b115d8fce3e5c4a9fa5b2dfe4c Author: mck AuthorDate: Tue Apr 27 19:27:24 2021 +0200 Fix 3.11.10 and 3.0.24 download names, links and dates. --- content/download/index.html | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/download/index.html b/content/download/index.html index 78d09c1..ee436b2 100644 --- a/content/download/index.html +++ b/content/download/index.html @@ -185,9 +185,9 @@ Latest Stable Version Download the latest Apache Cassandra 3.11 release: - Released on 2020-11-04 + Released on 2021-02-01 - https://www.apache.org/dyn/closer.lua/cassandra/3.11.9/apache-cassandra-3.11.9-bin.tar.gz;>3.11.9 (https://downloads.apache.org/cassandra/3.11.9/apache-cassandra-3.11.9-bin.tar.gz.asc;>pgp, https://downloads.apache.org/cassandra/3.11.9/apache-cassandra-3.11.9-bin.tar.gz.sha256;>sha256 and https://downloads.apache.org/cassandra/3.11.9/apache-cassandra-3.11.9-bin.tar.gz.sha512;>sha512) + https://www.apache.org/dyn/closer.lua/cassandra/3.11.10/apache-cassandra-3.11.10-bin.tar.gz;>3.11.10 (https://downloads.apache.org/cassandra/3.11.10/apache-cassandra-3.11.10-bin.tar.gz.asc;>pgp, https://downloads.apache.org/cassandra/3.11.10/apache-cassandra-3.11.10-bin.tar.gz.sha256;>sha256 and https://downloads.apache.org/cassandra/3.11.10/apache-cassandra-3.11.10-bin.tar.gz.sha512;>sha512) @@ -198,8 +198,8 @@ Apache Cassandra 3.0 - Released on 2020-11-04, and supported until 6 months after 4.0 release (date TBD). - https://www.apache.org/dyn/closer.lua/cassandra/3.0.23/apache-cassandra-3.0.23-bin.tar.gz;>3.0.23 (pgp, https://downloads.apache.org/cassandra/3.0.23/apache-cassandra-3.0.23-bin.tar.gz.sha256;>sha256 and https://downloads.apache.org/cassandra/3.0.23/apache-cassandra-3.0.23-bin.tar.gz.sha512;>sha512) + Released on 2021-02-01, and supported until 6 months after 4.0 release (date TBD). + https://www.apache.org/dyn/closer.lua/cassandra/3.0.24/apache-cassandra-3.0.24-bin.tar.gz;>3.0.24 (pgp, https://downloads.apache.org/cassandra/3.0.24/apache-cassandra-3.0.24-bin.tar.gz.sha256;>sha256 and https://downloads.apache.org/cassandra/3.0.24/apache-cassandra-3.0.24-bin.tar.gz.sha512;>sha512) Apache Cassandra 2.2 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
[
https://issues.apache.org/jira/browse/CASSANDRA-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16637:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Local/Compaction/LCS
Discovered By: Unit Test
Fix Version/s: 4.0-rc
Severity: Normal
Status: Open (was: Triage Needed)
> LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
> --
>
> Key: CASSANDRA-16637
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Test is failing occasionally as follows:
> {noformat}
> Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
> at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
> at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
> at
> org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
> at
> org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> {noformat}
> [Recent
> ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16637) LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
Adam Holmberg created CASSANDRA-16637:
-
Summary:
LongLeveledCompactionStrategyCQLTest.stressTestCompactionStrategyManager fails
Key: CASSANDRA-16637
URL: https://issues.apache.org/jira/browse/CASSANDRA-16637
Project: Cassandra
Issue Type: Bug
Reporter: Adam Holmberg
Test is failing occasionally as follows:
{noformat}
Caused by: java.lang.AssertionError: Got unexpected overlap in level 3
at
org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:161)
at
org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:131)
at
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:365)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:312)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:532)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:495)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:743)
at org.apache.cassandra.db.lifecycle.Tracker.notify(Tracker.java:508)
at
org.apache.cassandra.db.lifecycle.Tracker.notifyDiscarded(Tracker.java:502)
at
org.apache.cassandra.db.lifecycle.Tracker.replaceFlushed(Tracker.java:373)
at
org.apache.cassandra.db.ColumnFamilyStore.replaceFlushed(ColumnFamilyStore.java:1592)
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1194)
at
org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1075)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
{noformat}
[Recent
ci|https://ci-cassandra.apache.org/job/Cassandra-trunk/476/testReport/junit/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[
https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1749#comment-1749
]
Andres de la Peña commented on CASSANDRA-16625:
---
[Here|https://github.com/adelapena/cassandra/commit/682aa6082f55f0d508eeaf3d31021ce9363a3f84]
is as simple patch adding jobs to run a specific Python dtest multiple times.
The new jobs are:
* j8_repeated-dtest-with-vnodes
* j8_repeated-dtest-no-vnodes
* 11_repeated-dtest-with-vnodes
* j11_repeated-dtest-no-vnodes
All these jobs are optional and require user approval to start. The name of the
test to run is defined by the env var {{REPEATED_DTEST_PYTHON_TEST_NAME}}. It
can be anything of the form:
* pending_range_test.py
* pending_range_test.py::TestPendingRangeMovements
* pending_range_test.py::TestPendingRangeMovements::test_pending_range
The number of iterations is set in the environment variable
{{REPEATED_DTEST_PYTHON_COUNT}}, which defaults to 100. Sadly I haven't found a
way to introduce these values in the CircleCI UI, so they should be set in the
{{.circleci/config.yml}}, as we do when we want to run a specific dtest branch.
All the jobs use the parallel executor, evenly distributing the test iterations
among the runners. For example, if we use the MIDRES config with a parallelism
of 25 and we want to run a certain test 100 times, each runner will run the
test 4 times.
[Here|https://app.circleci.com/pipelines/github/adelapena/cassandra/305/workflows/827ede69-9a87-4738-a326-4368e94daa0b/jobs/2737]
we can see 100 runs of {{pending_range_test.py}}, which was recently fixed by
CASSANDRA-16614. It has taken less than 3 minutes with HIGHRES.
Also,
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra/304/workflows/e848906f-86e5-4779-a982-b4887570c012/jobs/2729]
we can see 100 runs of the class
{{cqlsh_tests/test_cqlsh.py::TestCqlshSmoke}}, taking around six minutes with
HIGHRES.
> Add a CircleCI job to run some tests repeatedly
> ---
>
> Key: CASSANDRA-16625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16625
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> I think it could be useful to have an optional CircleCI job to run some
> specific tests n times. That way, tickets could attach CircleCI runs showing
> that the changes don't make a certain ticket flaky or, conversely, that they
> fix a flaky test. Doing this systematically should mitigate the risk of
> introducing new flaky tests, and I guess it would be more convenient and easy
> to share than running the tests locally or on a private CI system.
> It would also be nice to have something similar in Jenkins, but I'm focusing
> this ticket on CircleCI because it's available also for non-committers, so
> assignees can run their tests before setting the tickets as ready for review.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[
https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1701#comment-1701
]
Sam Tunnicliffe commented on CASSANDRA-16581:
-
Currently, catching a {{ProtocolException}} in by the pipeline's exception
handler is supposed to close the channel, forcing the client to reconnect. For
v5, this is {{o.a.c.t.ExceptionHandlers.ExceptionHandler}} and for v4 and
lower, {{o.a.c.t.PreV5Handlers.ExceptionHandler}} in trunk and
{{o.a.c.t.Message.ExceptionHandler}} in prior versions. )
{code}
// On protocol exception, close the channel as soon as the message have been
sent
if (cause instanceof ProtocolException)
future.addListener((ChannelFutureListener) f -> ctx.close());
{code}
However, many if not most instances of {{ProtocolException}} are actually
contained in a {{WrappedException}} at this point, so not many actually trigger
this condition. This is changed by David's patches, but we spoke offline and
agreed that this should be reverted for v4- in 3.0, 3.11 and trunk as
reconnections can be expensive, especially on the server side when auth is
enabled.
As David mentioned, this is also a slightly more tricky in v5 as a frame can
contain envelopes for multiple streams. In the case of a fatal error (one which
renders the entire frame unusable), the server is not able to notify the client
of the stream ids present in the frame. To avoid causing a wave of client side
timeouts, we decided to fail fast and close the client connection if any
protocol error is detected.
{quote}
>From a client point of view, a dropped frame will result in request timeouts.
>We have no way of providing a better error, since the stream ids of the failed
>requests are in the corrupt payload. I'm wondering if it might not be better
>to drop the connection all the time: at least the client gets immediate
>feedback (we could try to propagate a cause), instead of a bunch of requests
>timing out for no apparent reason.
[1|https://issues.apache.org/jira/browse/CASSANDRA-15299?focusedCommentId=17099447=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17099447].
{quote}
However, many protocol errors are not fatal; examples include invalid
consistency levels, illegal statements in a BATCH, incorrect opcode. In these
cases, the server _may_ be able to respond appropriately to the invalid
envelope and continue processing the remainder of the frame.
I've pushed a couple of v5 specific commits
[here|https://github.com/beobal/cassandra/tree/16581-trunk-v5]. The general
idea is to attempt to differentiate between so-called protocol errors from
which the server can recover and those from which it can't. With this in mind,
the message processor will return an error response the first time it
encountered a protocol exception, but only terminate the connection if it
immediately encounters a second error on the very next envelope in the frame.
The reason for failing only on consecutive errors is that any individual error
may be recoverable. For instance, a client could send a Frame with 100
envelopes and every other one might have some recoverable corruption. A run of
consecutive errors in the same frame is a heuristic for identifying
non-recoverable corruption, and while not perfect, it seems fairly reasonable
to me.
An exception to this rule is if the body length advertised in the envelope
header is invalid (i.e. < 0). In this case, the message processor is unable to
even attempt to skip over the message, so it throws and closes the connection
immediately.
> Failure to execute queries should emit a KPI other than read
> timeout/unavailable so it can be alerted/tracked
> -
>
> Key: CASSANDRA-16581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16581
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> When we are unable to parse a message we do not have a way to detect this
> from a monitoring point of view so can get into situations where we believe
> the database is fine but the clients are on-fire. This case popped up in the
> 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16238) Fix flaky jvm-dtests that fail with Unable to contact any seeds
[
https://issues.apache.org/jira/browse/CASSANDRA-16238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333296#comment-17333296
]
Brandon Williams commented on CASSANDRA-16238:
--
bq. but we do see this outside of these classes as well.
I haven't seen those yet.
bq. If I understand you, the call to StorageService.onChange (which calls
handleStateNormal) happens-after gossip status check, so removes the state?
It's hard to know the exact order but it's clear from the first few log lines
that the status check and onChange are happening concurrently.
bq. If I understand you correctly, this feels like a race condition where we
read data not fully committed, which feels like a bug (which is why it was set
to 0 in the first place). Do I understand you Brandon Williams?
That may be the case as well, but yes you understand my theory thus far.
> Fix flaky jvm-dtests that fail with Unable to contact any seeds
> ---
>
> Key: CASSANDRA-16238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16238
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: 16238-archived-failures.txt
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/745/workflows/1c7e589e-b5af-4a56-b40a-43da424602c7/jobs/4231
> {code}
> test teardown failure
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795),
> ERROR [main] 2020-10-29 17:38:13,808 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1601)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-16513) Add tool to display or export the contents of a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-16513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16513:
-
Comment: was deleted
(was: Alfa 4 )
> Add tool to display or export the contents of a virtual table
> -
>
> Key: CASSANDRA-16513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16513
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics, Tool/nodetool
>Reporter: Paulo Motta
>Priority: Normal
> Labels: gsoc2021, mentor
>
> Several virtual tables were recently added, but they're currently only
> accessible via cqlsh or programmatically. While this is valuable for many use
> cases, operators are accustomed with the convenience of querying system
> metrics with a simple nodetool command.
> In addition to that, a relatively common request is to provide nodetool
> output in different formats (JSON, YAML and even XML) (CASSANDRA-5977,
> CASSANDRA-12035, CASSANDRA-12486, CASSANDRA-12698, CASSANDRA-12503). However
> this requires lots of manual labor as each nodetool subcommand needs to be
> adapted to support new output formats.
> I propose adding a new CLI tool that will consistently print to the standard
> output the contents of a virtual table. By default the command will print the
> output in a tabular format similar to cqlsh, but a "--format" parameter can
> be specified to modify the output to some other format like JSON or YAML.
> It should be possible to add a limit to the amount of rows displayed and
> filter to display only rows from with specific keys (ie. keyspace or table).
> The command should be flexible and provide simple hooks for registration and
> customization of new virtual tables.
> My vision is that this is a path towards deprecating JMX and toward CQL for
> management, as we move information currently available through JMX to virtual
> tables (as CASSANDRA-14457 did with compactionstats) and easily expose them
> in this new tool as more virtual tables are added. Eventually we can also add
> setters when we start supporting writeable virtual tables.
> I propose calling this tool admintool (naming bikeshedding welcome), for
> example:
> {noformat}
> admintool help
> admintool
> Available subcommands and entities are:
> subcommands:
> - show
> - set (future)
> entities:
> - caches
> - internode_inbound
> - internode_outbound
> - settings
> - sstable_tasks
> - system_properties
> - thread_pools
> nodetool show clients --format yaml
> ...
> nodetool show internode_outboud --format json
> ...
> nodetool show sstabletasks --filter keyspace=my_ks --filter table=my_table
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16635) dml.rst should not list a "!=" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-16635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16635:
-
Resolution: Fixed
Status: Resolved (was: Triage Needed)
Done in e2ee45cc74a725ddd7a5a8e937e15599aab5227a
> dml.rst should not list a "!=" operator
> ---
>
> Key: CASSANDRA-16635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16635
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Nadav Har'El
>Assignee: Brandon Williams
>Priority: Normal
>
> In {{doc/source/cql/dml.rst}} (which ends up in
> [https://cassandra.apache.org/doc/latest/cql/dml.html),] one of the operators
> listed is "!=". However this operator has never been supported in WHERE
> clauses, and I don't see any plans to making it supported.
> The confusion compounds when you notice that the text does refer in a few
> places to "non-equal" or "inequality" operators - but those refer to
> operators like "<=" which are allowed in certain places and not others - not
> to "!=" which isn't allowed anywhere. So "!=" should not be listed at all.
> The Datastax version of this document,
> [https://docs.datastax.com/en/cql-oss/3.3/cql/cql_reference/cqlSelect.html,]
> also doesn't list "!=".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16635) dml.rst should not list a "!=" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-16635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-16635:
Assignee: Brandon Williams
> dml.rst should not list a "!=" operator
> ---
>
> Key: CASSANDRA-16635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16635
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Nadav Har'El
>Assignee: Brandon Williams
>Priority: Normal
>
> In {{doc/source/cql/dml.rst}} (which ends up in
> [https://cassandra.apache.org/doc/latest/cql/dml.html),] one of the operators
> listed is "!=". However this operator has never been supported in WHERE
> clauses, and I don't see any plans to making it supported.
> The confusion compounds when you notice that the text does refer in a few
> places to "non-equal" or "inequality" operators - but those refer to
> operators like "<=" which are allowed in certain places and not others - not
> to "!=" which isn't allowed anywhere. So "!=" should not be listed at all.
> The Datastax version of this document,
> [https://docs.datastax.com/en/cql-oss/3.3/cql/cql_reference/cqlSelect.html,]
> also doesn't list "!=".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Ninja remove '!=' operator from cql doc for CASSANDRA-16635
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new e2ee45c Ninja remove '!=' operator from cql doc for CASSANDRA-16635
e2ee45c is described below
commit e2ee45cc74a725ddd7a5a8e937e15599aab5227a
Author: Brandon Williams
AuthorDate: Tue Apr 27 08:53:32 2021 -0500
Ninja remove '!=' operator from cql doc for CASSANDRA-16635
---
doc/source/cql/dml.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/source/cql/dml.rst b/doc/source/cql/dml.rst
index 1308de5..c5874ab 100644
--- a/doc/source/cql/dml.rst
+++ b/doc/source/cql/dml.rst
@@ -49,7 +49,7 @@ Querying data from data is done using a ``SELECT`` statement:
relation: `column_name` `operator` `term`
: '(' `column_name` ( ',' `column_name` )* ')' `operator`
`tuple_literal`
: TOKEN '(' `column_name` ( ',' `column_name` )* ')' `operator`
`term`
- operator: '=' | '<' | '>' | '<=' | '>=' | '!=' | IN | CONTAINS | CONTAINS
KEY
+ operator: '=' | '<' | '>' | '<=' | '>=' | IN | CONTAINS | CONTAINS KEY
group_by_clause: `column_name` ( ',' `column_name` )*
ordering_clause: `column_name` [ ASC | DESC ] ( ',' `column_name` [ ASC |
DESC ] )*
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16636) IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
[
https://issues.apache.org/jira/browse/CASSANDRA-16636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333242#comment-17333242
]
Brandon Williams commented on CASSANDRA-16636:
--
The fact that cqlsh works means the python driver is working correctly and the
problem is likely somewhere in your code/driver.
> IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
> -
>
> Key: CASSANDRA-16636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16636
> Project: Cassandra
> Issue Type: Bug
>Reporter: Misagh Moayyed
>Priority: Normal
>
> Hello, I am running a suite of integration tests against Apache Cassandra v4.
> I may have discovered a possible regression that I thought to share/report.
> Running Apache Cassandra as a Docker image using:
> {code:java}
> docker run --rm --name cassandra -d -p 9042:9042 cassandra:4.0{code}
> produces the following error:
> {code:java}
> com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach any
> contact point, make sure you've provided valid addresses (showing first 1
> nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
> hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]com.datastax.oss.driver.api.core.AllNodesFailedException: Could
> not reach any contact point, make sure you've provided valid addresses
> (showing first 1 nodes, use getAllErrors() for more):
> Node(endPoint=localhost/127.0.0.1:9042, hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]
> at
> com.datastax.oss.driver.api.core.AllNodesFailedException.copy(AllNodesFailedException.java:141)
> at
> com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149)
> at
> com.datastax.oss.driver.api.core.session.SessionBuilder.build(SessionBuilder.java:773)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.initializeCassandraSession(DefaultCassandraSessionFactory.java:78)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.(DefaultCassandraSessionFactory.java:39)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactoryTests.verifyOperation(DefaultCassandraSessionFactoryTests.java:52)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> at
>
[jira] [Updated] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[ https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16625: -- Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > Add a CircleCI job to run some tests repeatedly > --- > > Key: CASSANDRA-16625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16625 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > I think it could be useful to have an optional CircleCI job to run some > specific tests n times. That way, tickets could attach CircleCI runs showing > that the changes don't make a certain ticket flaky or, conversely, that they > fix a flaky test. Doing this systematically should mitigate the risk of > introducing new flaky tests, and I guess it would be more convenient and easy > to share than running the tests locally or on a private CI system. > It would also be nice to have something similar in Jenkins, but I'm focusing > this ticket on CircleCI because it's available also for non-committers, so > assignees can run their tests before setting the tickets as ready for review. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[
https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333173#comment-17333173
]
Andres de la Peña commented on CASSANDRA-16625:
---
Thanks for the feedback. I'm a few details away from having a CircleCI config
patch for repeatedly running Python dtests, using pytest-repeat in each
parallel test split.
For unit tests and in-JVM dtests I was thinking on adding a {{count}} argument
to {{ant testsome}} doing something similar to what pytest-repeat does, so we
can also use it locally.
> Add a CircleCI job to run some tests repeatedly
> ---
>
> Key: CASSANDRA-16625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16625
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> I think it could be useful to have an optional CircleCI job to run some
> specific tests n times. That way, tickets could attach CircleCI runs showing
> that the changes don't make a certain ticket flaky or, conversely, that they
> fix a flaky test. Doing this systematically should mitigate the risk of
> introducing new flaky tests, and I guess it would be more convenient and easy
> to share than running the tests locally or on a private CI system.
> It would also be nice to have something similar in Jenkins, but I'm focusing
> this ticket on CircleCI because it's available also for non-committers, so
> assignees can run their tests before setting the tickets as ready for review.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333149#comment-17333149 ] Jacek Lewandowski commented on CASSANDRA-16619: --- Thanks you [~blerer], I'll apply the requested changes > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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. samt pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9449cd3d6e3bab2ba43e8f16726689e2618f8c25 Merge: 87a46c3 4763d56 Author: Sam Tunnicliffe AuthorDate: Tue Apr 27 11:57:00 2021 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 .build/build-rat.xml | 18 +- build.xml| 4 +--- 2 files changed, 18 insertions(+), 4 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-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 4763d5625ad225beb3d465c35ea1b9b41ac87009 Merge: ad2f41e 26163bb Author: Sam Tunnicliffe AuthorDate: Tue Apr 27 11:56:07 2021 +0100 Merge branch 'cassandra-2.2' into cassandra-3.0 .build/build-rat.xml | 18 +- build.xml| 4 +--- 2 files changed, 18 insertions(+), 4 deletions(-) diff --cc build.xml index 89e6937,064d16d..6d533eb --- a/build.xml +++ b/build.xml @@@ -1,4 -1,4 +1,3 @@@ --
[cassandra] branch cassandra-3.0 updated (ad2f41e -> 4763d56)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ad2f41e Merge branch 'cassandra-2.2' into cassandra-3.0 add bd27026 Only include versioned files in rat-report new 26163bb Follow up fixes to CASSANDRA-16633 new 4763d56 Merge branch 'cassandra-2.2' into cassandra-3.0 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: .build/build-rat.xml | 18 +- build.xml| 4 +--- 2 files changed, 18 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16633) Only include versioned files in rat-report
[
https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333129#comment-17333129
]
Sam Tunnicliffe commented on CASSANDRA-16633:
-
Thanks, pushed the follow up in {{26163bb12aac590289aab6deabc21fe86371e22a}}
and merged to trunk
> Only include versioned files in rat-report
> --
>
> Key: CASSANDRA-16633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16633
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc2, 4.0
>
>
> Recent changes to the ant build.xml file to include running the Apache Rat
> reporting tool break the build when there are unversioned files in the source
> tree.
> We could modify the build to only include versioned files in the Rat report.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16633) Only include versioned files in rat-report
[ https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16633: Source Control Link: https://github.com/apache/cassandra/commit/5be6d7e6b1ecaaa74d394922afb57c37a132827d https://github.com/apache/cassandra/commit/26163bb12aac590289aab6deabc21fe86371e22a (was: https://github.com/apache/cassandra/commit/5be6d7e6b1ecaaa74d394922afb57c37a132827d) > Only include versioned files in rat-report > -- > > Key: CASSANDRA-16633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16633 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > > Recent changes to the ant build.xml file to include running the Apache Rat > reporting tool break the build when there are unversioned files in the source > tree. > We could modify the build to only include versioned files in the Rat report. -- This message was sent by Atlassian Jira (v8.3.4#803005) - 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 trunk
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 36a0f11221e19b8b21bd57f20e59d6eeb44af36f Merge: 9cda055 9449cd3 Author: Sam Tunnicliffe AuthorDate: Tue Apr 27 12:01:30 2021 +0100 Merge branch 'cassandra-3.11' into trunk .build/build-rat.xml | 18 +- build.xml| 4 +--- 2 files changed, 18 insertions(+), 4 deletions(-) diff --cc .build/build-rat.xml index 02f8750,54bd153..ce4e6f4 --- a/.build/build-rat.xml +++ b/.build/build-rat.xml @@@ -81,4 -92,29 +86,15 @@@ + - - - - - - - - - - - - - + + + + + + + + + + diff --cc build.xml index 566604d,af3256d..347ab6e --- a/build.xml +++ b/build.xml @@@ -2056,9 -1914,7 +2055,8 @@@ - - + - ++ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (9cda055 -> 36a0f11)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9cda055 Merge branch 'cassandra-3.11' into trunk add bd27026 Only include versioned files in rat-report new 26163bb Follow up fixes to CASSANDRA-16633 new 4763d56 Merge branch 'cassandra-2.2' into cassandra-3.0 new 9449cd3 Merge branch 'cassandra-3.0' into cassandra-3.11 new 36a0f11 Merge branch 'cassandra-3.11' into trunk 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: .build/build-rat.xml | 18 +- build.xml| 4 +--- 2 files changed, 18 insertions(+), 4 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 (87a46c3 -> 9449cd3)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 87a46c3 Merge branch 'cassandra-3.0' into cassandra-3.11 add bd27026 Only include versioned files in rat-report new 26163bb Follow up fixes to CASSANDRA-16633 new 4763d56 Merge branch 'cassandra-2.2' into cassandra-3.0 new 9449cd3 Merge branch 'cassandra-3.0' into cassandra-3.11 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: .build/build-rat.xml | 18 +- build.xml| 4 +--- 2 files changed, 18 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated: Follow up fixes to CASSANDRA-16633
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch cassandra-2.2 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-2.2 by this push: new 26163bb Follow up fixes to CASSANDRA-16633 26163bb is described below commit 26163bb12aac590289aab6deabc21fe86371e22a Author: Sam Tunnicliffe AuthorDate: Tue Apr 27 10:16:28 2021 +0100 Follow up fixes to CASSANDRA-16633 * Don't run rat check if git fails or not available * Check for presence of rat.txt before running eclipse-warnings task (to ensure that the report is always generated by CI runs) Patch by Sam Tunnicliffe; reviewed by Mick Semb Wever for CASSANDRA-16633 --- .build/build-rat.xml | 18 +- build.xml| 3 +-- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/.build/build-rat.xml b/.build/build-rat.xml index 6565410..195edc9 100644 --- a/.build/build-rat.xml +++ b/.build/build-rat.xml @@ -33,9 +33,14 @@ - + + + + + + @@ -101,4 +106,15 @@ + + + + + + + + + + + diff --git a/build.xml b/build.xml index 014a77c..064d16d 100644 --- a/build.xml +++ b/build.xml @@ -1920,8 +1920,7 @@ - - + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16636) IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
[
https://issues.apache.org/jira/browse/CASSANDRA-16636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333119#comment-17333119
]
Misagh Moayyed commented on CASSANDRA-16636:
Here is also a copy of the test:
{code:java}
var builder = CqlSession.builder().withKeyspace("cas");
builder.withLocalDatacenter("datacenter1");
builder.build();
{code}
Here is how the Cassandra server is prepared:
{code:java}
echo "Creating Cassandra keyspace: cas"
docker exec cassandra cqlsh -e "CREATE KEYSPACE cas WITH REPLICATION = {'class'
: 'SimpleStrategy', 'replication_factor' : 1}"
echo "Creating Cassandra users table"
docker exec cassandra cqlsh -e "CREATE TABLE cas.users_table ( id UUID PRIMARY
KEY, user_attr text, pwd_attr text )"
echo "Creating Cassandra services table"
docker exec cassandra cqlsh -e "CREATE TABLE cas.casservices ( id bigint
PRIMARY KEY, data text )"
echo "Creating Cassandra user record"
docker exec cassandra cqlsh -e "INSERT INTO cas.users_table
(id,user_attr,pwd_attr) VALUES (6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47,
'casuser','Mellon') USING TTL 86400 AND TIMESTAMP 123456789;"
{code}
> IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
> -
>
> Key: CASSANDRA-16636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16636
> Project: Cassandra
> Issue Type: Bug
>Reporter: Misagh Moayyed
>Priority: Normal
>
> Hello, I am running a suite of integration tests against Apache Cassandra v4.
> I may have discovered a possible regression that I thought to share/report.
> Running Apache Cassandra as a Docker image using:
> {code:java}
> docker run --rm --name cassandra -d -p 9042:9042 cassandra:4.0{code}
> produces the following error:
> {code:java}
> com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach any
> contact point, make sure you've provided valid addresses (showing first 1
> nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
> hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]com.datastax.oss.driver.api.core.AllNodesFailedException: Could
> not reach any contact point, make sure you've provided valid addresses
> (showing first 1 nodes, use getAllErrors() for more):
> Node(endPoint=localhost/127.0.0.1:9042, hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]
> at
> com.datastax.oss.driver.api.core.AllNodesFailedException.copy(AllNodesFailedException.java:141)
> at
> com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149)
> at
> com.datastax.oss.driver.api.core.session.SessionBuilder.build(SessionBuilder.java:773)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.initializeCassandraSession(DefaultCassandraSessionFactory.java:78)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.(DefaultCassandraSessionFactory.java:39)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactoryTests.verifyOperation(DefaultCassandraSessionFactoryTests.java:52)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
>
[jira] [Comment Edited] (CASSANDRA-16636) IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
[
https://issues.apache.org/jira/browse/CASSANDRA-16636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333119#comment-17333119
]
Misagh Moayyed edited comment on CASSANDRA-16636 at 4/27/21, 10:45 AM:
---
Here is also a copy of the test:
{code:java}
var builder = CqlSession.builder().withKeyspace("cas");
builder.withLocalDatacenter("datacenter1");
builder.build();
{code}
Here is how the Cassandra server is prepared after the Docker container is run:
{code:java}
echo "Creating Cassandra keyspace: cas"
docker exec cassandra cqlsh -e "CREATE KEYSPACE cas WITH REPLICATION = {'class'
: 'SimpleStrategy', 'replication_factor' : 1}"
echo "Creating Cassandra users table"
docker exec cassandra cqlsh -e "CREATE TABLE cas.users_table ( id UUID PRIMARY
KEY, user_attr text, pwd_attr text )"
echo "Creating Cassandra services table"
docker exec cassandra cqlsh -e "CREATE TABLE cas.casservices ( id bigint
PRIMARY KEY, data text )"
echo "Creating Cassandra user record"
docker exec cassandra cqlsh -e "INSERT INTO cas.users_table
(id,user_attr,pwd_attr) VALUES (6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47,
'casuser','Mellon') USING TTL 86400 AND TIMESTAMP 123456789;"
{code}
was (Author: mmoayyed):
Here is also a copy of the test:
{code:java}
var builder = CqlSession.builder().withKeyspace("cas");
builder.withLocalDatacenter("datacenter1");
builder.build();
{code}
Here is how the Cassandra server is prepared:
{code:java}
echo "Creating Cassandra keyspace: cas"
docker exec cassandra cqlsh -e "CREATE KEYSPACE cas WITH REPLICATION = {'class'
: 'SimpleStrategy', 'replication_factor' : 1}"
echo "Creating Cassandra users table"
docker exec cassandra cqlsh -e "CREATE TABLE cas.users_table ( id UUID PRIMARY
KEY, user_attr text, pwd_attr text )"
echo "Creating Cassandra services table"
docker exec cassandra cqlsh -e "CREATE TABLE cas.casservices ( id bigint
PRIMARY KEY, data text )"
echo "Creating Cassandra user record"
docker exec cassandra cqlsh -e "INSERT INTO cas.users_table
(id,user_attr,pwd_attr) VALUES (6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47,
'casuser','Mellon') USING TTL 86400 AND TIMESTAMP 123456789;"
{code}
> IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
> -
>
> Key: CASSANDRA-16636
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16636
> Project: Cassandra
> Issue Type: Bug
>Reporter: Misagh Moayyed
>Priority: Normal
>
> Hello, I am running a suite of integration tests against Apache Cassandra v4.
> I may have discovered a possible regression that I thought to share/report.
> Running Apache Cassandra as a Docker image using:
> {code:java}
> docker run --rm --name cassandra -d -p 9042:9042 cassandra:4.0{code}
> produces the following error:
> {code:java}
> com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach any
> contact point, make sure you've provided valid addresses (showing first 1
> nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
> hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]com.datastax.oss.driver.api.core.AllNodesFailedException: Could
> not reach any contact point, make sure you've provided valid addresses
> (showing first 1 nodes, use getAllErrors() for more):
> Node(endPoint=localhost/127.0.0.1:9042, hostId=null, hashCode=7369ba0):
> [com.datastax.oss.driver.api.core.connection.ConnectionInitException:
> [s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
> Protocol initialization request, step 1 (OPTIONS): unexpected failure
> (java.lang.IllegalArgumentException: Unsupported request opcode: 0 in
> protocol 6)]
> at
> com.datastax.oss.driver.api.core.AllNodesFailedException.copy(AllNodesFailedException.java:141)
> at
> com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149)
> at
> com.datastax.oss.driver.api.core.session.SessionBuilder.build(SessionBuilder.java:773)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.initializeCassandraSession(DefaultCassandraSessionFactory.java:78)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactory.(DefaultCassandraSessionFactory.java:39)
> at
> org.apereo.cas.cassandra.DefaultCassandraSessionFactoryTests.verifyOperation(DefaultCassandraSessionFactoryTests.java:52)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
>
[jira] [Commented] (CASSANDRA-16633) Only include versioned files in rat-report
[ https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333120#comment-17333120 ] Michael Semb Wever commented on CASSANDRA-16633: bq. Pushed a small follow up with a couple of fixes for CI here (2.2 only, I'll merge to other branches on commit) +1 > Only include versioned files in rat-report > -- > > Key: CASSANDRA-16633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16633 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > > Recent changes to the ant build.xml file to include running the Apache Rat > reporting tool break the build when there are unversioned files in the source > tree. > We could modify the build to only include versioned files in the Rat report. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16636) IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
[
https://issues.apache.org/jira/browse/CASSANDRA-16636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misagh Moayyed updated CASSANDRA-16636:
---
Description:
Hello, I am running a suite of integration tests against Apache Cassandra v4. I
may have discovered a possible regression that I thought to share/report.
Running Apache Cassandra as a Docker image using:
{code:java}
docker run --rm --name cassandra -d -p 9042:9042 cassandra:4.0{code}
produces the following error:
{code:java}
com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach any
contact point, make sure you've provided valid addresses (showing first 1
nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
hostId=null, hashCode=7369ba0):
[com.datastax.oss.driver.api.core.connection.ConnectionInitException:
[s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
Protocol initialization request, step 1 (OPTIONS): unexpected failure
(java.lang.IllegalArgumentException: Unsupported request opcode: 0 in protocol
6)]com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach
any contact point, make sure you've provided valid addresses (showing first 1
nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
hostId=null, hashCode=7369ba0):
[com.datastax.oss.driver.api.core.connection.ConnectionInitException:
[s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
Protocol initialization request, step 1 (OPTIONS): unexpected failure
(java.lang.IllegalArgumentException: Unsupported request opcode: 0 in protocol
6)]
at
com.datastax.oss.driver.api.core.AllNodesFailedException.copy(AllNodesFailedException.java:141)
at
com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149)
at
com.datastax.oss.driver.api.core.session.SessionBuilder.build(SessionBuilder.java:773)
at
org.apereo.cas.cassandra.DefaultCassandraSessionFactory.initializeCassandraSession(DefaultCassandraSessionFactory.java:78)
at
org.apereo.cas.cassandra.DefaultCassandraSessionFactory.(DefaultCassandraSessionFactory.java:39)
at
org.apereo.cas.cassandra.DefaultCassandraSessionFactoryTests.verifyOperation(DefaultCassandraSessionFactoryTests.java:52)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:210)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:206)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:131)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:65)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
[jira] [Updated] (CASSANDRA-16636) IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
[
https://issues.apache.org/jira/browse/CASSANDRA-16636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misagh Moayyed updated CASSANDRA-16636:
---
Description:
Hello, I am running a suite of integration tests against Apache Cassandra v4. I
may have discovered a possible regression that I thought to share/report.
Running Apache Cassandra as a Docker image using:
{code:java}
docker run --rm --name cassandra -d -p 9042:9042 cassandra:4.0{code}
produces the following error:
{code:java}
com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach any
contact point, make sure you've provided valid addresses (showing first 1
nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
hostId=null, hashCode=7369ba0):
[com.datastax.oss.driver.api.core.connection.ConnectionInitException:
[s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
Protocol initialization request, step 1 (OPTIONS): unexpected failure
(java.lang.IllegalArgumentException: Unsupported request opcode: 0 in protocol
6)]com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach
any contact point, make sure you've provided valid addresses (showing first 1
nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
hostId=null, hashCode=7369ba0):
[com.datastax.oss.driver.api.core.connection.ConnectionInitException:
[s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
Protocol initialization request, step 1 (OPTIONS): unexpected failure
(java.lang.IllegalArgumentException: Unsupported request opcode: 0 in protocol
6)]
at
com.datastax.oss.driver.api.core.AllNodesFailedException.copy(AllNodesFailedException.java:141)
at
com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149)
at
com.datastax.oss.driver.api.core.session.SessionBuilder.build(SessionBuilder.java:773)
at
org.apereo.cas.cassandra.DefaultCassandraSessionFactory.initializeCassandraSession(DefaultCassandraSessionFactory.java:78)
at
org.apereo.cas.cassandra.DefaultCassandraSessionFactory.(DefaultCassandraSessionFactory.java:39)
at
org.apereo.cas.cassandra.DefaultCassandraSessionFactoryTests.verifyOperation(DefaultCassandraSessionFactoryTests.java:52)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:210)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:206)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:131)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:65)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
[jira] [Created] (CASSANDRA-16636) IllegalArgumentException: Unsupported request opcode: 0 in protocol 6
Misagh Moayyed created CASSANDRA-16636:
--
Summary: IllegalArgumentException: Unsupported request opcode: 0
in protocol 6
Key: CASSANDRA-16636
URL: https://issues.apache.org/jira/browse/CASSANDRA-16636
Project: Cassandra
Issue Type: Bug
Reporter: Misagh Moayyed
Hello, I am running a suite of integration tests against Apache Cassandra v4. I
may have discovered a possible regression that I though to share/report.
Running Apache Cassandra as a Docker image using:
{code:java}
docker run --rm --name cassandra -d -p 9042:9042 cassandra:4.0{code}
produces the following error:
{code:java}
com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach any
contact point, make sure you've provided valid addresses (showing first 1
nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
hostId=null, hashCode=7369ba0):
[com.datastax.oss.driver.api.core.connection.ConnectionInitException:
[s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
Protocol initialization request, step 1 (OPTIONS): unexpected failure
(java.lang.IllegalArgumentException: Unsupported request opcode: 0 in protocol
6)]com.datastax.oss.driver.api.core.AllNodesFailedException: Could not reach
any contact point, make sure you've provided valid addresses (showing first 1
nodes, use getAllErrors() for more): Node(endPoint=localhost/127.0.0.1:9042,
hostId=null, hashCode=7369ba0):
[com.datastax.oss.driver.api.core.connection.ConnectionInitException:
[s0|control|id: 0x8cf56198, L:/127.0.0.1:51616 - R:localhost/127.0.0.1:9042]
Protocol initialization request, step 1 (OPTIONS): unexpected failure
(java.lang.IllegalArgumentException: Unsupported request opcode: 0 in protocol
6)]
at
com.datastax.oss.driver.api.core.AllNodesFailedException.copy(AllNodesFailedException.java:141)
at
com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149)
at
com.datastax.oss.driver.api.core.session.SessionBuilder.build(SessionBuilder.java:773)
at
org.apereo.cas.cassandra.DefaultCassandraSessionFactory.initializeCassandraSession(DefaultCassandraSessionFactory.java:78)
at
org.apereo.cas.cassandra.DefaultCassandraSessionFactory.(DefaultCassandraSessionFactory.java:39)
at
org.apereo.cas.cassandra.DefaultCassandraSessionFactoryTests.verifyOperation(DefaultCassandraSessionFactoryTests.java:52)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:688)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$6(TestMethodTestDescriptor.java:210)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:206)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:131)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:65)
at
[jira] [Commented] (CASSANDRA-16633) Only include versioned files in rat-report
[ https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333109#comment-17333109 ] Michael Semb Wever commented on CASSANDRA-16633: [!https://ci-cassandra.apache.org/job/Cassandra-devbranch-artifacts/691/badge/icon!|https://ci-cassandra.apache.org/job/Cassandra-devbranch-artifacts/691/] > Only include versioned files in rat-report > -- > > Key: CASSANDRA-16633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16633 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > > Recent changes to the ant build.xml file to include running the Apache Rat > reporting tool break the build when there are unversioned files in the source > tree. > We could modify the build to only include versioned files in the Rat report. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16633) Only include versioned files in rat-report
[ https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333098#comment-17333098 ] Sam Tunnicliffe edited comment on CASSANDRA-16633 at 4/27/21, 10:15 AM: Pushed a small follow up with a couple of fixes for CI [here|https://github.com/beobal/cassandra/commit/26163bb12aac590289aab6deabc21fe86371e22a] (2.2 only, I'll merge to other branches on commit) was (Author: beobal): Pushed a small follow up with a couple of fixes for CI [here|https://github.com/beobal/cassandra/commit/26163bb12aac590289aab6deabc21fe86371e22a] > Only include versioned files in rat-report > -- > > Key: CASSANDRA-16633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16633 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > > Recent changes to the ant build.xml file to include running the Apache Rat > reporting tool break the build when there are unversioned files in the source > tree. > We could modify the build to only include versioned files in the Rat report. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16633) Only include versioned files in rat-report
[ https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333098#comment-17333098 ] Sam Tunnicliffe commented on CASSANDRA-16633: - Pushed a small follow up with a couple of fixes for CI [here|https://github.com/beobal/cassandra/commit/26163bb12aac590289aab6deabc21fe86371e22a] > Only include versioned files in rat-report > -- > > Key: CASSANDRA-16633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16633 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > > Recent changes to the ant build.xml file to include running the Apache Rat > reporting tool break the build when there are unversioned files in the source > tree. > We could modify the build to only include versioned files in the Rat report. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16627) Flaky DirectoriesTest.testSecondaryIndexDirectories
[
https://issues.apache.org/jira/browse/CASSANDRA-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333061#comment-17333061
]
Berenguer Blasi edited comment on CASSANDRA-16627 at 4/27/21, 10:03 AM:
I didn't manage to repro. But the only reasonable path I can think of is there
has to be some cross test talk at the file system level. I have pushed a
version which is not final but:
- Has further isolation across test methods
- Provides a runner to run the test class N times
I would propose we review the improved isolated test. If we like it then remove
the repeatability and commit along the repeatable runner which may come in
handy some other time.
{noformat}
Testsuite: org.apache.cassandra.db.DirectoriesTest Tests run: 15000, Failures:
0, Errors: 0, Skipped: 0, Time elapsed: 24.579 sec
{noformat}
If sbdy has better ideas I am all ears :-)
was (Author: bereng):
I didn't manage to repro. But the only reasonable path I can think of is there
has to be some cross test talk at the file system level. I have pushed a
version which is not final but:
- Has further isolation across test methods
- Provides a runner to run the test class N times
I would propose we review the improved isolated test. If we like it then remove
the repeatability and commit along the repeatable runner which may come in
handy some other time.
If sbdy has better ideas I am all ears :-)
> Flaky DirectoriesTest.testSecondaryIndexDirectories
> ---
>
> Key: CASSANDRA-16627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16627
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/462/testReport/junit/org.apache.cassandra.db/DirectoriesTest/testSecondaryIndexDirectories_cdc/]
> {noformat}
> Error Message
> expected:<1619094213489> but was:<1619094213485>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1619094213489> but
> was:<1619094213485>
> at
> org.apache.cassandra.db.DirectoriesTest.testSecondaryIndexDirectories(DirectoriesTest.java:216)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16627) Flaky DirectoriesTest.testSecondaryIndexDirectories
[
https://issues.apache.org/jira/browse/CASSANDRA-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333061#comment-17333061
]
Berenguer Blasi edited comment on CASSANDRA-16627 at 4/27/21, 9:25 AM:
---
I didn't manage to repro. But the only reasonable path I can think of is there
has to be some cross test talk at the file system level. I have pushed a
version which is not final but:
- Has further isolation across test methods
- Provides a runner to run the test class N times
I would propose we review the improved isolated test. If we like it then remove
the repeatability and commit along the repeatable runner which may come in
handy some other time.
If sbdy has better ideas I am all ears :-)
was (Author: bereng):
I didn't manage to repro. But the only reasonable path I can think of is there
has to be some cross test talk at the file system level. I have pushed a
version which is not final but:
- Has further isolation across test methods
- Provides a runner to run the test class N times
I would propose we review the improved isolated test. If we like it then remove
the repeatability and commit along the repeatable runner which may come in
handy some other time.
> Flaky DirectoriesTest.testSecondaryIndexDirectories
> ---
>
> Key: CASSANDRA-16627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16627
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/462/testReport/junit/org.apache.cassandra.db/DirectoriesTest/testSecondaryIndexDirectories_cdc/]
> {noformat}
> Error Message
> expected:<1619094213489> but was:<1619094213485>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1619094213489> but
> was:<1619094213485>
> at
> org.apache.cassandra.db.DirectoriesTest.testSecondaryIndexDirectories(DirectoriesTest.java:216)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16627) Flaky DirectoriesTest.testSecondaryIndexDirectories
[
https://issues.apache.org/jira/browse/CASSANDRA-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16627:
Test and Documentation Plan: See PR
Status: Patch Available (was: In Progress)
> Flaky DirectoriesTest.testSecondaryIndexDirectories
> ---
>
> Key: CASSANDRA-16627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16627
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/462/testReport/junit/org.apache.cassandra.db/DirectoriesTest/testSecondaryIndexDirectories_cdc/]
> {noformat}
> Error Message
> expected:<1619094213489> but was:<1619094213485>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1619094213489> but
> was:<1619094213485>
> at
> org.apache.cassandra.db.DirectoriesTest.testSecondaryIndexDirectories(DirectoriesTest.java:216)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[ https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333063#comment-17333063 ] Berenguer Blasi commented on CASSANDRA-16625: - I have found sometimes the sh loop approach is a pain when the test happen to be a quick one. I need to run a test class N times fast rather than waiting 90% of the time for sh/ant to loop. I added a repeatable runner chasing a bug [here|https://github.com/apache/cassandra/pull/987/files#diff-3b232ce364185d49c362ae79ed940d43bb9acc2c90d8e996ae1f4bae2d611b35R1] that I find useful. I hope it serves inspiration for sthg more flexible and generic when we tackle this ticket. > Add a CircleCI job to run some tests repeatedly > --- > > Key: CASSANDRA-16625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16625 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > I think it could be useful to have an optional CircleCI job to run some > specific tests n times. That way, tickets could attach CircleCI runs showing > that the changes don't make a certain ticket flaky or, conversely, that they > fix a flaky test. Doing this systematically should mitigate the risk of > introducing new flaky tests, and I guess it would be more convenient and easy > to share than running the tests locally or on a private CI system. > It would also be nice to have something similar in Jenkins, but I'm focusing > this ticket on CircleCI because it's available also for non-committers, so > assignees can run their tests before setting the tickets as ready for review. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16627) Flaky DirectoriesTest.testSecondaryIndexDirectories
[
https://issues.apache.org/jira/browse/CASSANDRA-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333061#comment-17333061
]
Berenguer Blasi commented on CASSANDRA-16627:
-
I didn't manage to repro. But the only reasonable path I can think of is there
has to be some cross test talk at the file system level. I have pushed a
version which is not final but:
- Has further isolation across test methods
- Provides a runner to run the test class N times
I would propose we review the improved isolated test. If we like it then remove
the repeatability and commit along the repeatable runner which may come in
handy some other time.
> Flaky DirectoriesTest.testSecondaryIndexDirectories
> ---
>
> Key: CASSANDRA-16627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16627
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/462/testReport/junit/org.apache.cassandra.db/DirectoriesTest/testSecondaryIndexDirectories_cdc/]
> {noformat}
> Error Message
> expected:<1619094213489> but was:<1619094213485>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1619094213489> but
> was:<1619094213485>
> at
> org.apache.cassandra.db.DirectoriesTest.testSecondaryIndexDirectories(DirectoriesTest.java:216)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16633) Only include versioned files in rat-report
[ https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16633: --- Fix Version/s: 4.0 > Only include versioned files in rat-report > -- > > Key: CASSANDRA-16633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16633 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > > Recent changes to the ant build.xml file to include running the Apache Rat > reporting tool break the build when there are unversioned files in the source > tree. > We could modify the build to only include versioned files in the Rat report. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16633) Only include versioned files in rat-report
[
https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16633:
Fix Version/s: (was: 3.11.x)
(was: 3.0.x)
(was: 2.2.x)
3.11.11
3.0.25
2.2.20
Since Version: 4.0-rc1
Source Control Link:
https://github.com/apache/cassandra/commit/5be6d7e6b1ecaaa74d394922afb57c37a132827d
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks both, committed with [~mck]'s suggestions to 2.2 in
{{5be6d7e6b1ecaaa74d394922afb57c37a132827d}} and merged up.
> Only include versioned files in rat-report
> --
>
> Key: CASSANDRA-16633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16633
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 2.2.20, 3.0.25, 3.11.11, 4.0-rc2
>
>
> Recent changes to the ant build.xml file to include running the Apache Rat
> reporting tool break the build when there are unversioned files in the source
> tree.
> We could modify the build to only include versioned files in the Rat report.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16633) Only include versioned files in rat-report
[ https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16633: Status: Ready to Commit (was: Review In Progress) > Only include versioned files in rat-report > -- > > Key: CASSANDRA-16633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16633 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-rc2, 2.2.x, 3.0.x, 3.11.x > > > Recent changes to the ant build.xml file to include running the Apache Rat > reporting tool break the build when there are unversioned files in the source > tree. > We could modify the build to only include versioned files in the Rat report. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (f5a0c4c -> 9cda055)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f5a0c4c Merge branch 'cassandra-3.11' into trunk new 5be6d7e Only include versioned files in rat-report new ad2f41e Merge branch 'cassandra-2.2' into cassandra-3.0 new 87a46c3 Merge branch 'cassandra-3.0' into cassandra-3.11 new 9cda055 Merge branch 'cassandra-3.11' into trunk 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: .build/build-rat.xml | 102 +++-- .build/build-resolver.xml | 30 +++--- build.xml | 32 +++ doc/source/_templates/indexcontent.html| 16 doc/source/_theme/cassandra_theme/defindex.html| 16 doc/source/_theme/cassandra_theme/layout.html | 16 doc/source/_theme/cassandra_theme/search.html | 16 .../org/apache/cassandra/stress/graph/graph.html | 17 +++- 8 files changed, 163 insertions(+), 82 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 02/02: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ad2f41ef88784cd4fa0073688a247ebd2b77dd89 Merge: e9cf21b 5be6d7e Author: Sam Tunnicliffe AuthorDate: Tue Apr 27 09:08:44 2021 +0100 Merge branch 'cassandra-2.2' into cassandra-3.0 .build/build-rat.xml | 99 build.xml| 32 - 2 files changed, 68 insertions(+), 63 deletions(-) diff --cc .build/build-rat.xml index 468c671,730899b..fd1b0f3 --- a/.build/build-rat.xml +++ b/.build/build-rat.xml @@@ -37,34 -32,46 +32,46 @@@ - + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ ++ - 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.
samt pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 87a46c36f0a54c608a01d026a3d7816137fbbb69
Merge: a68a7c5 ad2f41e
Author: Sam Tunnicliffe
AuthorDate: Tue Apr 27 09:19:29 2021 +0100
Merge branch 'cassandra-3.0' into cassandra-3.11
.build/build-rat.xml | 100 +++--
build.xml | 32 ---
doc/source/_templates/indexcontent.html| 16
doc/source/_theme/cassandra_theme/defindex.html| 16
doc/source/_theme/cassandra_theme/layout.html | 16
doc/source/_theme/cassandra_theme/search.html | 16
.../org/apache/cassandra/stress/graph/graph.html | 17 +++-
7 files changed, 148 insertions(+), 65 deletions(-)
diff --cc .build/build-rat.xml
index cfb3c8b,fd1b0f3..4a6ebfc
--- a/.build/build-rat.xml
+++ b/.build/build-rat.xml
@@@ -38,34 -32,46 +32,46 @@@
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
diff --cc doc/source/_templates/indexcontent.html
index a95191c,000..eaaaca5
mode 100644,00..100644
--- a/doc/source/_templates/indexcontent.html
+++ b/doc/source/_templates/indexcontent.html
@@@ -1,75 -1,0 +1,91 @@@
++
+{% extends "layout.html" %}
+{%- block htmltitle -%}
+{{ html_title }}
+{%- endblock -%}
+{% block body %}
+ {{ docstitle|e }}
+
+ {% trans %}Welcome! This is the documentation for Apache Cassandra {{
version }}.{% endtrans %}
+
+This documentation is a work-in-progress.
+Contributions are welcome.
+
+Main documentation
+
+
+
+
+ {% trans %}Getting started{% endtrans
%}
+ {% trans %}Newbie friendly starting point{%
endtrans %}
+
+
+ {% trans %}Operating Cassandra{% endtrans
%}
+ {% trans %}The operator's corner{% endtrans
%}
+
+
+
+
+ {% trans %}Cassandra Architecture{% endtrans
%}
+ {% trans %}Cassandra's big picture{% endtrans
%}
+
+
+ {% trans %}Cassandra's Tools{% endtrans %}
+ {% trans %}cqlsh, nodetool, ...{% endtrans
%}
+
+
+
+
+ {% trans %}Data Modeling{% endtrans
%}
+ {% trans %}Or how to make square pegs fit round
holes{% endtrans %}
+
+
+ {% trans %}Troubleshooting{% endtrans
%}
+ {% trans %}What to look for when you have a
problem{% endtrans %}
+
+
+
+
+ {% trans %}Cassandra Query Language{% endtrans %}
+ {% trans %}CQL reference documentation{%
endtrans %}
+
+
+ {% trans %}Cassandra Development{% endtrans
%}
+ {% trans %}Learn how to improve Cassandra and
contribute patches{% endtrans %}
+
+
+
+
+ {% trans %}FAQs{% endtrans %}
+ {% trans %}Frequently Asked Questions (with
answers!){% endtrans %}
+
+
+ {% trans %}Configuration{% endtrans
%}
+ {% trans %}Cassandra's handles and knobs{%
endtrans %}
+
+
+
+
+Meta informations
+
+
+ {% trans %}Reporting
bugs{% endtrans %}
+ {% trans %}Contact
us{% endtrans %}
+
+
+{% endblock %}
diff --cc doc/source/_theme/cassandra_theme/defindex.html
index 1809332,000..a7bd5b8
mode
[cassandra] 01/02: Only include versioned files in rat-report
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 5be6d7e6b1ecaaa74d394922afb57c37a132827d Author: Sam Tunnicliffe AuthorDate: Mon Apr 26 19:33:30 2021 +0100 Only include versioned files in rat-report Patch by Sam Tunnicliffe; reviewed by Benedict Elliott Smith and Mick Semb Wever for CASSANDRA-16633 --- .build/build-rat.xml | 99 build.xml| 32 - 2 files changed, 68 insertions(+), 63 deletions(-) diff --git a/.build/build-rat.xml b/.build/build-rat.xml index 468c671..730899b 100644 --- a/.build/build-rat.xml +++ b/.build/build-rat.xml @@ -1,21 +1,19 @@ - - - @@ -37,34 +32,46 @@ - + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/build.xml b/build.xml index 52ba87f..014a77c 100644 --- a/build.xml +++ b/build.xml @@ -1,22 +1,20 @@ + 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. +--> - 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 (e9cf21b -> ad2f41e)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e9cf21b Update README links new 5be6d7e Only include versioned files in rat-report new ad2f41e Merge branch 'cassandra-2.2' into cassandra-3.0 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: .build/build-rat.xml | 99 build.xml| 32 - 2 files changed, 68 insertions(+), 63 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 trunk
This is an automated email from the ASF dual-hosted git repository.
samt pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 9cda055faaef6ff2f591ad2815139b9c89882514
Merge: f5a0c4c 87a46c3
Author: Sam Tunnicliffe
AuthorDate: Tue Apr 27 09:26:45 2021 +0100
Merge branch 'cassandra-3.11' into trunk
.build/build-rat.xml | 102 +++--
.build/build-resolver.xml | 30 +++---
build.xml | 32 +++
doc/source/_templates/indexcontent.html| 16
doc/source/_theme/cassandra_theme/defindex.html| 16
doc/source/_theme/cassandra_theme/layout.html | 16
doc/source/_theme/cassandra_theme/search.html | 16
.../org/apache/cassandra/stress/graph/graph.html | 17 +++-
8 files changed, 163 insertions(+), 82 deletions(-)
diff --cc .build/build-rat.xml
index cf8d6fc,4a6ebfc..02f8750
--- a/.build/build-rat.xml
+++ b/.build/build-rat.xml
@@@ -1,34 -1,34 +1,28 @@@
+ xmlns:rat="antlib:org.apache.rat.anttasks">
-
-
-
-
-
-
-
-
-
-
+
@@@ -75,4 -87,18 +81,4 @@@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
diff --cc .build/build-resolver.xml
index 793937d,000..888f4b9
mode 100644,00..100644
--- a/.build/build-resolver.xml
+++ b/.build/build-resolver.xml
@@@ -1,264 -1,0 +1,262 @@@
+
+
+
+
+
+
+
+https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-ant-tasks;
/>
+
+
+
+
+https://files.pythonhosted.org/packages; />
+https://github.com; />
+
+
+
+https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha};
/>
+
+
+
+
+
+
+
+Downloading Resolver ANT Tasks...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --cc build.xml
index 932c18a,a1aa1ea..566604d
--- a/build.xml
+++ b/build.xml
@@@ -1,26 -1,22 +1,24
[cassandra] branch cassandra-3.11 updated (a68a7c5 -> 87a46c3)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from a68a7c5 Nodetool garbagecollect should retain SSTableLevel for LCS new 5be6d7e Only include versioned files in rat-report new ad2f41e Merge branch 'cassandra-2.2' into cassandra-3.0 new 87a46c3 Merge branch 'cassandra-3.0' into cassandra-3.11 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: .build/build-rat.xml | 100 +++-- build.xml | 32 --- doc/source/_templates/indexcontent.html| 16 doc/source/_theme/cassandra_theme/defindex.html| 16 doc/source/_theme/cassandra_theme/layout.html | 16 doc/source/_theme/cassandra_theme/search.html | 16 .../org/apache/cassandra/stress/graph/graph.html | 17 +++- 7 files changed, 148 insertions(+), 65 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated: Only include versioned files in rat-report
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch cassandra-2.2 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-2.2 by this push: new bd27026 Only include versioned files in rat-report bd27026 is described below commit bd270260c847e0e8d0825c417215df60e2625539 Author: Sam Tunnicliffe AuthorDate: Mon Apr 26 19:33:30 2021 +0100 Only include versioned files in rat-report Patch by Sam Tunnicliffe; reviewed by Benedict Elliott Smith and Mick Semb Wever for CASSANDRA-16633 --- .build/build-rat.xml | 99 build.xml| 32 - 2 files changed, 68 insertions(+), 63 deletions(-) diff --git a/.build/build-rat.xml b/.build/build-rat.xml index 468c671..6565410 100644 --- a/.build/build-rat.xml +++ b/.build/build-rat.xml @@ -1,21 +1,19 @@ - - - @@ -37,34 +32,46 @@ - + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/build.xml b/build.xml index 52ba87f..014a77c 100644 --- a/build.xml +++ b/build.xml @@ -1,22 +1,20 @@ + 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. +--> - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16575) "compression" configuration in unit tests is incorrect
[
https://issues.apache.org/jira/browse/CASSANDRA-16575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16575:
---
Status: Changes Suggested (was: Review In Progress)
> "compression" configuration in unit tests is incorrect
> --
>
> Key: CASSANDRA-16575
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16575
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When running unit tests with "compression" configuration, we use non-default
> Snappy compressor.
> There is a misleading fragment of {{build.xml}}:
> {code}
>value="${build.test.dir}/cassandra.compressed.yaml"/>
>
>
>
>
> {code}
> {{cassandra.compressed.yaml}} has been replaced in CASSANDRA-14482 by two
> files {{commitlog_compression_LZ4.yaml}} and
> {{commitlog_compression_Zstd.yaml}} without changing build configuration.
> All in all we could fix that but I doubt it makes any sense since {{cdc}}
> configuration already uses compressed commit log anyway so it feels redundant
> to test compression alone for each CI run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16633) Only include versioned files in rat-report
[ https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16633: --- Reviewers: Benedict Elliott Smith, Michael Semb Wever, Michael Semb Wever (was: Benedict Elliott Smith, Michael Semb Wever) Benedict Elliott Smith, Michael Semb Wever, Michael Semb Wever Status: Review In Progress (was: Patch Available) > Only include versioned files in rat-report > -- > > Key: CASSANDRA-16633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16633 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-rc2, 2.2.x, 3.0.x, 3.11.x > > > Recent changes to the ant build.xml file to include running the Apache Rat > reporting tool break the build when there are unversioned files in the source > tree. > We could modify the build to only include versioned files in the Rat report. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16634) Garbagecollect should not output all tables to L0 with LeveledCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16634: Fix Version/s: (was: 4.0.x) (was: 3.11.x) 4.0 4.0-rc2 3.11.11 Since Version: 3.10 Source Control Link: https://github.com/apache/cassandra/commit/a68a7c5181930053f9b513672391b45088e590c4 Resolution: Fixed Status: Resolved (was: Ready to Commit) committed, test failures look unrelated > Garbagecollect should not output all tables to L0 with > LeveledCompactionStrategy > > > Key: CASSANDRA-16634 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16634 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Scott Carey >Assignee: Scott Carey >Priority: Normal > Fix For: 3.11.11, 4.0-rc2, 4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > nodetool garbagecollect always outputs to L0 with LeveledCompactionStrategy. > This is awful. On a large LCS table, this means that at the end of the > garbagecollect process, all data is in L0. > > This results in an awful sequence of useless temporary space usage and write > amplification: > # L0 is repeatedly size-tiered compacted until it doesn't have too many > SSTables. If the original LCS table had 2000 tables... this takes a long time > # L0 is compacted to L1 in one to a couple very very large compactions > # L1 is compacted to L2, L3 to L4, etc. Write amplification galore > Due to the above, 'nodetool garbagecollect' is close to worthless for large > LCS tables. A full compaction is always less write amplification and similar > temp disk space required. The only exception is if you can use 'nodetool > garbagecolect' part-way, and then use 'nodetool stop' to cancel it before L0 > is too large. In this case if you are lucky, and the order that it chose to > process SSTables coincides with tables that have the most disk space to > clear, you might free up enough disk space to succeed in your original goal. > > However, from what I can tell, there is no good reason to move the output to > L0. Leaving the output table in the same SSTableLevel as the source table > does not violate any of the LeveledCompactionStrategy placement rules, as the > output by definition has a token range equal to or smaller than the source. > The only drawback is if the size of the output files is significantly smaller > than the source, in which case the source level would be under-sized. But > that seems like a problem that LCS has to handle, not garbagecollect. > LCS could have a "pull up" operation where it does something like the > following. Assume a table has L4 as the max level, and L3 and L4 are both > 'under-sized'. L3 can attempt to 'pull up' any tables from L4 that do not > overlap with the token ranges of the L3 tables. After that, it can choose to > do some compactions that mix L3 and L4 to pull up data into L3 if it is still > significantly under-sized. > From what I can tell, garbagecollect should just re-write tables in place, > and leave the compaction strategy to deal with any consequences. > Moving to L0 is a bad idea. In addition to the extra write amplification and > extreme increase in temporary disk space required, I observed the following: > A 'nodetool garbagecollect' was placing a lot of pressure on a L0 of a node. > We stopped it about 20% through the process, and it managed to compact down > the top couple levels. So we tried to run 'garbagecollect' again, but the > first tables it chose to operate on were in L1, not the 'leafs' in L5! This > was because the order of SSTables chosen currently does not consider the > level, and instead looks purely at the max timestamp in the file. But > because we moved _very old_ data from L5 into L0 as a result of the prior > gabagecollect, manytables in L1 and L2 now had very wide ranges between their > min and max timestamps – essentially some of the oldest and newest data all > in one table. This breaks the usual structure of an LCS table where the > oldest data is at the high levels. > > I hope that others agree that this is a bug, and deserving of a fix. > I have a very simple patch for this that I will be creating a PR for soon. 3 > lines for the code change, 70 lines for a new unit test. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16633) Only include versioned files in rat-report
[ https://issues.apache.org/jira/browse/CASSANDRA-16633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333008#comment-17333008 ] Michael Semb Wever commented on CASSANDRA-16633: Thanks [~samt] for this! A small comment on [this commit page|https://github.com/apache/cassandra/commit/93f67ebbe180219b490cc872ab9a8642fd051987]. > Only include versioned files in rat-report > -- > > Key: CASSANDRA-16633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16633 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 4.0-rc2, 2.2.x, 3.0.x, 3.11.x > > > Recent changes to the ant build.xml file to include running the Apache Rat > reporting tool break the build when there are unversioned files in the source > tree. > We could modify the build to only include versioned files in the Rat report. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (e74d891 -> f5a0c4c)
This is an automated email from the ASF dual-hosted git repository. marcuse pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e74d891 Fix How-to Commit docs new a68a7c5 Nodetool garbagecollect should retain SSTableLevel for LCS new f5a0c4c Merge branch 'cassandra-3.11' into trunk 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: CHANGES.txt| 1 + .../cassandra/db/compaction/CompactionManager.java | 6 +++ .../apache/cassandra/cql3/GcCompactionBench.java | 4 ++ .../apache/cassandra/cql3/GcCompactionTest.java| 61 ++ 4 files changed, 72 insertions(+) - 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 trunk
This is an automated email from the ASF dual-hosted git repository. marcuse pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit f5a0c4c9628f5f2f4841e87100bccb9e23af8aba Merge: e74d891 a68a7c5 Author: Marcus Eriksson AuthorDate: Tue Apr 27 08:35:19 2021 +0200 Merge branch 'cassandra-3.11' into trunk CHANGES.txt| 1 + .../cassandra/db/compaction/CompactionManager.java | 6 +++ .../apache/cassandra/cql3/GcCompactionBench.java | 4 ++ .../apache/cassandra/cql3/GcCompactionTest.java| 61 ++ 4 files changed, 72 insertions(+) diff --cc CHANGES.txt index f5331f8,bb0309f..21d3efe --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,76 -1,13 +1,77 @@@ -3.11.11 +4.0-rc2 + * Test org.apache.cassandra.net.AsyncPromiseTest FAILED (CASSANDRA-16596) +Merged from 3.11: + * Nodetool garbagecollect should retain SSTableLevel for LCS (CASSANDRA-16634) * Ignore stale acks received in the shadow round (CASSANDRA-16588) +Merged from 3.0: + * Fix materialized view builders inserting truncated data (CASSANDRA-16567) + +4.0-rc1 + * Allow for setting buffer max capacity to increase it dynamically as needed (CASSANDRA-16524) + * Harden internode message resource limit accounting against serialization failures (CASSANDRA-16616) + * Add back the source release of python driver in tree to avoid fetching from GitHub APIs (CASSANDRA-16599) + * Fix false unavailable for queries due to cluster topology changes (CASSANDRA-16545) + * Fixed a race condition issue in nodetool repair where we poll for the error before seeing the error notification, leading to a less meaningful message (CASSANDRA-16585) + * Fix mixed cluster GROUP BY queries (CASSANDRA-16582) + * Upgrade jflex to 1.8.2 (CASSANDRA-16576) + * Binary releases no longer bundle the apidocs (javadoc) (CASSANDRA-15561) + * Fix Streaming Repair metrics (CASSANDRA-16190) + * Scheduled (delayed) schema pull tasks should not run after MIGRATION stage shutdown during decommission (CASSANDRA-16495) + * When behind a firewall trunk is not buildable, need to allow overriding URLs (CASSANDRA-16563) + * Make sure sstables with moved starts are removed correctly in LeveledGenerations (CASSANDRA-16552) + * Fix race between secondary index building and active compactions tracking (CASSANDRA-16554) + * Migrate dependency handling from maven-ant-tasks to resolver-ant-tasks, removing lib/ directory from version control (CASSANDRA-16391) + * Fix 4.0 node sending a repair prepare message to a 3.x node breaking the connection (CASSANDRA-16542) + * Removed synchronized modifier from StreamSession#onChannelClose to prevent deadlocking on flush (CASSANDRA-15892) + * Throw IOE in AbstractType.writeValue if value has wrong fixed length (CASSANDRA-16500) + * Execute background refreshing of auth caches on a dedicated executor (CASSANDRA-15177) + * Update bundled java and python drivers to 3.11.0 and 3.25.0 respectively (CASSANDRA-13951) + * Add io.netty.tryReflectionSetAccessible=true to j11 server options in order to enable netty to use Unsafe direct byte buffer construction (CASSANDRA-16493) + * Make cassandra-stress -node support host:port notation (CASSANDRA-16529) + * Better handle legacy gossip application states during (and after) upgrades (CASSANDRA-16525) + * Mark StreamingMetrics.ActiveOutboundStreams as deprecated (CASSANDRA-11174) + * Increase the cqlsh version number (CASSANDRA-16509) + * Fix the CQL generated for the views.where_clause column when some identifiers require quoting (CASSANDRA-16479) + * Send FAILED_SESSION_MSG on shutdown and on in-progress repairs during startup (CASSANDRA-16425) + * Reinstate removed ApplicationState padding (CASSANDRA-16484) + * Expose data dirs to ColumnFamilyStoreMBean (CASSANDRA-16335) + * Add possibility to copy SSTables in SSTableImporter instead of moving them (CASSANDRA-16407) + * Fix DESCRIBE statement for CUSTOM indices with options (CASSANDRA-16482) + * Fix cassandra-stress JMX connection (CASSANDRA-16473) + * Avoid processing redundant application states on endpoint changes (CASSANDRA-16381) + * Prevent parent repair sessions leak (CASSANDRA-16446) + * Fix timestamp issue in SinglePartitionSliceCommandTest testPartitionD…eletionRowDeletionTie (CASSANDRA-16443) + * Promote protocol V5 out of beta (CASSANDRA-14973) + * Fix incorrect encoding for strings can be UTF8 (CASSANDRA-16429) + * Fix node unable to join when RF > N in multi-DC with added warning (CASSANDRA-16296) + * Add an option to nodetool tablestats to check sstable location correctness (CASSANDRA-16344) + * Unable to ALTER KEYSPACE while decommissioned/assassinated nodes are in gossip (CASSANDRA-16422) + * Metrics backward compatibility restored after CASSANDRA-15066 (CASSANDRA-16083) + * Reduce new reserved keywords introduced since 3.0 (CASSANDRA-16439) + * Improve system tables handling
[cassandra] branch cassandra-3.11 updated: Nodetool garbagecollect should retain SSTableLevel for LCS
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new a68a7c5 Nodetool garbagecollect should retain SSTableLevel for LCS
a68a7c5 is described below
commit a68a7c5181930053f9b513672391b45088e590c4
Author: Scott Carey
AuthorDate: Mon Apr 26 15:29:38 2021 -0700
Nodetool garbagecollect should retain SSTableLevel for LCS
Patch by Scott Carey; reviewed by marcuse for CASSANDRA-16634
---
CHANGES.txt| 1 +
.../cassandra/db/compaction/CompactionManager.java | 6 +++
.../apache/cassandra/cql3/GcCompactionBench.java | 4 ++
.../apache/cassandra/cql3/GcCompactionTest.java| 61 ++
4 files changed, 72 insertions(+)
diff --git a/CHANGES.txt b/CHANGES.txt
index 899cb79..bb0309f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.11.11
+ * Nodetool garbagecollect should retain SSTableLevel for LCS (CASSANDRA-16634)
* Ignore stale acks received in the shadow round (CASSANDRA-16588)
* Add autocomplete and error messages for provide_overlapping_tombstones
(CASSANDRA-16350)
* Add StorageServiceMBean.getKeyspaceReplicationInfo(keyspaceName)
(CASSANDRA-16447)
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index 4ad5ceb..76f6a98 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -531,6 +531,12 @@ public class CompactionManager implements
CompactionManagerMBean
{
return new CompactionController(cfStore, toCompact,
gcBefore, null, tombstoneOption);
}
+
+@Override
+protected int getLevel()
+{
+return txn.onlyOne().getSSTableLevel();
+}
};
task.setUserDefined(true);
task.setCompactionType(OperationType.GARBAGE_COLLECT);
diff --git a/test/long/org/apache/cassandra/cql3/GcCompactionBench.java
b/test/long/org/apache/cassandra/cql3/GcCompactionBench.java
index 84c0384..203367d 100644
--- a/test/long/org/apache/cassandra/cql3/GcCompactionBench.java
+++ b/test/long/org/apache/cassandra/cql3/GcCompactionBench.java
@@ -229,6 +229,7 @@ public class GcCompactionBench extends CQLTester
int startTombCount = countTombstoneMarkers(cfs);
int startRowDeletions = countRowDeletions(cfs);
int startTableCount = cfs.getLiveSSTables().size();
+int startTableMaxLevel =
cfs.getLiveSSTables().stream().mapToInt(SSTableReader::getSSTableLevel).max().orElseGet(()
-> 0);
long startSize = SSTableReader.getTotalBytes(cfs.getLiveSSTables());
System.out.println();
@@ -242,6 +243,7 @@ public class GcCompactionBench extends CQLTester
int endTombCount = countTombstoneMarkers(cfs);
int endRowDeletions = countRowDeletions(cfs);
int endTableCount = cfs.getLiveSSTables().size();
+int endTableMaxLevel =
cfs.getLiveSSTables().stream().mapToInt(SSTableReader::getSSTableLevel).max().orElseGet(()
-> 0);
long endSize = SSTableReader.getTotalBytes(cfs.getLiveSSTables());
System.out.println(cfs.getCompactionParametersJson());
@@ -253,9 +255,11 @@ public class GcCompactionBench extends CQLTester
startTableCount, startSize, startRowCount, startRowDeletions,
startTombCount));
System.out.println(String.format("At end: %12d tables %12d bytes
%12d rows %12d deleted rows %12d tombstone markers",
endTableCount, endSize, endRowCount, endRowDeletions,
endTombCount));
+System.out.println(String.format("Max SSTable level before: %d and
after %d", startTableMaxLevel, endTableMaxLevel));
String hashesAfter = getHashes();
Assert.assertEquals(hashesBefore, hashesAfter);
+Assert.assertEquals(startTableMaxLevel, endTableMaxLevel);
}
private String getHashes() throws Throwable
diff --git a/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
b/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
index 3af5dee..ee16a4d 100644
--- a/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
+++ b/test/unit/org/apache/cassandra/cql3/GcCompactionTest.java
@@ -36,6 +36,7 @@ import org.apache.cassandra.db.rows.*;
import org.apache.cassandra.io.sstable.ISSTableScanner;
import org.apache.cassandra.io.sstable.format.SSTableReader;
import org.apache.cassandra.schema.CompactionParams;
+import org.apache.cassandra.schema.CompactionParams.TombstoneOption;
import org.apache.cassandra.utils.FBUtilities;
public class GcCompactionTest extends
[jira] [Created] (CASSANDRA-16635) dml.rst should not list a "!=" operator
Nadav Har'El created CASSANDRA-16635:
Summary: dml.rst should not list a "!=" operator
Key: CASSANDRA-16635
URL: https://issues.apache.org/jira/browse/CASSANDRA-16635
Project: Cassandra
Issue Type: Improvement
Reporter: Nadav Har'El
In {{doc/source/cql/dml.rst}} (which ends up in
[https://cassandra.apache.org/doc/latest/cql/dml.html),] one of the operators
listed is "!=". However this operator has never been supported in WHERE
clauses, and I don't see any plans to making it supported.
The confusion compounds when you notice that the text does refer in a few
places to "non-equal" or "inequality" operators - but those refer to operators
like "<=" which are allowed in certain places and not others - not to "!="
which isn't allowed anywhere. So "!=" should not be listed at all.
The Datastax version of this document,
[https://docs.datastax.com/en/cql-oss/3.3/cql/cql_reference/cqlSelect.html,]
also doesn't list "!=".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16465) Increased Read Latency With Cassandra >= 3.11.7
[ https://issues.apache.org/jira/browse/CASSANDRA-16465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332982#comment-17332982 ] Stefan Miklosovic commented on CASSANDRA-16465: --- Hey guys, is this acutally an issue for 4.0 as well? I am just wondering if we see this in 3, why could not it be in 4 as well? > Increased Read Latency With Cassandra >= 3.11.7 > --- > > Key: CASSANDRA-16465 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16465 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ahmed ELJAMI >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Attachments: Screenshot from 2021-04-24 20-50-47.png > > > After upgrading Cassandra from 3.11.3 to 3.11.9, Cassandra read latency 99% > increased significantly. Getting back to 3.11.3 immediately fixed the issue. > I have observed "SStable reads" increases after upgrading to 3.11.9. > The same behavior was observed by some other users: > [https://www.mail-archive.com/user@cassandra.apache.org/msg61247.html] > According to Paulo Motta's comment, this behavior may be caused by > https://issues.apache.org/jira/browse/CASSANDRA-15690 which was introduced on > 3.11.7 and removed an optimization that may cause a correctness issue when > there are partition deletions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16634) Garbagecollect should not output all tables to L0 with LeveledCompactionStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332966#comment-17332966 ] Marcus Eriksson commented on CASSANDRA-16634: - bq. The only drawback is if the size of the output files is significantly smaller than the source, in which case the source level would be under-sized. we have CASSANDRA-7414 for this case > Garbagecollect should not output all tables to L0 with > LeveledCompactionStrategy > > > Key: CASSANDRA-16634 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16634 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Scott Carey >Assignee: Scott Carey >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Time Spent: 10m > Remaining Estimate: 0h > > nodetool garbagecollect always outputs to L0 with LeveledCompactionStrategy. > This is awful. On a large LCS table, this means that at the end of the > garbagecollect process, all data is in L0. > > This results in an awful sequence of useless temporary space usage and write > amplification: > # L0 is repeatedly size-tiered compacted until it doesn't have too many > SSTables. If the original LCS table had 2000 tables... this takes a long time > # L0 is compacted to L1 in one to a couple very very large compactions > # L1 is compacted to L2, L3 to L4, etc. Write amplification galore > Due to the above, 'nodetool garbagecollect' is close to worthless for large > LCS tables. A full compaction is always less write amplification and similar > temp disk space required. The only exception is if you can use 'nodetool > garbagecolect' part-way, and then use 'nodetool stop' to cancel it before L0 > is too large. In this case if you are lucky, and the order that it chose to > process SSTables coincides with tables that have the most disk space to > clear, you might free up enough disk space to succeed in your original goal. > > However, from what I can tell, there is no good reason to move the output to > L0. Leaving the output table in the same SSTableLevel as the source table > does not violate any of the LeveledCompactionStrategy placement rules, as the > output by definition has a token range equal to or smaller than the source. > The only drawback is if the size of the output files is significantly smaller > than the source, in which case the source level would be under-sized. But > that seems like a problem that LCS has to handle, not garbagecollect. > LCS could have a "pull up" operation where it does something like the > following. Assume a table has L4 as the max level, and L3 and L4 are both > 'under-sized'. L3 can attempt to 'pull up' any tables from L4 that do not > overlap with the token ranges of the L3 tables. After that, it can choose to > do some compactions that mix L3 and L4 to pull up data into L3 if it is still > significantly under-sized. > From what I can tell, garbagecollect should just re-write tables in place, > and leave the compaction strategy to deal with any consequences. > Moving to L0 is a bad idea. In addition to the extra write amplification and > extreme increase in temporary disk space required, I observed the following: > A 'nodetool garbagecollect' was placing a lot of pressure on a L0 of a node. > We stopped it about 20% through the process, and it managed to compact down > the top couple levels. So we tried to run 'garbagecollect' again, but the > first tables it chose to operate on were in L1, not the 'leafs' in L5! This > was because the order of SSTables chosen currently does not consider the > level, and instead looks purely at the max timestamp in the file. But > because we moved _very old_ data from L5 into L0 as a result of the prior > gabagecollect, manytables in L1 and L2 now had very wide ranges between their > min and max timestamps – essentially some of the oldest and newest data all > in one table. This breaks the usual structure of an LCS table where the > oldest data is at the high levels. > > I hope that others agree that this is a bug, and deserving of a fix. > I have a very simple patch for this that I will be creating a PR for soon. 3 > lines for the code change, 70 lines for a new unit test. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
