[PR] Correction of exception handling in asynchronous programming [cassandra-java-driver]
vararo27 opened a new pull request, #1918:
URL: https://github.com/apache/cassandra-java-driver/pull/1918
An exception is thrown from DefaultSchemaQueriesFactory.java (newInstance
method) when Control connection goes down for any reason and new connection has
not yet initialized yet.
`throw new IllegalStateException("Control channel not available, aborting
schema refresh");`
Exception thrown from here is not propagated to whenComplete method used in
below code snippet of MetadataManager.java and refreshFuture is never marked as
completed and application gets stuck. Reason for that is exception not handled
properly in SchemaRows future object. Its been depicted in this PR using
HandlerSchemaQueries.java
`
private void startSchemaRequest(CompletableFuture
refreshFuture) {
assert adminExecutor.inEventLoop();
if (closeWasCalled) {
refreshFuture.complete(new RefreshSchemaResult(metadata));
return;
}
if (currentSchemaRefresh == null) {
currentSchemaRefresh = refreshFuture;
LOG.debug("[{}] Starting schema refresh", logPrefix);
initControlConnectionForSchema()
.thenCompose(v ->
context.getTopologyMonitor().checkSchemaAgreement())
.whenComplete(
(schemaInAgreement, agreementError) -> {
if (agreementError != null) {
refreshFuture.completeExceptionally(agreementError);
} else {
schemaQueriesFactory
.newInstance()
.execute()
.thenApplyAsync(this::parseAndApplySchemaRows,
adminExecutor)
.whenComplete(
(newMetadata, metadataError) -> {
if (metadataError != null) {
refreshFuture.completeExceptionally(metadataError);
} else {
refreshFuture.complete(
new RefreshSchemaResult(newMetadata,
schemaInAgreement));
}
firstSchemaRefreshFuture.complete(null);
currentSchemaRefresh = null;
// If another refresh was enqueued during this
one, run it now
if (queuedSchemaRefresh != null) {
CompletableFuture tmp =
this.queuedSchemaRefresh;
this.queuedSchemaRefresh = null;
startSchemaRequest(tmp);
}
});
}
});
} else if (queuedSchemaRefresh == null) {
queuedSchemaRefresh = refreshFuture; // wait for our turn
} else {
CompletableFutures.completeFrom(
queuedSchemaRefresh, refreshFuture); // join the queued request
}
}
`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] CASSANDRA-19418 - Changes to report additional bulk analytics job stats for instrumentation [cassandra-analytics]
arjunashok commented on code in PR #41: URL: https://github.com/apache/cassandra-analytics/pull/41#discussion_r1520641363 ## cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/BulkWriterContext.java: ## @@ -21,7 +21,9 @@ import java.io.Serializable; -public interface BulkWriterContext extends Serializable +import org.apache.cassandra.spark.common.Reportable; + +public interface BulkWriterContext extends Serializable, Reportable Review Comment: We could potentially have this implemented by the concrete `CassandraBulkWriterContext` to keep it consistent with how `dialHome` is currently implemented. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] CASSANDRA-19418 - Changes to report additional bulk analytics job stats for instrumentation [cassandra-analytics]
arjunashok commented on code in PR #41:
URL:
https://github.com/apache/cassandra-analytics/pull/41#discussion_r1520627909
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/bulkwriter/CassandraBulkSourceRelation.java:
##
@@ -107,17 +112,25 @@ private void persist(@NotNull JavaPairRDD sortedRDD, Str
{
try
{
-sortedRDD.foreachPartition(writeRowsInPartition(broadcastContext,
columnNames));
+List results = sortedRDD
+
.mapPartitions(partitionsFlatMapFunc(broadcastContext, columnNames))
+ .collect();
+long rowCount = results.stream().mapToLong(res ->
res.rowCount).sum();
+long totalBytesWritten = results.stream().mapToLong(res ->
res.bytesWritten).sum();
+LOGGER.info("Bulk writer has written {} rows and {} bytes",
rowCount, totalBytesWritten);
+recordSuccessfulJobStats(rowCount, totalBytesWritten);
}
catch (Throwable throwable)
{
+recordFailureStats(throwable.getMessage());
LOGGER.error("Bulk Write Failed", throwable);
throw new RuntimeException("Bulk Write to Cassandra has failed",
throwable);
}
finally
{
try
{
+writerContext.publishJobStats();
Review Comment:
You're right. Fixed to only report/publish stats from the driver.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] Fix decode in VectorCodec [cassandra-java-driver]
absurdfarce commented on PR #1909: URL: https://github.com/apache/cassandra-java-driver/pull/1909#issuecomment-1989603867 With two +1's from committers (mine + @adutra) this ticket was considered eligible to merge. We can't do a squash merge at the moment, however, so we need to resolve that first. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] CASSANDRA-19290: Replace uses of AttributeKey.newInstance [cassandra-java-driver]
absurdfarce commented on PR #1908: URL: https://github.com/apache/cassandra-java-driver/pull/1908#issuecomment-1989603594 With two +1's from committers (mine + @adutra) this ticket was considered eligible to merge. We can't do a squash merge at the moment, however, so we need to resolve that first. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] JAVA-2967: Support native_transport_(address|port) + native_transport_port_ssl for DSE 6.8 (4.x edition) [cassandra-java-driver]
absurdfarce commented on PR #1913: URL: https://github.com/apache/cassandra-java-driver/pull/1913#issuecomment-1989604266 With two +1's from committers (mine + @adutra) this ticket was considered eligible to merge. We can't do a squash merge at the moment, however, so we need to resolve that first. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
Re: [PR] CASSANDRA-19180: Support reloading keystore in cassandra-java-driver [cassandra-java-driver]
absurdfarce commented on PR #1907: URL: https://github.com/apache/cassandra-java-driver/pull/1907#issuecomment-1989597253 With two +1's from committers (mine + one from driftx on the JIRA ticket) this ticket was considered eligible to merge. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817502#comment-17817502 ] Bret McGuire edited comment on CASSANDRA-19180 at 3/11/24 10:52 PM: Thanks [~brandon.williams]. With your +1 we have two approvals from committers so we're all set). was (Author: JIRAUSER304104): Thanks [~brandon.williams] ! With your +1 we have two approvals from committers so we're all set! > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825465#comment-17825465
]
Jon Haddad commented on CASSANDRA-19429:
I'm using the latest 4.1 and the branch off 4.1 I found above.
Cassandra 4.1 ships configured to use ParNew + CMS, but there's not really a
good reason to use that. We changed to G1 in 5.0, it's far superior to ParNew
/ CMS for general usage. Both versions were set up using G1.
I built my clusters using easy-cass-lab (formerly tlp-cluster). Here's the
cassandra.patch.yaml I used along with the JMX options and a bunch of other
settings. You can see the workloads I ran and my flame graphs in a previous
comment.
I ran these tests on the same node, with the same exact dataset. In fact, I
ran many tests, switching back and forth between 4.1 and the patched branch in
order to try to find some way of replicating what you found, however I was
unable to.
{noformat}
---
cluster_name: "Test Cluster"
num_tokens: 4
seed_provider:
class_name: "org.apache.cassandra.locator.SimpleSeedProvider"
parameters:
seeds: "172.31.42.182"
hints_directory: "/mnt/cassandra/hints"
data_file_directories:
- "/mnt/cassandra/data"
commitlog_directory: "/mnt/cassandra/commitlog"
concurrent_reads: 128
concurrent_writes: 64
trickle_fsync: true
endpoint_snitch: "Ec2Snitch"
memtable_heap_space: 16MiB{noformat}
{noformat}
### G1 Settings
## Use the Hotspot garbage-first collector.
-XX:+UseG1GC
-XX:+ParallelRefProcEnabled
-XX:MaxTenuringThreshold=4
-XX:G1HeapRegionSize=16m
-XX:+UnlockExperimentalVMOptions
-XX:G1NewSizePercent=50
-XX:G1MaxNewSizePercent=70-Xmx24G
-Xms24G{noformat}
{noformat}
sudo sysctl kernel.perf_event_paranoid=1
sudo sysctl kernel.kptr_restrict=0
echo 0 > /proc/sys/vm/zone_reclaim_mode{noformat}
{noformat}
# /etc/security/limits.d/cassandra.conf
cassandra soft memlock unlimited
cassandra hard memlock unlimited
cassandra soft nofile 10
cassandra hard nofile 10
cassandra soft nproc 32768
cassandra hard nproc 32768
cassandra - as unlimited{noformat}
{noformat}
# /etc/sysctl.d/60-cassandra.conf
vm.max_map_count = 1048575{noformat}
{noformat}
sudo swapoff --allsudo sysctl -p{noformat}
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apac
[jira] [Comment Edited] (CASSANDRA-18335) Push LocalSessions info logs to debug
[
https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825462#comment-17825462
]
Arun Ganesh edited comment on CASSANDRA-18335 at 3/11/24 9:46 PM:
--
{quote}..., I would recommend that CHANGES not be addressed in PRs, ...
{quote}
Cool.
Aside: I understand that you are super busy. Since you are already here, do you
have any tickets (a bit complex than this, for starters) that I can work on?
Almost all of the low-hanging fruit issues are taken, and the other ones seem
intimidating. I'd like to actively contribute to this project, and I got a
couple basic PRs merged recently. Thanks!
was (Author: JIRAUSER303038):
{quote}..., I would recommend that CHANGES not be addressed in PRs, ...
{quote}
Cool.
Aside: I understand that you are super busy. Since you are already here, do you
have any issues (a bit complex than this, for starters) that I can work on?
Almost all of the low-hanging fruit issues are taken, and the other ones seem
intimidating. I'd like to actively contribute to this project, and I got a
couple basic PRs merged recently. Thanks!
> Push LocalSessions info logs to debug
> -
>
> Key: CASSANDRA-18335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18335
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I don't think these are particularly useful to have at info, but the impetus
> for this ticket is specifically [this
> message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456]
> during automatic cleanup about skipping deleting sessions that seems to
> confuse or alarm people.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18335) Push LocalSessions info logs to debug
[
https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825462#comment-17825462
]
Arun Ganesh commented on CASSANDRA-18335:
-
{quote}..., I would recommend that CHANGES not be addressed in PRs, ...
{quote}
Cool.
Aside: I understand that you are super busy. Since you are already here, do you
have any issues (a bit complex than this, for starters) that I can work on?
Almost all of the low-hanging fruit issues are taken, and the other ones seem
intimidating. I'd like to actively contribute to this project, and I got a
couple basic PRs merged recently. Thanks!
> Push LocalSessions info logs to debug
> -
>
> Key: CASSANDRA-18335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18335
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I don't think these are particularly useful to have at info, but the impetus
> for this ticket is specifically [this
> message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456]
> during automatic cleanup about skipping deleting sessions that seems to
> confuse or alarm people.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18335: - Reviewers: Brandon Williams Status: Review In Progress (was: Patch Available) > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18335: - Status: Needs Committer (was: Review In Progress) > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825458#comment-17825458 ] Brandon Williams commented on CASSANDRA-18335: -- This looks good to me, I don't think we need CI to push log levels down but I [smoke tested 5.0|https://app.circleci.com/pipelines/github/driftx/cassandra/1504/workflows/9ab0975e-e8a1-4783-b4f8-201b22d3e3e8] just to make sure no tests were looking for these. Nothing there looks relevant, I'm +1. bq. Also, I wasn't sure where to add the CHANGES.txt line for the 4.0 and 4.1 PRs. In general I would recommend that CHANGES not be addressed in PRs, since this will almost always later conflict for the committer, who will know where to put those lines anyway. > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825442#comment-17825442
]
Dipietro Salvatore edited comment on CASSANDRA-19429 at 3/11/24 8:57 PM:
-
> I'm working with a single node, with compaction disabled, and I reduced my
> memtable space to 16MB in order to constantly flush. I wrote 10m rows and
> have 1928 SStables. These boxes have 72 CPU. I'm using G1GC with a 24GB
> heap. I've tested concurrent_reads at 64 and 128 since there's enough cores
> on here to handle and we don't need to bottleneck on reads.
[~rustyrazorblade] Can you provided full detailed and step-by-step instructions
on how you tested? So I will try to reproduce as well on the r8g and r7i
instance types.
BTW which Cassandra version did you use? AFAIK, Cassandra 4 uses
UseConcMarkSweepGC and not G1GC. Am I right?
was (Author: JIRAUSER304377):
> I'm working with a single node, with compaction disabled, and I reduced my
> memtable space to 16MB in order to constantly flush. I wrote 10m rows and
> have 1928 SStables. These boxes have 72 CPU. I'm using G1GC with a 24GB
> heap. I've tested concurrent_reads at 64 and 128 since there's enough cores
> on here to handle and we don't need to bottleneck on reads.
[~rustyrazorblade] Can you provided full detailed and step-by-step instructions
on how you tested? So I will try to reproduce as well.
BTW which Cassandra version did you use? AFAIK, Cassandra 4 uses
UseConcMarkSweepGC and not G1GC. Am I right?
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825442#comment-17825442
]
Dipietro Salvatore commented on CASSANDRA-19429:
> I'm working with a single node, with compaction disabled, and I reduced my
> memtable space to 16MB in order to constantly flush. I wrote 10m rows and
> have 1928 SStables. These boxes have 72 CPU. I'm using G1GC with a 24GB
> heap. I've tested concurrent_reads at 64 and 128 since there's enough cores
> on here to handle and we don't need to bottleneck on reads.
[~rustyrazorblade] Can you provided full detailed and step-by-step instructions
on how you tested? So I will try to reproduce as well.
BTW which Cassandra version did you use? AFAIK, Cassandra 4 uses
UseConcMarkSweepGC and not G1GC. Am I right?
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825398#comment-17825398 ] Arun Ganesh commented on CASSANDRA-18335: - [~brandon.williams], I've changed all `logger.info` lines to `logger.debug`. Let me know if you want me to change something else. Also, I wasn't sure where to add the CHANGES.txt line for the 4.0 and 4.1 PRs. > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh updated CASSANDRA-18335: Test and Documentation Plan: Not applicable Status: Patch Available (was: In Progress) > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19445) Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
[
https://issues.apache.org/jira/browse/CASSANDRA-19445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19445:
-
Fix Version/s: 4.1.x
5.0.x
5.x
> Cassandra 4.1.4 floods logs with "Completed 0 uncommitted paxos instances for"
> --
>
> Key: CASSANDRA-19445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19445
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Lightweight Transactions
>Reporter: Zbyszek Z
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: paxos-entry.txt, paxos-multiple.txt
>
>
> Hello,
> On our cluster logs are flooded with:
> {code:java}
> INFO [OptionalTasks:1] 2024-02-27 14:27:51,213
> PaxosCleanupLocalCoordinator.java:185 - Completed 0 uncommitted paxos
> instances for X on ranges
> [(9210458530128018597,-9222146739399525061],
> (-9222146739399525061,-9174246180597321488],
> (-9174246180597321488,-9155837684527496840],
> (-9155837684527496840,-9148981328078890812],
> (-9148981328078890812,-9141853035919151700],
> (-9141853035919151700,-9138872620588476741], {code}
> I cannot find anything in doc regarding this longline. Also this are huge log
> payloads that heavy flood system.log.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh reassigned CASSANDRA-18335: --- Assignee: Arun Ganesh > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-19465:
Assignee: Brandon Williams
> Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
> -
>
> Key: CASSANDRA-19465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19465
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> https://app.circleci.com/pipelines/github/bereng/cassandra/1181/workflows/fe2ac859-f6ba-4f1e-b0b1-e6923b16e874/jobs/39449/tests
> {noformat}
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> def new_commitlog_cluster_node():
> # writes should block on commitlog fsync
> self.fixture_dtest_setup.cluster.populate(1)
> node = self.fixture_dtest_setup.cluster.nodelist()[0]
>
> self.fixture_dtest_setup.cluster.set_batch_commitlog(enabled=True,
> use_batch_window = self.fixture_dtest_setup.cluster.version() < '5.0')
>
> self.fixture_dtest_setup.cluster.start()
> return node
>
> durable_node = new_commitlog_cluster_node()
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> # get a fresh cluster to work on
> durable_session.shutdown()
> self.fixture_dtest_setup.cleanup_and_replace_cluster()
>
> node = new_commitlog_cluster_node()
> init_size = commitlog_size(node)
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> session.execute('ALTER KEYSPACE ks WITH DURABLE_WRITES=true')
> > write_to_trigger_fsync(session, 'ks', 'tab')
> configuration_test.py:113:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> configuration_test.py:186: in write_to_trigger_fsync
> execute_concurrent_with_args(session,
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:238: in
> execute_concurrent_with_args
> return execute_concurrent(session, zip(cycle((statement,)), parameters),
> *args, **kwargs)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:94: in
> execute_concurrent
> return executor.execute(concurrency, raise_on_first_error)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:201: in execute
> return super(ConcurrentExecutorListResults, self).execute(concurrency,
> fail_fast)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:120: in execute
> return self._results()
> ../env3.8/
[jira] [Commented] (CASSANDRA-19417) LIST SUPERUSERS cql command
[ https://issues.apache.org/jira/browse/CASSANDRA-19417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825364#comment-17825364 ] Shailaja Koppu commented on CASSANDRA-19417: I ran CI before review comments, I will run again now with latest changes and will upload results > LIST SUPERUSERS cql command > --- > > Key: CASSANDRA-19417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19417 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Shailaja Koppu >Assignee: Shailaja Koppu >Priority: Normal > Labels: CQL > Fix For: 5.x > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Developing a new CQL command LIST SUPERUSERS to return list of roles with > superuser privilege. This includes roles who acquired superuser privilege in > the hierarchy. > Context: LIST ROLES cql command lists roles, their membership details and > displays super=true for immediate superusers. But there can be roles who > acquired superuser privilege due to a grant. LIST ROLES command won't display > super=true for such roles and the only way to recognize such roles is to look > for atleast one row with super=true in the output of LIST ROLES OF name> command. While this works to check is a given role has superuser > privilege, there may be services (for example, Sidecar) working with C* and > may need to maintain list of roles with superuser privilege. There is no > existing command/tool to retrieve such roles details. Hence developing this > command which returns all roles having superuser privilege. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[ https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825359#comment-17825359 ] C. Scott Andreas commented on CASSANDRA-18831: -- Hi [~e.dimitrova], I think [~jmckenzie] is picking this up from Achilles. > Enable Cassandra to build and run under JDK21 > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[
https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825315#comment-17825315
]
Ekaterina Dimitrova edited comment on CASSANDRA-18831 at 3/11/24 1:37 PM:
--
Hi [~utkuaydin],
Thank you for suggesting to help. I suspect Achilles Benetopoulos won't be
working on bringing Java 21 to Cassandra 6.0. [~cscotta], do you know if anyone
else plans to take over this, or can Utku Aydin take over?
{quote}{quote} {color:#172b4d}I assume another ticket would be needed regarding
CI or could that also be done here?{color}
{quote}{quote}
By CI, do you mean the whole CI setup - JDK21 added to images, jobs added in
CI systems, etc.? I suspect we should have a new epic - similar to the one we
have for introducing JDK17 (CASSANDRA-16895). However, I am optimistic that the
jump between 17 and 21 will be less work as we have caught up on maintenance.
However, I do not want to underestimate the time and effort that it will
require.
was (Author: e.dimitrova):
Hi [~utkuaydin],
Thank you for suggesting to help. I suspect Achilles Benetopoulos won't be
working on bringing Java 21 to Cassandra 6.0. [~cscotta], do you know if anyone
else plans to take over this, or can Utku Aydin take over?
{quote}bq. {color:#172b4d}I assume another ticket would be needed regarding CI
or could that also be done here?{color}
{quote}
By CI, do you mean the whole CI setup - JDK21 added to images, jobs added in
CI systems, etc.? I suspect we should have a new epic - similar to the one we
have for introducing JDK17 (CASSANDRA-16895). However, I am optimistic that the
jump between 17 and 21 will be less work as we have caught up on maintenance.
> Enable Cassandra to build and run under JDK21
> -
>
> Key: CASSANDRA-18831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18831
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Achilles Benetopoulos
>Priority: Normal
> Fix For: 5.x
>
> Attachments: jdk21-patch
>
>
> This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list
> of supported Java versions, and extends that work to enable building and
> running Cassandra under JDK21.
> The following commits comprise the changes included in the attached patch:
> -
> [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47]
> -
> [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897]
> -
> [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913]
> -
> [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[
https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825315#comment-17825315
]
Ekaterina Dimitrova commented on CASSANDRA-18831:
-
Hi [~utkuaydin],
Thank you for suggesting to help. I suspect Achilles Benetopoulos won't be
working on bringing Java 21 to Cassandra 6.0. [~cscotta], do you know if anyone
else plans to take over this, or can Utku Aydin take over?
{quote}bq. {color:#172b4d}I assume another ticket would be needed regarding CI
or could that also be done here?{color}
{quote}
By CI, do you mean the whole CI setup - JDK21 added to images, jobs added in
CI systems, etc.? I suspect we should have a new epic - similar to the one we
have for introducing JDK17 (CASSANDRA-16895). However, I am optimistic that the
jump between 17 and 21 will be less work as we have caught up on maintenance.
> Enable Cassandra to build and run under JDK21
> -
>
> Key: CASSANDRA-18831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18831
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Achilles Benetopoulos
>Priority: Normal
> Fix For: 5.x
>
> Attachments: jdk21-patch
>
>
> This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list
> of supported Java versions, and extends that work to enable building and
> running Cassandra under JDK21.
> The following commits comprise the changes included in the attached patch:
> -
> [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47]
> -
> [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897]
> -
> [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913]
> -
> [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19460) Fix tests to work with ULID SSTable identifiers to enable uuid_sstable_identifiers_enabled in cassandra-latest.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-19460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825314#comment-17825314 ] Stefan Miklosovic commented on CASSANDRA-19460: --- j11 https://app.circleci.com/pipelines/github/instaclustr/cassandra/3984/workflows/378320b6-301d-4f58-a5a5-d9bbe241a79d j17 https://app.circleci.com/pipelines/github/instaclustr/cassandra/3985/workflows/3ae6a6f0-9a58-4b7e-aa4f-13907e874230 These builds also include https://github.com/apache/cassandra/pull/3165 otherwise it would fail a lot of tests .. > Fix tests to work with ULID SSTable identifiers to enable > uuid_sstable_identifiers_enabled in cassandra-latest.yaml > --- > > Key: CASSANDRA-19460 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19460 > Project: Cassandra > Issue Type: Task > Components: CI, Test/dtest/java, Test/unit >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > In CASSANDRA-18753 we identified that we want to also set > uuid_sstable_identifiers_enabled to true, while running a CI with it turned > on, it failed (1). > Errors do not seem to be serious, it is just the test suite we have is not > prepared for the case when uuid_sstable_identifiers_enabled is set to true by > default. > We need to fix all these tests so we can have cassandra-latest.yaml > containing that property. > https://app.circleci.com/pipelines/github/blambov/cassandra/609/workflows/aef2b936-0551-4f3b-9d86-a49451c83947 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19464) pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-19464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825232#comment-17825232 ] Stefan Miklosovic commented on CASSANDRA-19464: --- ninja committed [here|https://github.com/apache/cassandra-dtest/commit/1f562e2635ce7afca38eb1538cf3eab6e46d5c15] I will transition this to "open" to actually track the progress towards 8.1.1 upgrade. > pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests > --- > > Key: CASSANDRA-19464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19464 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I just hit this issue literally today / yesterday. Python's dtests started to > fail on some super strange errors like this (1) and similar ... > We have "pytest>=6.5.0" in requirements.txt for Python dtests so it seems > like it automatically updates to whatever is the latest and it just updated > to 8.1.1 and it broke the stuff. > Some basic investigation yields (2), (3) were complaints are made that it > break a lot of things. > The proper solution seems to be to remove flaky and transition to (4). > Until we fix this, I think we might just downgrade to the latest 8.0.x > pytest, probably this one (5), I am just trying it as I write this. > (1) > https://app.circleci.com/pipelines/github/instaclustr/cassandra/3978/workflows/57f7db32-9892-40bd-9e85-cc9527af7af7/jobs/201511 > (2) https://github.com/pytest-dev/pytest/issues/12066 > (3) https://docs.pytest.org/en/latest/changelog.html#pytest-8-1-0-yanked > (4) https://github.com/pytest-dev/pytest-rerunfailures > (5) https://docs.pytest.org/en/latest/changelog.html#pytest-8-0-2-2024-02-24 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19464) pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-19464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19464: -- Status: In Progress (was: Patch Available) > pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests > --- > > Key: CASSANDRA-19464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19464 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I just hit this issue literally today / yesterday. Python's dtests started to > fail on some super strange errors like this (1) and similar ... > We have "pytest>=6.5.0" in requirements.txt for Python dtests so it seems > like it automatically updates to whatever is the latest and it just updated > to 8.1.1 and it broke the stuff. > Some basic investigation yields (2), (3) were complaints are made that it > break a lot of things. > The proper solution seems to be to remove flaky and transition to (4). > Until we fix this, I think we might just downgrade to the latest 8.0.x > pytest, probably this one (5), I am just trying it as I write this. > (1) > https://app.circleci.com/pipelines/github/instaclustr/cassandra/3978/workflows/57f7db32-9892-40bd-9e85-cc9527af7af7/jobs/201511 > (2) https://github.com/pytest-dev/pytest/issues/12066 > (3) https://docs.pytest.org/en/latest/changelog.html#pytest-8-1-0-yanked > (4) https://github.com/pytest-dev/pytest-rerunfailures > (5) https://docs.pytest.org/en/latest/changelog.html#pytest-8-0-2-2024-02-24 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-dtest) branch trunk updated (f4de30a9 -> 1f562e26)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git from f4de30a9 Extend timeout for parallel_upgrade and parallel_upgrade_with_internode_ssl upgrade tests (fix 2 for CASSANDRA-19409) add 1f562e26 temporarily pin down pytest to >=6.5.0,<=8.0.2 until CASSANDRA-16464 is resolved No new revisions were added by this update. Summary of changes: requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19464) pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-19464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825230#comment-17825230 ] Stefan Miklosovic commented on CASSANDRA-19464: --- I just tested 5.0 in dev profile [here|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3987/workflows/543a6338-4be1-4543-8fd0-279c12125de7] to see that dtests pass. > pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests > --- > > Key: CASSANDRA-19464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19464 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I just hit this issue literally today / yesterday. Python's dtests started to > fail on some super strange errors like this (1) and similar ... > We have "pytest>=6.5.0" in requirements.txt for Python dtests so it seems > like it automatically updates to whatever is the latest and it just updated > to 8.1.1 and it broke the stuff. > Some basic investigation yields (2), (3) were complaints are made that it > break a lot of things. > The proper solution seems to be to remove flaky and transition to (4). > Until we fix this, I think we might just downgrade to the latest 8.0.x > pytest, probably this one (5), I am just trying it as I write this. > (1) > https://app.circleci.com/pipelines/github/instaclustr/cassandra/3978/workflows/57f7db32-9892-40bd-9e85-cc9527af7af7/jobs/201511 > (2) https://github.com/pytest-dev/pytest/issues/12066 > (3) https://docs.pytest.org/en/latest/changelog.html#pytest-8-1-0-yanked > (4) https://github.com/pytest-dev/pytest-rerunfailures > (5) https://docs.pytest.org/en/latest/changelog.html#pytest-8-0-2-2024-02-24 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-19393: Status: Ready to Commit (was: Review In Progress) > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825221#comment-17825221 ] Marcus Eriksson commented on CASSANDRA-19393: - +1 > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19464) pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-19464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-19464: Reviewers: Berenguer Blasi > pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests > --- > > Key: CASSANDRA-19464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19464 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I just hit this issue literally today / yesterday. Python's dtests started to > fail on some super strange errors like this (1) and similar ... > We have "pytest>=6.5.0" in requirements.txt for Python dtests so it seems > like it automatically updates to whatever is the latest and it just updated > to 8.1.1 and it broke the stuff. > Some basic investigation yields (2), (3) were complaints are made that it > break a lot of things. > The proper solution seems to be to remove flaky and transition to (4). > Until we fix this, I think we might just downgrade to the latest 8.0.x > pytest, probably this one (5), I am just trying it as I write this. > (1) > https://app.circleci.com/pipelines/github/instaclustr/cassandra/3978/workflows/57f7db32-9892-40bd-9e85-cc9527af7af7/jobs/201511 > (2) https://github.com/pytest-dev/pytest/issues/12066 > (3) https://docs.pytest.org/en/latest/changelog.html#pytest-8-1-0-yanked > (4) https://github.com/pytest-dev/pytest-rerunfailures > (5) https://docs.pytest.org/en/latest/changelog.html#pytest-8-0-2-2024-02-24 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19464) pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-19464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825195#comment-17825195 ] Berenguer Blasi commented on CASSANDRA-19464: - Fire 5.0 and trunk CI at least imo bc of the release on one side and to make sure trunk looks good? > pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests > --- > > Key: CASSANDRA-19464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19464 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I just hit this issue literally today / yesterday. Python's dtests started to > fail on some super strange errors like this (1) and similar ... > We have "pytest>=6.5.0" in requirements.txt for Python dtests so it seems > like it automatically updates to whatever is the latest and it just updated > to 8.1.1 and it broke the stuff. > Some basic investigation yields (2), (3) were complaints are made that it > break a lot of things. > The proper solution seems to be to remove flaky and transition to (4). > Until we fix this, I think we might just downgrade to the latest 8.0.x > pytest, probably this one (5), I am just trying it as I write this. > (1) > https://app.circleci.com/pipelines/github/instaclustr/cassandra/3978/workflows/57f7db32-9892-40bd-9e85-cc9527af7af7/jobs/201511 > (2) https://github.com/pytest-dev/pytest/issues/12066 > (3) https://docs.pytest.org/en/latest/changelog.html#pytest-8-1-0-yanked > (4) https://github.com/pytest-dev/pytest-rerunfailures > (5) https://docs.pytest.org/en/latest/changelog.html#pytest-8-0-2-2024-02-24 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19464) pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-19464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19464: -- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) I was checking how complex it would be to move pytest to 8.1.1 and it is not so straightforward. The best thing we can do for now is to just pin it to <=8.0.2 - the latest one known to work. https://github.com/apache/cassandra-dtest/pull/256 I can ninja this if we agree [~bereng] [~brandon.williams] > pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests > --- > > Key: CASSANDRA-19464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19464 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I just hit this issue literally today / yesterday. Python's dtests started to > fail on some super strange errors like this (1) and similar ... > We have "pytest>=6.5.0" in requirements.txt for Python dtests so it seems > like it automatically updates to whatever is the latest and it just updated > to 8.1.1 and it broke the stuff. > Some basic investigation yields (2), (3) were complaints are made that it > break a lot of things. > The proper solution seems to be to remove flaky and transition to (4). > Until we fix this, I think we might just downgrade to the latest 8.0.x > pytest, probably this one (5), I am just trying it as I write this. > (1) > https://app.circleci.com/pipelines/github/instaclustr/cassandra/3978/workflows/57f7db32-9892-40bd-9e85-cc9527af7af7/jobs/201511 > (2) https://github.com/pytest-dev/pytest/issues/12066 > (3) https://docs.pytest.org/en/latest/changelog.html#pytest-8-1-0-yanked > (4) https://github.com/pytest-dev/pytest-rerunfailures > (5) https://docs.pytest.org/en/latest/changelog.html#pytest-8-0-2-2024-02-24 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19464) pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-19464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19464: -- Change Category: Operability Complexity: Normal Fix Version/s: NA Assignee: Stefan Miklosovic Status: Open (was: Triage Needed) > pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests > --- > > Key: CASSANDRA-19464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19464 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I just hit this issue literally today / yesterday. Python's dtests started to > fail on some super strange errors like this (1) and similar ... > We have "pytest>=6.5.0" in requirements.txt for Python dtests so it seems > like it automatically updates to whatever is the latest and it just updated > to 8.1.1 and it broke the stuff. > Some basic investigation yields (2), (3) were complaints are made that it > break a lot of things. > The proper solution seems to be to remove flaky and transition to (4). > Until we fix this, I think we might just downgrade to the latest 8.0.x > pytest, probably this one (5), I am just trying it as I write this. > (1) > https://app.circleci.com/pipelines/github/instaclustr/cassandra/3978/workflows/57f7db32-9892-40bd-9e85-cc9527af7af7/jobs/201511 > (2) https://github.com/pytest-dev/pytest/issues/12066 > (3) https://docs.pytest.org/en/latest/changelog.html#pytest-8-1-0-yanked > (4) https://github.com/pytest-dev/pytest-rerunfailures > (5) https://docs.pytest.org/en/latest/changelog.html#pytest-8-0-2-2024-02-24 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-19465:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: Unit Test
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
> -
>
> Key: CASSANDRA-19465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19465
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> https://app.circleci.com/pipelines/github/bereng/cassandra/1181/workflows/fe2ac859-f6ba-4f1e-b0b1-e6923b16e874/jobs/39449/tests
> {noformat}
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> def new_commitlog_cluster_node():
> # writes should block on commitlog fsync
> self.fixture_dtest_setup.cluster.populate(1)
> node = self.fixture_dtest_setup.cluster.nodelist()[0]
>
> self.fixture_dtest_setup.cluster.set_batch_commitlog(enabled=True,
> use_batch_window = self.fixture_dtest_setup.cluster.version() < '5.0')
>
> self.fixture_dtest_setup.cluster.start()
> return node
>
> durable_node = new_commitlog_cluster_node()
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> # get a fresh cluster to work on
> durable_session.shutdown()
> self.fixture_dtest_setup.cleanup_and_replace_cluster()
>
> node = new_commitlog_cluster_node()
> init_size = commitlog_size(node)
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> session.execute('ALTER KEYSPACE ks WITH DURABLE_WRITES=true')
> > write_to_trigger_fsync(session, 'ks', 'tab')
> configuration_test.py:113:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> configuration_test.py:186: in write_to_trigger_fsync
> execute_concurrent_with_args(session,
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:238: in
> execute_concurrent_with_args
> return execute_concurrent(session, zip(cycle((statement,)), parameters),
> *args, **kwargs)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:94: in
> execute_concurrent
> return executor.execute(concurrency, raise_on_first_error)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:201: in execute
> return super(ConcurrentExecutorListResults, self).execute(concurrency,
> fail_fast)
> ../env3.8/sr
[jira] [Updated] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-19465:
Fix Version/s: 5.0-rc
5.x
> Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
> -
>
> Key: CASSANDRA-19465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19465
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> https://app.circleci.com/pipelines/github/bereng/cassandra/1181/workflows/fe2ac859-f6ba-4f1e-b0b1-e6923b16e874/jobs/39449/tests
> {noformat}
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> def new_commitlog_cluster_node():
> # writes should block on commitlog fsync
> self.fixture_dtest_setup.cluster.populate(1)
> node = self.fixture_dtest_setup.cluster.nodelist()[0]
>
> self.fixture_dtest_setup.cluster.set_batch_commitlog(enabled=True,
> use_batch_window = self.fixture_dtest_setup.cluster.version() < '5.0')
>
> self.fixture_dtest_setup.cluster.start()
> return node
>
> durable_node = new_commitlog_cluster_node()
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> # get a fresh cluster to work on
> durable_session.shutdown()
> self.fixture_dtest_setup.cleanup_and_replace_cluster()
>
> node = new_commitlog_cluster_node()
> init_size = commitlog_size(node)
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> session.execute('ALTER KEYSPACE ks WITH DURABLE_WRITES=true')
> > write_to_trigger_fsync(session, 'ks', 'tab')
> configuration_test.py:113:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> configuration_test.py:186: in write_to_trigger_fsync
> execute_concurrent_with_args(session,
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:238: in
> execute_concurrent_with_args
> return execute_concurrent(session, zip(cycle((statement,)), parameters),
> *args, **kwargs)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:94: in
> execute_concurrent
> return executor.execute(concurrency, raise_on_first_error)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:201: in execute
> return super(ConcurrentExecutorListResults, self).execute(concurrency,
> fail_fast)
> ../env3.8/src/cassandra-driver/cassandra/concurrent.py:120: in execute
> return self._results()
> ../env3.8/src/cassandra-driver/cassandra/
[jira] [Created] (CASSANDRA-19465) Test Failure: configuration_test.TestConfiguration.test_change_durable_writes
Berenguer Blasi created CASSANDRA-19465:
---
Summary: Test Failure:
configuration_test.TestConfiguration.test_change_durable_writes
Key: CASSANDRA-19465
URL: https://issues.apache.org/jira/browse/CASSANDRA-19465
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Berenguer Blasi
https://app.circleci.com/pipelines/github/bereng/cassandra/1181/workflows/fe2ac859-f6ba-4f1e-b0b1-e6923b16e874/jobs/39449/tests
{noformat}
self =
@pytest.mark.timeout(60*30)
def test_change_durable_writes(self):
"""
@jira_ticket CASSANDRA-9560
Test that changes to the DURABLE_WRITES option on keyspaces is
respected in subsequent writes.
This test starts by writing a dataset to a cluster and asserting that
the commitlogs have been written to. The subsequent test depends on
the assumption that this dataset triggers an fsync.
After checking this assumption, the test destroys the cluster and
creates a fresh one. Then it tests that DURABLE_WRITES is respected by:
- creating a keyspace with DURABLE_WRITES set to false,
- using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
- writing a dataset to this keyspace that is known to trigger a
commitlog fsync,
- asserting that the commitlog has grown in size since the data was
written.
"""
def new_commitlog_cluster_node():
# writes should block on commitlog fsync
self.fixture_dtest_setup.cluster.populate(1)
node = self.fixture_dtest_setup.cluster.nodelist()[0]
self.fixture_dtest_setup.cluster.set_batch_commitlog(enabled=True,
use_batch_window = self.fixture_dtest_setup.cluster.version() < '5.0')
self.fixture_dtest_setup.cluster.start()
return node
durable_node = new_commitlog_cluster_node()
durable_init_size = commitlog_size(durable_node)
durable_session = self.patient_exclusive_cql_connection(durable_node)
# test assumption that write_to_trigger_fsync actually triggers a
commitlog fsync
durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
{'class': 'SimpleStrategy', 'replication_factor': 1} "
"AND DURABLE_WRITES = true")
durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
int, b int, c int)')
logger.debug('commitlog size diff = ' +
str(commitlog_size(durable_node) - durable_init_size))
write_to_trigger_fsync(durable_session, 'ks', 'tab')
assert commitlog_size(durable_node) > durable_init_size, \
"This test will not work in this environment;
write_to_trigger_fsync does not trigger fsync."
# get a fresh cluster to work on
durable_session.shutdown()
self.fixture_dtest_setup.cleanup_and_replace_cluster()
node = new_commitlog_cluster_node()
init_size = commitlog_size(node)
session = self.patient_exclusive_cql_connection(node)
# set up a keyspace without durable writes, then alter it to use them
session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
'SimpleStrategy', 'replication_factor': 1} "
"AND DURABLE_WRITES = false")
session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
int, c int)')
session.execute('ALTER KEYSPACE ks WITH DURABLE_WRITES=true')
> write_to_trigger_fsync(session, 'ks', 'tab')
configuration_test.py:113:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
configuration_test.py:186: in write_to_trigger_fsync
execute_concurrent_with_args(session,
../env3.8/src/cassandra-driver/cassandra/concurrent.py:238: in
execute_concurrent_with_args
return execute_concurrent(session, zip(cycle((statement,)), parameters),
*args, **kwargs)
../env3.8/src/cassandra-driver/cassandra/concurrent.py:94: in execute_concurrent
return executor.execute(concurrency, raise_on_first_error)
../env3.8/src/cassandra-driver/cassandra/concurrent.py:201: in execute
return super(ConcurrentExecutorListResults, self).execute(concurrency,
fail_fast)
../env3.8/src/cassandra-driver/cassandra/concurrent.py:120: in execute
return self._results()
../env3.8/src/cassandra-driver/cassandra/concurrent.py:219: in _results
self._raise(self._exception)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
exc = NoHostAvailable('Unable to complete the operation against any hosts',
{: ConnectionShutdown('Connection to
127.0.0.1:9042 was closed')})
@staticmethod
def _raise(exc):
if six.PY2 and isinstance(exc, tuple):
(exc_type, value, traceback) = exc
six.reraise(exc_type, value, traceback)
else:
>
[jira] [Updated] (CASSANDRA-18635) Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18635:
Fix Version/s: 5.1
(was: 5.x)
Since Version: 5.0-alpha2
Source Control Link:
https://github.com/apache/cassandra/commit/451b0c010f0997d7bf9e3f4687bf9e75e2ebb004
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
> ---
>
> Key: CASSANDRA-18635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18635
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1095/workflows/6114e2e3-8dcc-4bb0-b664-ae7d82c3349f/jobs/33405/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<0> but was:<2>
> at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.upgradeSSTablesInterruptsOngoingCompaction(UpgradeSSTablesTest.java:86)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) 01/01: Merge branch 'cassandra-5.0' into trunk
This is an automated email from the ASF dual-hosted git repository. bereng pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit e8e7861f142d7e6cb178a0c1126d458956862460 Merge: 5d4bcc797a 451b0c010f Author: Bereng AuthorDate: Mon Mar 11 08:08:34 2024 +0100 Merge branch 'cassandra-5.0' into trunk * cassandra-5.0: Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest .../cassandra/tools/nodetool/UpgradeSSTable.java | 27 +- 1 file changed, 21 insertions(+), 6 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch cassandra-5.0 updated: Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch cassandra-5.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-5.0 by this push:
new 451b0c010f Test failure:
org.apache.cassandra.distributed.test.UpgradeSSTablesTest
451b0c010f is described below
commit 451b0c010f0997d7bf9e3f4687bf9e75e2ebb004
Author: Bereng
AuthorDate: Tue Feb 13 11:11:19 2024 +0100
Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
patch by Berenguer Blasi; reviewed by Brandon Williams, Stefan Miklosovic
for CASSANDRA-18635
---
.../cassandra/tools/nodetool/UpgradeSSTable.java | 27 +-
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/src/java/org/apache/cassandra/tools/nodetool/UpgradeSSTable.java
b/src/java/org/apache/cassandra/tools/nodetool/UpgradeSSTable.java
index cc94d8b54b..fb881bf106 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/UpgradeSSTable.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/UpgradeSSTable.java
@@ -24,6 +24,9 @@ import io.airlift.airline.Option;
import java.util.ArrayList;
import java.util.List;
+import org.apache.commons.lang3.exception.ExceptionUtils;
+
+import org.apache.cassandra.db.compaction.CompactionInterruptedException;
import org.apache.cassandra.tools.NodeProbe;
import org.apache.cassandra.tools.NodeTool.NodeToolCmd;
@@ -56,13 +59,25 @@ public class UpgradeSSTable extends NodeToolCmd
for (String keyspace : keyspaces)
{
-try
-{
-probe.upgradeSSTables(probe.output().out, keyspace,
!includeAll, maxSSTableTimestamp, jobs, tableNames);
-}
-catch (Exception e)
+for (int retries = 0; retries < 5; retries++)
{
-throw new RuntimeException("Error occurred during enabling
auto-compaction", e);
+try
+{
+if (retries > 0)
+Thread.sleep(500);
+probe.upgradeSSTables(probe.output().out, keyspace,
!includeAll, maxSSTableTimestamp, jobs, tableNames);
+break;
+}
+catch (RuntimeException cie)
+{
+// Spin retry. See CASSANDRA-18635
+if (ExceptionUtils.indexOfThrowable(cie,
CompactionInterruptedException.class) != -1 && retries == 4)
+throw (cie);
+}
+catch (Exception e)
+{
+throw new RuntimeException("Error occurred during enabling
auto-compaction", e);
+}
}
}
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated (5d4bcc797a -> e8e7861f14)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 5d4bcc797a Avoid exposing intermediate state while replaying log during startup new 451b0c010f Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest new e8e7861f14 Merge branch 'cassandra-5.0' 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: .../cassandra/tools/nodetool/UpgradeSSTable.java | 27 +- 1 file changed, 21 insertions(+), 6 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
