[jira] [Commented] (CASSANDRA-18934) Downgrade to 4.1 fails due to schema changes
[
https://issues.apache.org/jira/browse/CASSANDRA-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823476#comment-17823476
]
Claude Warren commented on CASSANDRA-18934:
---
[~maxwellguo] I have been thinking about this ticket on and off for awhile now
and have some ideas that I would like to talk with you about. Would you reach
out to me directly [cla...@apache.org.|mailto:cla...@apache.org.] thank you.
> Downgrade to 4.1 fails due to schema changes
>
>
> Key: CASSANDRA-18934
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18934
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: David Capwell
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
>
> We are required to support 5.0 downgrading to 4.1 as a migration step, but we
> don’t have tests to show this is working… I wrote a quick test to make sure a
> change we needed in Accord wouldn’t block the downgrade and see that we fail
> right now.
> {code}
> ERROR 20:56:39 Exiting due to error while processing commit log during
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReadHandler$CommitLogReadException:
> Unexpected error deserializing mutation; saved to
> /var/folders/h1/s_3p1x3s3hl0hltbpck67m0hgn/T/mutation418421767150092dat.
> This may be caused by replaying a mutation against a table with the same
> name but incompatible schema. Exception follows: java.lang.RuntimeException:
> Unknown column compaction_properties during deserialization
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readMutation(CommitLogReader.java:464)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readSection(CommitLogReader.java:397)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:244)
> at
> org.apache.cassandra.db.commitlog.CommitLogReader.readCommitLogSegment(CommitLogReader.java:147)
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayFiles(CommitLogReplayer.java:191)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverFiles(CommitLog.java:223)
> at
> org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:204)
> {code}
> This was caused by a schema change in CASSANDRA-18061
> {code}
> /*
> * 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.
> */
> package org.apache.cassandra.distributed.upgrade;
> import java.io.IOException;
> import java.io.File;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.junit.Test;
> import org.apache.cassandra.distributed.api.IUpgradeableInstance;
> public class DowngradeTest extends UpgradeTestBase
> {
> @Test
> public void test() throws Throwable
> {
> AtomicBoolean first = new AtomicBoolean(true);
> new TestCase()
> .nodes(1)
> .withConfig(c -> {
> if (first.compareAndSet(true, false))
> c.set("storage_compatibility_mode", "CASSANDRA_4");
> })
> .downgradeTo(v41)
> .setup(cluster -> {})
> // Uncomment if you want to test what happens after reading the commit log,
> which fails right now
> //.runBeforeNodeRestart((cluster, nodeId) -> {
> //IUpgradeableInstance inst = cluster.get(nodeId);
> //File f = new File((String)
> inst.config().get("commitlog_directory"));
> //deleteRecursive(f);
> //})
> .runAfterClusterUpgrade(cluster -> {})
> .run();
> }
> private void deleteRecursive(File f)
> {
> if (f.isDirectory())
> {
> File[] children = f.listFiles();
> if (children != null)
> {
> for (File c : children)
> deleteRecursive(c);
> }
> }
> f.delete();
> }
> }
> {code}
> {code}
> diff --git
> a/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java
>
>
[jira] [Commented] (CASSANDRA-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823466#comment-17823466
]
Arun Ganesh commented on CASSANDRA-19454:
-
[~maedhroz], thanks!
I have a [draft PR|https://github.com/apache/cassandra/pull/3158] up for trunk.
I'm not sure if that's all there is to do. Also, how should I go about testing
these changes? I'll create another PR for 5.0 after I finish this one.
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823463#comment-17823463
]
Claude Warren commented on CASSANDRA-12937:
---
[~smiklosovic] , we have finished 16565, Can we look at moving this forward?
The pull request I placed against your branch changes the exclusion code so
that it is all in one place. calling for the default compression will properly
exclude system keyspaces, and gives us a single point in which to fix any other
issues that arise.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-15452) Improve disk access patterns during compaction and streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823391#comment-17823391
]
Jon Haddad edited comment on CASSANDRA-15452 at 3/5/24 2:59 AM:
I took another look at this. This lets us extract every read operation against
a single data file:
{noformat}
awk '$4 == "R" { print $0 }' everyfs.txt | grep '30-bti-Data.db' >
30-bti-data.txt{noformat}
If you glance at the end of the data, the last entry is this:
{noformat}
23:47:12 CompactionExec 44651 R 2699 12483 0.00
da-30-bti-Data.db{noformat}
The data file is only 15KB. But we're doing over 6 thousand reads
{noformat}
wc -l ../research/30-bti-data.txt
6420 ../research/30-bti-data.txt{noformat}
The 5th column is the number of bytes read. Summing this:
{noformat}
awk '{ sum += $5; } END {print sum}' ../research/30-bti-data.txt
25571844{noformat}
= 25MB
which is a lot to pull through the filesystem when in an optimal situation we
would have done a single 16KB read.
Since these numbers are really, really weird, I'm going back through and
verifying there's not a bug in the tools, or my understanding of them.
was (Author: rustyrazorblade):
I took another look at this. This lets us extract every read operation against
a single data file:
{noformat}
awk '$4 == "R" { print $0 }' everyfs.txt | grep '30-bti-Data.db' >
30-bti-data.txt{noformat}
If you glance at the end of the data, the last entry is this:
{noformat}
23:47:12 CompactionExec 44651 R 2699 12483 0.00
da-30-bti-Data.db{noformat}
The data file is only 15KB. But we're doing over 6 thousand reads
{noformat}
wc -l ../research/30-bti-data.txt
6420 ../research/30-bti-data.txt{noformat}
The 5th column is the number of bytes read. Summing this:
{noformat}
awk '{ sum += $5; } END {print sum}' ../research/30-bti-data.txt
25571844{noformat}
= 25MB
which is a lot to pull through the filesystem when in an optimal situation we
would have done a single 16KB read.
> Improve disk access patterns during compaction and streaming
>
>
> Key: CASSANDRA-15452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15452
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths, Local/Compaction
>Reporter: Jon Haddad
>Priority: Normal
> Attachments: everyfs.txt, results.txt, sequential.fio
>
>
> On read heavy workloads Cassandra performs much better when using a low read
> ahead setting. In my tests I've seen an 5x improvement in throughput and
> more than a 50% reduction in latency. However, I've also observed that it
> can have a negative impact on compaction and streaming throughput. It
> especially negatively impacts cloud environments where small reads incur high
> costs in IOPS due to tiny requests.
> # We should investigate using POSIX_FADV_DONTNEED on files we're compacting
> to see if we can improve performance and reduce page faults.
> # This should be combined with an internal read ahead style buffer that
> Cassandra manages, similar to a BufferedInputStream but with our own
> machinery. This buffer should read fairly large blocks of data off disk at
> at time. EBS, for example, allows 1 IOP to be up to 256KB. A considerable
> amount of time is spent in blocking I/O during compaction and streaming.
> Reducing the frequency we read from disk should speed up all sequential I/O
> operations.
--
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-15452) Improve disk access patterns during compaction and streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823391#comment-17823391
]
Jon Haddad edited comment on CASSANDRA-15452 at 3/5/24 1:57 AM:
I took another look at this. This lets us extract every read operation against
a single data file:
{noformat}
awk '$4 == "R" { print $0 }' everyfs.txt | grep '30-bti-Data.db' >
30-bti-data.txt{noformat}
If you glance at the end of the data, the last entry is this:
{noformat}
23:47:12 CompactionExec 44651 R 2699 12483 0.00
da-30-bti-Data.db{noformat}
The data file is only 15KB. But we're doing over 6 thousand reads
{noformat}
wc -l ../research/30-bti-data.txt
6420 ../research/30-bti-data.txt{noformat}
The 5th column is the number of bytes read. Summing this:
{noformat}
awk '{ sum += $5; } END {print sum}' ../research/30-bti-data.txt
25571844{noformat}
= 25MB
which is a lot to pull through the filesystem when in an optimal situation we
would have done a single 16KB read.
was (Author: rustyrazorblade):
I took another look at this. This lets us extract every read operation against
a single data file:
{noformat}
awk '$4 == "R" { print $0 }' everyfs.txt | grep '30-bti-Data.db' >
30-bti-data.txt{noformat}
If you glance at the end of the data, the last entry is this:
{noformat}
23:47:12 CompactionExec 44651 R 2699 12483 0.00
da-30-bti-Data.db{noformat}
The data file is only 15KB. But we're doing over 6 thousand reads
{noformat}
wc -l ../research/30-bti-data.txt
6420 ../research/30-bti-data.txt{noformat}
The 5th column is the number of bytes read. Summing this:
{noformat}
awk '{ sum += $5; } END {print sum}' ../research/30-bti-data.txt
25571844{noformat}
= 25MB
which is a lot to pull through the filesystem when in an optimal situation have
done a single 16KB read.
> Improve disk access patterns during compaction and streaming
>
>
> Key: CASSANDRA-15452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15452
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths, Local/Compaction
>Reporter: Jon Haddad
>Priority: Normal
> Attachments: everyfs.txt, results.txt, sequential.fio
>
>
> On read heavy workloads Cassandra performs much better when using a low read
> ahead setting. In my tests I've seen an 5x improvement in throughput and
> more than a 50% reduction in latency. However, I've also observed that it
> can have a negative impact on compaction and streaming throughput. It
> especially negatively impacts cloud environments where small reads incur high
> costs in IOPS due to tiny requests.
> # We should investigate using POSIX_FADV_DONTNEED on files we're compacting
> to see if we can improve performance and reduce page faults.
> # This should be combined with an internal read ahead style buffer that
> Cassandra manages, similar to a BufferedInputStream but with our own
> machinery. This buffer should read fairly large blocks of data off disk at
> at time. EBS, for example, allows 1 IOP to be up to 256KB. A considerable
> amount of time is spent in blocking I/O during compaction and streaming.
> Reducing the frequency we read from disk should speed up all sequential I/O
> operations.
--
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-15452) Improve disk access patterns during compaction and streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823391#comment-17823391
]
Jon Haddad commented on CASSANDRA-15452:
I took another look at this. This lets us extract every read operation against
a single data file:
{noformat}
awk '$4 == "R" { print $0 }' everyfs.txt | grep '30-bti-Data.db' >
30-bti-data.txt{noformat}
If you glance at the end of the data, the last entry is this:
{noformat}
23:47:12 CompactionExec 44651 R 2699 12483 0.00
da-30-bti-Data.db{noformat}
The data file is only 15KB. But we're doing over 6 thousand reads
{noformat}
wc -l ../research/30-bti-data.txt
6420 ../research/30-bti-data.txt{noformat}
The 5th column is the number of bytes read. Summing this:
{noformat}
awk '{ sum += $5; } END {print sum}' ../research/30-bti-data.txt
25571844{noformat}
= 25MB
which is a lot to pull through the filesystem when in an optimal situation have
done a single 16KB read.
> Improve disk access patterns during compaction and streaming
>
>
> Key: CASSANDRA-15452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15452
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths, Local/Compaction
>Reporter: Jon Haddad
>Priority: Normal
> Attachments: everyfs.txt, results.txt, sequential.fio
>
>
> On read heavy workloads Cassandra performs much better when using a low read
> ahead setting. In my tests I've seen an 5x improvement in throughput and
> more than a 50% reduction in latency. However, I've also observed that it
> can have a negative impact on compaction and streaming throughput. It
> especially negatively impacts cloud environments where small reads incur high
> costs in IOPS due to tiny requests.
> # We should investigate using POSIX_FADV_DONTNEED on files we're compacting
> to see if we can improve performance and reduce page faults.
> # This should be combined with an internal read ahead style buffer that
> Cassandra manages, similar to a BufferedInputStream but with our own
> machinery. This buffer should read fairly large blocks of data off disk at
> at time. EBS, for example, allows 1 IOP to be up to 256KB. A considerable
> amount of time is spent in blocking I/O during compaction and streaming.
> Reducing the frequency we read from disk should speed up all sequential I/O
> operations.
--
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-15452) Improve disk access patterns during compaction and streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15452: --- Attachment: everyfs.txt > Improve disk access patterns during compaction and streaming > > > Key: CASSANDRA-15452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15452 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths, Local/Compaction >Reporter: Jon Haddad >Priority: Normal > Attachments: everyfs.txt, results.txt, sequential.fio > > > On read heavy workloads Cassandra performs much better when using a low read > ahead setting. In my tests I've seen an 5x improvement in throughput and > more than a 50% reduction in latency. However, I've also observed that it > can have a negative impact on compaction and streaming throughput. It > especially negatively impacts cloud environments where small reads incur high > costs in IOPS due to tiny requests. > # We should investigate using POSIX_FADV_DONTNEED on files we're compacting > to see if we can improve performance and reduce page faults. > # This should be combined with an internal read ahead style buffer that > Cassandra manages, similar to a BufferedInputStream but with our own > machinery. This buffer should read fairly large blocks of data off disk at > at time. EBS, for example, allows 1 IOP to be up to 256KB. A considerable > amount of time is spent in blocking I/O during compaction and streaming. > Reducing the frequency we read from disk should speed up all sequential I/O > operations. -- 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-15452) Improve disk access patterns during compaction and streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823380#comment-17823380
]
Jon Haddad edited comment on CASSANDRA-15452 at 3/5/24 12:29 AM:
-
I took a look at the new BTI format and we're doing the same thing here.
{noformat}
TIME COMM PID T BYTES OFF_KB LAT(ms) FILENAME
23:47:09 CompactionExec 44651 R 3982 0 0.01 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 0 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3980 3 0.01 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3980 3 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 7 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 7 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 11 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 11 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 15 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 15 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 19 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 19 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3989 23 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3989 23 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3996 27 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3996 27 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3974 31 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3974 31 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3987 35 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3987 35 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3984 38 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3984 38 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3973 42 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3973 42 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3991 46 0.00
da-30-bti-Data.db{noformat}
This read pattern is also really odd - we're reading the same data off the
filesystem repeatedly. Every I/O read operation is making an expensive system
call rather than looking at an in process buffer.
I'm uploading everyfs.txt which contains every filesystem operation done during
this compaction.
was (Author: rustyrazorblade):
I took a look at the new BTI format and we're doing the same thing here.
{noformat}
TIME COMM PID T BYTES OFF_KB LAT(ms) FILENAME
23:47:09 CompactionExec 44651 R 3982 0 0.01 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 0 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3980 3 0.01 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3980 3 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 7 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 7 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 11 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 11 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 15 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 15 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 19 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 19 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3989 23 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3989 23 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3996 27 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3996 27 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3974 31 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3974 31 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3987 35 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3987 35 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3984 38 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3984 38 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3973 42 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3973 42 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3991 46 0.00
da-30-bti-Data.db{noformat}
This read pattern is also really odd - we're reading the same data off the
filesystem repeatedly. Every I/O read operation is making an expensive system
call rather than looking at an in process buffer.
> Improve disk access
[jira] [Updated] (CASSANDRA-19456) invalid
[ https://issues.apache.org/jira/browse/CASSANDRA-19456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19456: --- Attachment: (was: image-2024-03-04-13-09-49-321.png) > invalid > --- > > Key: CASSANDRA-19456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19456 > Project: Cassandra > Issue Type: Improvement >Reporter: Brad Schoening >Priority: Normal > -- 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-19456) invalid
[ https://issues.apache.org/jira/browse/CASSANDRA-19456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19456: --- Summary: invalid (was: caas_repair should use TLS 1.3) > invalid > --- > > Key: CASSANDRA-19456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19456 > Project: Cassandra > Issue Type: Improvement >Reporter: Brad Schoening >Priority: Normal > -- 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-19456) invalid
[ https://issues.apache.org/jira/browse/CASSANDRA-19456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19456: --- Resolution: Invalid Status: Resolved (was: Triage Needed) > invalid > --- > > Key: CASSANDRA-19456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19456 > Project: Cassandra > Issue Type: Improvement >Reporter: Brad Schoening >Priority: Normal > -- 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-19456) caas_repair should use TLS 1.3
[ https://issues.apache.org/jira/browse/CASSANDRA-19456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19456: --- Description: (was: It's best practice to let the driver & server auto negotiate the TLS version, which should usually be TLS 1.3. Based on clientstats, it looks like the driver is forcing the protocol to the older TLS 1.2. Would suggest removing any TLS versions from the code and just letting it auto-negotiate TLS. !image-2024-03-04-13-09-49-321.png!) > caas_repair should use TLS 1.3 > -- > > Key: CASSANDRA-19456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19456 > Project: Cassandra > Issue Type: Improvement >Reporter: Brad Schoening >Priority: Normal > Attachments: image-2024-03-04-13-09-49-321.png > > -- 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-15452) Improve disk access patterns during compaction and streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823380#comment-17823380
]
Jon Haddad commented on CASSANDRA-15452:
I took a look at the new BTI format and we're doing the same thing here.
{noformat}
TIME COMM PID T BYTES OFF_KB LAT(ms) FILENAME
23:47:09 CompactionExec 44651 R 3982 0 0.01 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 0 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3980 3 0.01 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3980 3 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 7 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 7 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 11 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3986 11 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 15 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 15 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 19 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3982 19 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3989 23 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3989 23 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3996 27 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3996 27 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3974 31 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3974 31 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3987 35 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3987 35 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3984 38 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3984 38 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3973 42 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3973 42 0.00 da-30-bti-Data.db
23:47:09 CompactionExec 44651 R 3991 46 0.00
da-30-bti-Data.db{noformat}
We're also unnecessary
> Improve disk access patterns during compaction and streaming
>
>
> Key: CASSANDRA-15452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15452
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths, Local/Compaction
>Reporter: Jon Haddad
>Priority: Normal
> Attachments: results.txt, sequential.fio
>
>
> On read heavy workloads Cassandra performs much better when using a low read
> ahead setting. In my tests I've seen an 5x improvement in throughput and
> more than a 50% reduction in latency. However, I've also observed that it
> can have a negative impact on compaction and streaming throughput. It
> especially negatively impacts cloud environments where small reads incur high
> costs in IOPS due to tiny requests.
> # We should investigate using POSIX_FADV_DONTNEED on files we're compacting
> to see if we can improve performance and reduce page faults.
> # This should be combined with an internal read ahead style buffer that
> Cassandra manages, similar to a BufferedInputStream but with our own
> machinery. This buffer should read fairly large blocks of data off disk at
> at time. EBS, for example, allows 1 IOP to be up to 256KB. A considerable
> amount of time is spent in blocking I/O during compaction and streaming.
> Reducing the frequency we read from disk should speed up all sequential I/O
> operations.
--
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-15452) Improve disk access patterns during compaction and streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823374#comment-17823374
]
Jon Haddad edited comment on CASSANDRA-15452 at 3/4/24 11:04 PM:
-
I took a look at the I/O operations hitting the filesystem in the HEAD of 5.0
branch, and I've found our reads are going to be fairly wasteful. I loaded a
single node up with some data and then started monitoring every operation, then
ran `nodetool compact`.
I monitored the i/o using this command:
{noformat}
sudo /usr/share/bcc/tools/xfsslower 0 -p 26988 | awk '$4 == "R" { print $0
}'{noformat}
which allowed me to monitor all reads at the filesystem level.
Here's a sample of the output. I've added the headers back in for convenience,
and I've taken the liberty of showing some of the later I/O operations that
occur at the end.
{noformat}
Tracing XFS operations
TIME COMM PID T BYTES OFF_KB LAT(ms) FILENAME
22:27:38 CompactionExec 26988 R 4096 0 0.01 nb-7-big-Statistics.db
22:27:38 CompactionExec 26988 R 4096 4 0.00 nb-7-big-Statistics.db
22:27:38 CompactionExec 26988 R 2062 8 0.00 nb-7-big-Statistics.db
22:27:38 CompactionExec 26988 R 14907 0 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14924 14 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14896 29 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14844 43 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14923 58 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14931 72 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14905 87 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14891 101 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14919 116 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14965 130 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14918 145 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14930 160 0.01 nb-7-big-Data.db
.
22:27:39 CompactionExec 26988 R 4096 0 0.01 nb-7-big-Statistics.db
22:27:39 CompactionExec 26988 R 98 0 0.01 nb-9-big-Data.db
22:27:39 CompactionExec 26988 R 4096 0 0.01
nb-13-big-Statistics.db
22:27:39 CompactionExec 26988 R 4096 0 0.01
nb-4-big-Statistics.db
22:27:39 CompactionExec 26988 R 911 4 0.00
nb-4-big-Statistics.db
22:27:39 CompactionExec 26988 R 115 0 0.01 nb-4-big-Data.db
22:27:39 CompactionExec 26988 R 51 0 0.01 nb-9-big-Data.db
{noformat}
This table was using the default compression with a 16KB chunk length. When I
altered the table to use a 4KB chunk length, I see this, running the same
commands:
{noformat}
22:37:56 CompactionExec 26988 R 4096 0 0.01
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 816 4 0.00
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 102 0 0.01 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 4096 0 0.01
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 4096 4 0.00
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 2062 8 0.00
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 3763 0 0.01 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3758 3 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3748 7 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3783 11 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3770 14 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3750 18 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3794 22 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3793 25 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3748 29 0.00
nb-13-big-Data.db{noformat}
Reading in only 1 chunk at a time instead of a buffer means our reliance on
page cache for sequential reads is at odds with our need to minimize read
amplification during read heavy workloads. This includes LWT and Counter
workloads as they're read before write. With accord coming up we're going to
want to ensure our users don't need to overpay for storage just for the sake of
running compaction.
Here's a sample of what the I/O looks like at the block device level when
running compact:
{noformat}
ubuntu@ip-172-31-38-58:~$ sudo /usr/share/bcc/tools/biosnoop -d xvdb | awk '$5
== "R" { print $0 }'{noformat}
{noformat}
TIME(s) COMM PID DISK T SECTOR BYTES LAT(ms)
0.00 CompactionExec 26988 xvdb R 4834 16384 0.26
0.002350 CompactionExec 26988 xvdb R 48339842 512 0.23
0.003560
[jira] [Commented] (CASSANDRA-15452) Improve disk access patterns during compaction and streaming
[
https://issues.apache.org/jira/browse/CASSANDRA-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823374#comment-17823374
]
Jon Haddad commented on CASSANDRA-15452:
I took a look at the I/O operations hitting the filesystem in the HEAD of 5.0
branch, and I've found our reads are going to be fairly wasteful. I loaded a
single node up with some data and then started monitoring every operation, then
ran `nodetool compact`.
I monitored the i/o using this command:
{noformat}
sudo /usr/share/bcc/tools/xfsslower 0 -p 26988 | awk '$4 == "R" { print $0
}'{noformat}
which allowed me to monitor all reads at the filesystem level.
Here's a sample of the output. I've added the headers back in for convenience,
and I've taken the liberty of showing some of the later I/O operations that
occur at the end.
{noformat}
Tracing XFS operations
TIME COMM PID T BYTES OFF_KB LAT(ms) FILENAME
22:27:38 CompactionExec 26988 R 4096 0 0.01 nb-7-big-Statistics.db
22:27:38 CompactionExec 26988 R 4096 4 0.00 nb-7-big-Statistics.db
22:27:38 CompactionExec 26988 R 2062 8 0.00 nb-7-big-Statistics.db
22:27:38 CompactionExec 26988 R 14907 0 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14924 14 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14896 29 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14844 43 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14923 58 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14931 72 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14905 87 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14891 101 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14919 116 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14965 130 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14918 145 0.01 nb-7-big-Data.db
22:27:38 CompactionExec 26988 R 14930 160 0.01 nb-7-big-Data.db
.
22:27:39 CompactionExec 26988 R 4096 0 0.01 nb-7-big-Statistics.db
22:27:39 CompactionExec 26988 R 98 0 0.01 nb-9-big-Data.db
22:27:39 CompactionExec 26988 R 4096 0 0.01
nb-13-big-Statistics.db
22:27:39 CompactionExec 26988 R 4096 0 0.01
nb-4-big-Statistics.db
22:27:39 CompactionExec 26988 R 911 4 0.00
nb-4-big-Statistics.db
22:27:39 CompactionExec 26988 R 115 0 0.01 nb-4-big-Data.db
22:27:39 CompactionExec 26988 R 51 0 0.01 nb-9-big-Data.db
{noformat}
This table was using the default compression with a 16KB chunk length. When I
altered the table to use a 4KB chunk length, I see this, running the same
commands:
{noformat}
22:37:56 CompactionExec 26988 R 4096 0 0.01
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 816 4 0.00
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 102 0 0.01 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 4096 0 0.01
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 4096 4 0.00
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 2062 8 0.00
nb-13-big-Statistics.db
22:37:56 CompactionExec 26988 R 3763 0 0.01 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3758 3 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3748 7 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3783 11 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3770 14 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3750 18 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3794 22 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3793 25 0.00 nb-13-big-Data.db
22:37:56 CompactionExec 26988 R 3748 29 0.00
nb-13-big-Data.db{noformat}
Reading in only 1 chunk at a time instead of a buffer means our reliance on
page cache for sequential reads is at odds with our need to minimize read
amplification during read heavy workloads. This includes LWT and Counter
workloads as they're read before write. With accord coming up we're going to
want to ensure our users don't need to overpay for storage just for the sake of
running compaction.
Here's a sample of what the I/O looks like at the block device level when
running compact:
{noformat}
ubuntu@ip-172-31-38-58:~$ sudo /usr/share/bcc/tools/biosnoop -d xvdb | awk '$5
== "R" { print $0 }'{noformat}
{noformat}
TIME(s) COMM PID DISK T SECTOR BYTES LAT(ms)
0.00 CompactionExec 26988 xvdb R 4834 16384 0.26
0.002350 CompactionExec 26988 xvdb R 48339842 512 0.23
0.003560 CompactionExec 26988 xvdb R 48339872 4096
[jira] [Updated] (CASSANDRA-19355) Accord: PreLoadContext must properly and consistently support ranges
[ https://issues.apache.org/jira/browse/CASSANDRA-19355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-19355: -- Test and Documentation Plan: unit + simulation tests Status: Patch Available (was: In Progress) > Accord: PreLoadContext must properly and consistently support ranges > > > Key: CASSANDRA-19355 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19355 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > There are some mechanisms for ensuring range transactions are loaded for > range transactions, but they do not currently work properly (having several > race conditions), are potentially costly in terms of memory consumption, and > are inconsistent with how they work for key transactions. -- 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-18120) Single slow node dramatically reduces cluster write throughput regardless of CL
[
https://issues.apache.org/jira/browse/CASSANDRA-18120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823365#comment-17823365
]
Shayne Hunsaker commented on CASSANDRA-18120:
-
[~dsarisky] [~maximc] [~mck] I'm reviving this for more discussion.
We're working on a fix for this in our fork and ideally could contribute the
solution to both, to keep them more in sync. We're looking into porting the
[Datastax Enterprise
bachlog_endpoint_strategy|https://docs.datastax.com/en/dse/6.8/docs/managing/configure/configure-cassandra-yaml.html#hints_compression],
or something like it, to open source cassandra.
This implementation uses DynamicEndpointSnitch.sortedByProximity(). To respond
to your points in: +Why not go with `sortedByProximity()`?+
# It's true that the implementation is different across every
`AbstractEndpointSnitch` descendant, Datastax enterprise solution only works if
the dynamic snitch is enabled. It checks that the snitch is of type
`DynamicEndpointSnitch` and reverts back to the current Random implementation
if it is not. So it avoids errors, but doesn't work in every scenario.
# It looks like the appropriate way to convert the `List`
to `replicaCollection` type is to call
`[SystemReplicas.getSystemReplicas|https://github.com/apache/cassandra/blob/8b429c8ef9d9907dc3a435ffe7371ec69a9a85e5/src/java/org/apache/cassandra/locator/SystemReplicas.java#L50]`
which specifically lists batchlog as a valid use case
For "{+}Why not go with Dynamic Snitch?"{+} [~mck] and [~maximc] provide strong
arguments against Dynamic snitch. That it is often not enabled, and that
requiring users to take an action to change their snitch to get this fixed
isn't ideal, and could impact performance elsewhere. IFailureDetector's PHI
might be a good alternative, but I'm not entirely sure it works how you expect:
{quote}A couple of assumptions here:
...
The lower PHI value is, the faster responses from a node arrive. It looks this
way from CASSANDRA-2597 explanation regarding ArrivalWindow and the [official
PHI
paper|https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.7427=rep1=pdf].
{quote}
I had a different understanding after reading CASSANDRA-2597. It sounds to me
like Failure detector and dynamic snitch use different calculations, and *that
Dynamic Snitch does sort by lowest latency, but failure detector does not*
{quote}the developer found that the {{score()}} values were going _down_ for
nodes with higher average latency instead of up ... the phi accrual failure
detector assigns higher badness values to nodes with a low recent latency than
to nodes with high recent latency
{quote}
Have you been able to test and confirm that the failure detector PHI is
behaving as you expect?
> Single slow node dramatically reduces cluster write throughput regardless of
> CL
> ---
>
> Key: CASSANDRA-18120
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18120
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Dan Sarisky
>Assignee: Maxim Chanturiay
>Priority: Normal
>
> We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO,
> QUORUM, or LOCAL_QUORUM)
>
> On clusters of any size - a single extremely slow node causes a ~90% loss of
> cluster-wide throughput using batched writes. We can replicate this in the
> lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1.
>
> It appears the mechanism in play is:
> Those logged batches are immediately written to two replica nodes and the
> actual mutations aren't processed until those two nodes acknowledge the batch
> statements. Those replica nodes are selected randomly from all nodes in the
> local data center currently up in gossip. If a single node is slow, but
> still thought to be up in gossip, this eventually causes every other node to
> have all of its MutationStages to be waiting while the slow replica accepts
> batch writes.
>
> The code in play appears to be:
> See
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245].
> In the method filterBatchlogEndpoints() there is a
> Collections.shuffle() to order the endpoints and a
> FailureDetector.isEndpointAlive() to test if the endpoint is acceptable.
>
> This behavior causes Cassandra to move from a multi-node fault tolerant
> system toa collection of single points of failure.
>
> We try to take administrator actions to kill off the extremely slow nodes,
> but it would be great to have some notion of "what node is a bad choice" when
> writing log batches to replica nodes.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe,
[jira] [Created] (CASSANDRA-19457) Memory Leak of `DefaultSession`
Jane He created CASSANDRA-19457:
---
Summary: Memory Leak of `DefaultSession`
Key: CASSANDRA-19457
URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
Project: Cassandra
Issue Type: Bug
Components: Client/java-driver
Reporter: Jane He
Assignee: Jane He
There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
reproduced by this:
{code:java}
public static void main(String[] args) throws InterruptedException {
Semaphore sema = new Semaphore(20);
for (int i = 0; i < 1; i++) {
new Thread(() -> {
try {
sema.acquire();
try(CqlSession session = CqlSession.builder()
.withCloudSecureConnectBundle(Paths.get("bundle.zip"))
.withAuthCredentials("token", "")
.build()) {
// Do stuff
}
} catch (Exception e) {
System.out.println(e);
} finally {
sema.release();
}
}).start();
}
}{code}
On initial investigation, it seems like
{{MicrometerMetricUpdater.initializeGauge()}} uses
{{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
strong reference that is causing the issue.
--
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-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19453:
-
Fix Version/s: 5.0-beta2
5.1
(was: 5.x)
(was: 5.0-rc)
Since Version: 5.0-alpha1
Source Control Link:
https://github.com/apache/cassandra/commit/194a41baea93b00a369e6fecd8f2271ec71e99a6
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks for the review, committed.
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-beta2, 5.1
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
>
(cassandra) 01/01: Merge branch 'cassandra-5.0' into trunk
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 commit 8b429c8ef9d9907dc3a435ffe7371ec69a9a85e5 Merge: 001f70367e 194a41baea Author: Brandon Williams AuthorDate: Mon Mar 4 14:18:28 2024 -0600 Merge branch 'cassandra-5.0' into trunk CHANGES.txt | 1 + conf/jvm17-server.options | 1 + 2 files changed, 2 insertions(+) diff --cc CHANGES.txt index f3c3096705,225b9192e7..ec63666e67 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,25 -1,5 +1,26 @@@ -5.0-beta2 +5.1 + * Harry model and in-JVM tests for partition-restricted 2i queries (CASSANDRA-18275) + * Refactor cqlshmain global constants (CASSANDRA-19201) + * Remove native_transport_port_ssl (CASSANDRA-19397) + * Make nodetool reconfigurecms sync by default and add --cancel to be able to cancel ongoing reconfigurations (CASSANDRA-19216) + * Expose auth mode in system_views.clients, nodetool clientstats, metrics (CASSANDRA-19366) + * Remove sealed_periods and last_sealed_period tables (CASSANDRA-19189) + * Improve setup and initialisation of LocalLog/LogSpec (CASSANDRA-19271) + * Refactor structure of caching metrics and expose auth cache metrics via JMX (CASSANDRA-17062) + * Allow CQL client certificate authentication to work without sending an AUTHENTICATE request (CASSANDRA-18857) + * Extend nodetool tpstats and system_views.thread_pools with detailed pool parameters (CASSANDRA-19289) + * Remove dependency on Sigar in favor of OSHI (CASSANDRA-16565) + * Simplify the bind marker and Term logic (CASSANDRA-18813) + * Limit cassandra startup to supported JDKs, allow higher JDKs by setting CASSANDRA_JDK_UNSUPPORTED (CASSANDRA-18688) + * Standardize nodetool tablestats formatting of data units (CASSANDRA-19104) + * Make nodetool tablestats use number of significant digits for time and average values consistently (CASSANDRA-19015) + * Upgrade jackson to 2.15.3 and snakeyaml to 2.1 (CASSANDRA-18875) + * Transactional Cluster Metadata [CEP-21] (CASSANDRA-18330) + * Add ELAPSED command to cqlsh (CASSANDRA-18861) + * Add the ability to disable bulk loading of SSTables (CASSANDRA-18781) + * Clean up obsolete functions and simplify cql_version handling in cqlsh (CASSANDRA-18787) +Merged from 5.0: + * Fix remote JMX under Java17 (CASSANDRA-19453) * Avoid consistency violations for SAI intersections over unrepaired data at consistency levels requiring reconciliation (CASSANDRA-19018) * Fix NullPointerException in ANN+WHERE when adding rows in another partition (CASSANDRA-19404) * Record latencies for SAI post-filtering reads against local storage (CASSANDRA-18940) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra) branch trunk updated (001f70367e -> 8b429c8ef9)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 001f70367e Harry model and in-JVM tests for partition-restricted 2i queries new 194a41baea Add export for remote JMX security for j17 new 8b429c8ef9 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: CHANGES.txt | 1 + conf/jvm17-server.options | 1 + 2 files changed, 2 insertions(+) - 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: Add export for remote JMX security for j17
This is an automated email from the ASF dual-hosted git repository. brandonwilliams 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 194a41baea Add export for remote JMX security for j17 194a41baea is described below commit 194a41baea93b00a369e6fecd8f2271ec71e99a6 Author: Brandon Williams AuthorDate: Mon Mar 4 06:24:51 2024 -0600 Add export for remote JMX security for j17 Patch by brandonwilliams; reviewed by smiklosovic for CASSANDRA-19453 --- CHANGES.txt | 1 + conf/jvm17-server.options | 1 + 2 files changed, 2 insertions(+) diff --git a/CHANGES.txt b/CHANGES.txt index 9808945582..225b9192e7 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 5.0-beta2 + * Fix remote JMX under Java17 (CASSANDRA-19453) * Avoid consistency violations for SAI intersections over unrepaired data at consistency levels requiring reconciliation (CASSANDRA-19018) * Fix NullPointerException in ANN+WHERE when adding rows in another partition (CASSANDRA-19404) * Record latencies for SAI post-filtering reads against local storage (CASSANDRA-18940) diff --git a/conf/jvm17-server.options b/conf/jvm17-server.options index bc084c920e..1a0f8f9c56 100644 --- a/conf/jvm17-server.options +++ b/conf/jvm17-server.options @@ -64,6 +64,7 @@ -Djdk.attach.allowAttachSelf=true --add-exports java.base/jdk.internal.misc=ALL-UNNAMED --add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED +--add-exports java.management/com.sun.jmx.remote.security=ALL-UNNAMED --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED --add-exports java.rmi/sun.rmi.server=ALL-UNNAMED --add-exports java.sql/java.sql=ALL-UNNAMED - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19355) Accord: PreLoadContext must properly and consistently support ranges
[ https://issues.apache.org/jira/browse/CASSANDRA-19355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-19355: --- Labels: pull-request-available (was: ) > Accord: PreLoadContext must properly and consistently support ranges > > > Key: CASSANDRA-19355 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19355 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > There are some mechanisms for ensuring range transactions are loaded for > range transactions, but they do not currently work properly (having several > race conditions), are potentially costly in terms of memory consumption, and > are inconsistent with how they work for key transactions. -- 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-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19453:
--
Status: Ready to Commit (was: Review In Progress)
+1
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
>
[jira] [Updated] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19453:
--
Reviewers: Stefan Miklosovic, Stefan Miklosovic
Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
>
[jira] [Updated] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19453:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
>
[jira] [Created] (CASSANDRA-19456) caas_repair should use TLS 1.3
Brad Schoening created CASSANDRA-19456: -- Summary: caas_repair should use TLS 1.3 Key: CASSANDRA-19456 URL: https://issues.apache.org/jira/browse/CASSANDRA-19456 Project: Cassandra Issue Type: Improvement Reporter: Brad Schoening Attachments: image-2024-03-04-13-09-49-321.png It's best practice to let the driver & server auto negotiate the TLS version, which should usually be TLS 1.3. Based on clientstats, it looks like the driver is forcing the protocol to the older TLS 1.2. Would suggest removing any TLS versions from the code and just letting it auto-negotiate TLS. !image-2024-03-04-13-09-49-321.png! -- 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-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823154#comment-17823154
]
Brandon Williams edited comment on CASSANDRA-19453 at 3/4/24 5:55 PM:
--
Looks like we just need to export JMX remote security in j17.
||Branch||CI||
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1498/workflows/21dfb9c9-702e-490d-8889-498fde621cbd],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1498/workflows/61189194-785b-4495-ac05-1b63df7540ca]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1499/workflows/20153741-3295-4db0-909b-fa902460a5e3],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1499/workflows/7c2366fe-1655-4cda-a7f5-a6a06c59a1d3]|
was (Author: brandon.williams):
Looks like we just need to export JMX remote security in j17.
||Branch||CI||
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1493/workflows/51d6ff2f-16ce-4cfc-ab7e-8617ed8b01e3],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1493/workflows/1d865623-67bf-4b90-968f-142a89857741]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1494/workflows/39f12071-515e-4fe8-8a38-108514c903ed],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1494/workflows/69a0dfa5-901e-4cd0-ad77-cfaa3714d655]|
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
>
[jira] [Commented] (CASSANDRA-19428) Clean up KeyRangeItearor classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823256#comment-17823256 ] Ekaterina Dimitrova commented on CASSANDRA-19428: - I think it is small but I do not want to block 5.0 where almost all tickets are closed. I will try to quickly create the patch today and if it goes fast it can get in 5.0. I will ping you when I am done, [~maedhroz], if you have time :-) > Clean up KeyRangeItearor classes > > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 5.x > > > Remove KeyRangeIterator.current and simplify -- 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-15452) Improve disk access patterns during compaction and streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-15452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRA-15452: --- Summary: Improve disk access patterns during compaction and streaming (was: Improve disk access patterns during compaction compaction) > Improve disk access patterns during compaction and streaming > > > Key: CASSANDRA-15452 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15452 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths, Local/Compaction >Reporter: Jon Haddad >Priority: Normal > Attachments: results.txt, sequential.fio > > > On read heavy workloads Cassandra performs much better when using a low read > ahead setting. In my tests I've seen an 5x improvement in throughput and > more than a 50% reduction in latency. However, I've also observed that it > can have a negative impact on compaction and streaming throughput. It > especially negatively impacts cloud environments where small reads incur high > costs in IOPS due to tiny requests. > # We should investigate using POSIX_FADV_DONTNEED on files we're compacting > to see if we can improve performance and reduce page faults. > # This should be combined with an internal read ahead style buffer that > Cassandra manages, similar to a BufferedInputStream but with our own > machinery. This buffer should read fairly large blocks of data off disk at > at time. EBS, for example, allows 1 IOP to be up to 256KB. A considerable > amount of time is spent in blocking I/O during compaction and streaming. > Reducing the frequency we read from disk should speed up all sequential I/O > operations. -- 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-19398) Test Failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading
[
https://issues.apache.org/jira/browse/CASSANDRA-19398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823255#comment-17823255
]
Brandon Williams edited comment on CASSANDRA-19398 at 3/4/24 4:32 PM:
--
I see what you mean, nothing is guaranteed whatsoever in the current state.
was (Author: brandon.williams):
I see what you mean, nothing is guarantee whatsoever in the current state.
> Test Failure:
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading
> --
>
> Key: CASSANDRA-19398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19398
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2646/workflows/bc2bba74-9e56-4bea-8de7-4ff840c4f450/jobs/56028/tests#failed-test-0]
> {code:java}
> junit.framework.AssertionFailedError at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading(UpgradeSSTablesTest.java:220)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
--
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-19398) Test Failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading
[
https://issues.apache.org/jira/browse/CASSANDRA-19398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823255#comment-17823255
]
Brandon Williams commented on CASSANDRA-19398:
--
I see what you mean, nothing is guarantee whatsoever in the current state.
> Test Failure:
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading
> --
>
> Key: CASSANDRA-19398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19398
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2646/workflows/bc2bba74-9e56-4bea-8de7-4ff840c4f450/jobs/56028/tests#failed-test-0]
> {code:java}
> junit.framework.AssertionFailedError at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading(UpgradeSSTablesTest.java:220)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
--
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-18951) Add option for MutualTlsAuthenticator to restrict the certificate age
[
https://issues.apache.org/jira/browse/CASSANDRA-18951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-18951:
--
Reviewers: Abe Ratnofsky, Andy Tolbert
Status: Review In Progress (was: Patch Available)
> Add option for MutualTlsAuthenticator to restrict the certificate age
> -
>
> Key: CASSANDRA-18951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18951
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Authorization
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> In {{org.apache.cassandra.auth.MutualTlsAuthenticator}}, we validate that a
> certificate is valid by looking at the identities inside the
> certificate and making sure the identity exists in the identity to role table.
> In some situations we may want to restrict the certificates
> we accept by rejecting certificates older than x amount of days. Some
> certificates can be generated with long expiration dates,
> and this might be undesired when you want to protect against potential
> certificates being compromised. For that reason, it is
> important to add an option, that when configured, we can limit the age of the
> certificate we accept for mTLS authentication.
> When enabled, this will force clients to have to renew certificates more
> frequently, reducing the exposure of a Cassandra cluster
> to leaked certificates.
--
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-19327) Test Failure: org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest[Small partition restricted high high]-system_keyspace_directory_jdk17
[
https://issues.apache.org/jira/browse/CASSANDRA-19327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremiah Jordan updated CASSANDRA-19327:
Resolution: Not A Problem
Status: Resolved (was: Open)
> Test Failure:
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest[Small
> partition restricted high high]-system_keyspace_directory_jdk17
>
>
> Key: CASSANDRA-19327
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19327
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> Seen here:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2629/workflows/75f57272-f299-40e1-8e4f-fdb75bca2f7c/jobs/53821/tests]
> The tests were run with _memtable_allocation_type: heap_buffers_ (By default
> we run them now with offheap_objects, to be changed in CASSANDRA-19326)
> {code:java}
> junit.framework.AssertionFailedError: Got less rows than expected. Expected
> 16 but got 0 at
> org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1880) at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.lambda$runRestrictedQueries$3(RandomIntersectionTest.java:118)
> at
> org.apache.cassandra.cql3.CQLTester.beforeAndAfterFlush(CQLTester.java:2269)
> at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.runRestrictedQueries(RandomIntersectionTest.java:104)
> at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest(RandomIntersectionTest.java:95)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36){code}
> CC [~maedhroz]
--
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-19428) Clean up KeyRangeItearor classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-19428: Reviewers: Caleb Rackliffe > Clean up KeyRangeItearor classes > > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 5.x > > > Remove KeyRangeIterator.current and simplify -- 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-19327) Test Failure: org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest[Small partition restricted high high]-system_keyspace_directory_jdk1
[
https://issues.apache.org/jira/browse/CASSANDRA-19327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823239#comment-17823239
]
Caleb Rackliffe commented on CASSANDRA-19327:
-
tl;dr Let's close this.
CASSANDRA-19018 and CASSANDRA-19278 fixed so many things, and these tests were
run many hundreds of times (albeit not via the multiplexer).
> Test Failure:
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest[Small
> partition restricted high high]-system_keyspace_directory_jdk17
>
>
> Key: CASSANDRA-19327
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19327
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> Seen here:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2629/workflows/75f57272-f299-40e1-8e4f-fdb75bca2f7c/jobs/53821/tests]
> The tests were run with _memtable_allocation_type: heap_buffers_ (By default
> we run them now with offheap_objects, to be changed in CASSANDRA-19326)
> {code:java}
> junit.framework.AssertionFailedError: Got less rows than expected. Expected
> 16 but got 0 at
> org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1880) at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.lambda$runRestrictedQueries$3(RandomIntersectionTest.java:118)
> at
> org.apache.cassandra.cql3.CQLTester.beforeAndAfterFlush(CQLTester.java:2269)
> at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.runRestrictedQueries(RandomIntersectionTest.java:104)
> at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest(RandomIntersectionTest.java:95)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36){code}
> CC [~maedhroz]
--
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-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823236#comment-17823236
]
Caleb Rackliffe commented on CASSANDRA-19454:
-
Go for it! Reach out to me or [~dcapwell] if you have any questions or need
review ;)
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
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-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe reassigned CASSANDRA-19454:
---
Assignee: Arun Ganesh (was: Caleb Rackliffe)
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
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-19428) Clean up KeyRangeItearor classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Fix Version/s: 5.x > Clean up KeyRangeItearor classes > > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 5.x > > > Remove KeyRangeIterator.current and simplify -- 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-19327) Test Failure: org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest[Small partition restricted high high]-system_keyspace_directory_jdk1
[
https://issues.apache.org/jira/browse/CASSANDRA-19327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823225#comment-17823225
]
Ekaterina Dimitrova commented on CASSANDRA-19327:
-
There is no RandomIntersectionTest class anymore.
CASSANDRA-19278 introduced RandomIntersectionTester extended by
RandomMixedIntersectionTest, RandomMixedPartitionIntersectionTest,
RandomRegularIntersectionTest, RandomRegularPartitionIntersectionTest,
RandomStaticIntersectionTest, RandomStaticPartitionIntersectionTest,
TwoRegularOneStaticIntersectionTest,
TwoRegularOneStaticPartitionIntersectionTest.
[~maedhroz], were those checked in a loop for flakiness? Shall we close this
ticket?
> Test Failure:
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest[Small
> partition restricted high high]-system_keyspace_directory_jdk17
>
>
> Key: CASSANDRA-19327
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19327
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> Seen here:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2629/workflows/75f57272-f299-40e1-8e4f-fdb75bca2f7c/jobs/53821/tests]
> The tests were run with _memtable_allocation_type: heap_buffers_ (By default
> we run them now with offheap_objects, to be changed in CASSANDRA-19326)
> {code:java}
> junit.framework.AssertionFailedError: Got less rows than expected. Expected
> 16 but got 0 at
> org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1880) at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.lambda$runRestrictedQueries$3(RandomIntersectionTest.java:118)
> at
> org.apache.cassandra.cql3.CQLTester.beforeAndAfterFlush(CQLTester.java:2269)
> at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.runRestrictedQueries(RandomIntersectionTest.java:104)
> at
> org.apache.cassandra.index.sai.cql.RandomIntersectionTest.randomIntersectionTest(RandomIntersectionTest.java:95)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36){code}
> CC [~maedhroz]
--
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-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823154#comment-17823154
]
Brandon Williams edited comment on CASSANDRA-19453 at 3/4/24 3:01 PM:
--
Looks like we just need to export JMX remote security in j17.
||Branch||CI||
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1493/workflows/51d6ff2f-16ce-4cfc-ab7e-8617ed8b01e3],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1493/workflows/1d865623-67bf-4b90-968f-142a89857741]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1494/workflows/39f12071-515e-4fe8-8a38-108514c903ed],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1494/workflows/69a0dfa5-901e-4cd0-ad77-cfaa3714d655]|
was (Author: brandon.williams):
Looks like we just need to export JMX remote security in j17.
||Branch||CI||
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1489/workflows/0472537f-9cc6-49b7-a910-1dca612f901d],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1489/workflows/b6234e38-c93c-4db9-86f9-eb35053deb4b]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1490/workflows/33b5d443-abad-40c2-bfc3-bd9fb0a03cb6],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1490/workflows/5a46bbb9-992f-42ed-8b6a-fcda1c413245]|
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
>
[jira] [Commented] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823217#comment-17823217
]
Stefan Miklosovic commented on CASSANDRA-14572:
---
yeah just put it here as comment or add it as attachment
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823214#comment-17823214
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
[~smiklosovic] I agree, no need to commit the script to the patch itself. I was
thinking of putting it here in the comments, or on the gist. That way everyone
can use it.
Anyway, thank you for the comments, I've fixed all of them.
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-19384) Avoid exposing intermediate node state during startup
[ https://issues.apache.org/jira/browse/CASSANDRA-19384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-19384: Status: Ready to Commit (was: Changes Suggested) +1 > Avoid exposing intermediate node state during startup > - > > Key: CASSANDRA-19384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19384 > Project: Cassandra > Issue Type: Bug > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Attachments: ci_summary-1.html, ci_summary.html, > result_details.tar-1.gz, result_details.tar.gz > > Time Spent: 20m > Remaining Estimate: 0h > > During startup we replay the local log, during this time we might expose > intermediate node states (via JMX for example). -- 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-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823173#comment-17823173
]
Stefan Miklosovic commented on CASSANDRA-19453:
---
Thanks [~brandon.williams], I reproduced the problem, finally, and verified
that your suggested patch works.
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
>
[jira] [Commented] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823154#comment-17823154
]
Brandon Williams commented on CASSANDRA-19453:
--
Looks like we just need to export JMX remote security in j17.
||Branch||CI||
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-5.0]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1489/workflows/0472537f-9cc6-49b7-a910-1dca612f901d],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1489/workflows/b6234e38-c93c-4db9-86f9-eb35053deb4b]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-19453-trunk]|[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/1490/workflows/33b5d443-abad-40c2-bfc3-bd9fb0a03cb6],
[j17|https://app.circleci.com/pipelines/github/driftx/cassandra/1490/workflows/5a46bbb9-992f-42ed-8b6a-fcda1c413245]|
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
>
[jira] [Updated] (CASSANDRA-19455) Create Trigger is not working on 4.x version cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19455: -- Resolution: Not A Problem Status: Resolved (was: Open) > Create Trigger is not working on 4.x version cassandra > -- > > Key: CASSANDRA-19455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19455 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Hakan OTAL >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x > > > Current version is 3.11.16 , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both > of 4.x version gives below error. > > Reload triggers is executed , custom trigger jar put in correct path > "../conf/triggers". > > cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct > USING 'com..cassandra.trigger.RadAcctTrigger'; > > InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger > class 'com..cassandra.trigger.RadAcctTrigger' couldn't be loaded" > > -- 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-19455) Create Trigger is not working on 4.x version cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823149#comment-17823149 ] Stefan Miklosovic commented on CASSANDRA-19455: --- Because you just can not move the trigger jar from 3.11 to 4.0. There are likely issues as I mentioned above: _Now it is worth to say that implementation-wise, the trigger in examples in 3.11 does differ from the one in 4.0, there are changed imports etc so it is not the same thing. The trigger for 4.0 has to be specifically tailored to that version and it is not 1:1 replacement._ Are you sure your trigger source code does compile against Cassandra 4.0 code base? > Create Trigger is not working on 4.x version cassandra > -- > > Key: CASSANDRA-19455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19455 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Hakan OTAL >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x > > > Current version is 3.11.16 , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both > of 4.x version gives below error. > > Reload triggers is executed , custom trigger jar put in correct path > "../conf/triggers". > > cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct > USING 'com..cassandra.trigger.RadAcctTrigger'; > > InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger > class 'com..cassandra.trigger.RadAcctTrigger' couldn't be loaded" > > -- 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-19455) Create Trigger is not working on 4.x version cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823150#comment-17823150 ] Stefan Miklosovic commented on CASSANDRA-19455: --- Hah we posted at the same time. Yeah that is what I am talking about. > Create Trigger is not working on 4.x version cassandra > -- > > Key: CASSANDRA-19455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19455 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Hakan OTAL >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x > > > Current version is 3.11.16 , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both > of 4.x version gives below error. > > Reload triggers is executed , custom trigger jar put in correct path > "../conf/triggers". > > cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct > USING 'com..cassandra.trigger.RadAcctTrigger'; > > InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger > class 'com..cassandra.trigger.RadAcctTrigger' couldn't be loaded" > > -- 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-19455) Create Trigger is not working on 4.x version cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823148#comment-17823148 ] Hakan OTAL commented on CASSANDRA-19455: Our development team compiled our custom Cassandra trigger source codes with Cassandra 4.1.x dependencies and it works now . We observed that it was not possible to move from 3.X to 4.x without changing the custom trigger source code without related version dependencies. They are trying with 4.0.x dependencies ,let me inform you. > Create Trigger is not working on 4.x version cassandra > -- > > Key: CASSANDRA-19455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19455 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Hakan OTAL >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x > > > Current version is 3.11.16 , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both > of 4.x version gives below error. > > Reload triggers is executed , custom trigger jar put in correct path > "../conf/triggers". > > cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct > USING 'com..cassandra.trigger.RadAcctTrigger'; > > InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger > class 'com..cassandra.trigger.RadAcctTrigger' couldn't be loaded" > > -- 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-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19453:
-
Resolution: (was: Invalid)
Status: Open (was: Resolved)
Hmm, this is indeed a problem. Removing compilation from the equation, I
downloaded the beta-1 binary, enabled remote JMX, and indeed it fails like this.
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
>
[jira] [Assigned] (CASSANDRA-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-19453:
Assignee: Brandon Williams
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 common frames omitted
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
>
[jira] [Commented] (CASSANDRA-19455) Create Trigger is not working on 4.x version cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823134#comment-17823134 ] Hakan OTAL commented on CASSANDRA-19455: Hi Stefan Miklosovic , Before starting to migration steps , i want to check all functionality is running , so i create 3 node cluster cassanda 4.x version on my lab , created a keyspace and created a table than try to create triggers and it gave me related error. > Create Trigger is not working on 4.x version cassandra > -- > > Key: CASSANDRA-19455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19455 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Hakan OTAL >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x > > > Current version is 3.11.16 , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both > of 4.x version gives below error. > > Reload triggers is executed , custom trigger jar put in correct path > "../conf/triggers". > > cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct > USING 'com..cassandra.trigger.RadAcctTrigger'; > > InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger > class 'com..cassandra.trigger.RadAcctTrigger' couldn't be loaded" > > -- 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-19455) Create Trigger is not working on 4.x version cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823124#comment-17823124 ] Stefan Miklosovic edited comment on CASSANDRA-19455 at 3/4/24 10:56 AM: Steps I did: 1) git checkout cassandra-3.11 2) ant artifacts 3) cd examples/triggers && ant 3) copied and extracted tarball into /tmp and copied trigger jar from 3) to conf/triggers 4) started Cassandra 3.11, created tables and triggeer, inserted some data and I see records in test.audit table as per example in examples/triggers 5) shut down Cassandra 3.11, checkouted cassandra-4.0 branch, ant artifacts, cd examples/triggers && ant, copied tarball to /tmp, extracted and copied trigger to conf/triggers, copied all data dir from cassandra-3.11 to cassandra-4.0 6) started 4.0, inserted more data to tables as per example, trigger creates new entries in test.audit Now it is worth to say that implementation-wise, the trigger in examples in 3.11 does differ from the one in 4.0, there are changed imports etc so it is not the same thing. The trigger for 4.0 has to be specifically tailored to that version and it is not 1:1 replacement. I would suggest to triple check if the trigger jar is properly implemented for Cassandra 4.0 as moving a jar from 3.11 to 4.0 and expect it to work might be problematic and probably does not work if imports are not aligned etc. I also do not understand why the author of this ticket tries to create a trigger again if it was already existing in 3.11 already and he just bumped the cassandra tarball as such but data dir was same for 3.11 / 4.0. was (Author: smiklosovic): Steps I did: 1) git checkout cassandra-3.11 2) ant artifacts 3) cd examples/triggers && ant 3) copied and extracted tarball into /tmp and copied trigger jar from 3) to conf/triggers 4) started Cassandra 3.11, created tables and triggeer, inserted some data and I see records in test.audit table as per example in examples/triggers 5) shut down Cassandra 3.11, checkouted cassandra-4.0 branch, ant artifacts, cd examples/triggers && ant, copied tarball to /tmp, extracted and copied trigger to conf/triggers, copied all data dir from cassandra-3.11 to cassandra-4.0 6) started 4.0, inserted more data to tables as per example, trigger creates new entries in test.audit Now it is worth to say that implementation-wise, the trigger in examples in 3.11 does differ from the one in 4.0, there are changed imports etc so it is not the same thing. The trigger for 4.0 has to be specifically tailored to that version and it is not 1:1 replacement. I would suggest to triple check if the trigger jar loads fine and if it does not why it is so. I also do not understand why the author of this ticket tries to create a trigger again if it was already existing in 3.11 already and he just bumped the cassandra tarball as such but data dir was same for 3.11 / 4.0. > Create Trigger is not working on 4.x version cassandra > -- > > Key: CASSANDRA-19455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19455 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Hakan OTAL >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x > > > Current version is 3.11.16 , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both > of 4.x version gives below error. > > Reload triggers is executed , custom trigger jar put in correct path > "../conf/triggers". > > cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct > USING 'com..cassandra.trigger.RadAcctTrigger'; > > InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger > class 'com..cassandra.trigger.RadAcctTrigger' couldn't be loaded" > > -- 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-19455) Create Trigger is not working on 4.x version cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-19455: - Assignee: Stefan Miklosovic (was: Brandon Williams) > Create Trigger is not working on 4.x version cassandra > -- > > Key: CASSANDRA-19455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19455 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Hakan OTAL >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x > > > Current version is 3.11.16 , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both > of 4.x version gives below error. > > Reload triggers is executed , custom trigger jar put in correct path > "../conf/triggers". > > cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct > USING 'com..cassandra.trigger.RadAcctTrigger'; > > InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger > class 'com..cassandra.trigger.RadAcctTrigger' couldn't be loaded" > > -- 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-19455) Create Trigger is not working on 4.x version cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823126#comment-17823126 ] Stefan Miklosovic commented on CASSANDRA-19455: --- I moved this to "in progress" by mistake, what I mean was to await for feedback but I do not see how to do this. > Create Trigger is not working on 4.x version cassandra > -- > > Key: CASSANDRA-19455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19455 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Hakan OTAL >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > > Current version is 3.11.16 , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both > of 4.x version gives below error. > > Reload triggers is executed , custom trigger jar put in correct path > "../conf/triggers". > > cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct > USING 'com..cassandra.trigger.RadAcctTrigger'; > > InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger > class 'com..cassandra.trigger.RadAcctTrigger' couldn't be loaded" > > -- 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-19455) Create Trigger is not working on 4.x version cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-19455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823124#comment-17823124 ] Stefan Miklosovic commented on CASSANDRA-19455: --- Steps I did: 1) git checkout cassandra-3.11 2) ant artifacts 3) cd examples/triggers && ant 3) copied and extracted tarball into /tmp and copied trigger jar from 3) to conf/triggers 4) started Cassandra 3.11, created tables and triggeer, inserted some data and I see records in test.audit table as per example in examples/triggers 5) shut down Cassandra 3.11, checkouted cassandra-4.0 branch, ant artifacts, cd examples/triggers && ant, copied tarball to /tmp, extracted and copied trigger to conf/triggers, copied all data dir from cassandra-3.11 to cassandra-4.0 6) started 4.0, inserted more data to tables as per example, trigger creates new entries in test.audit Now it is worth to say that implementation-wise, the trigger in examples in 3.11 does differ from the one in 4.0, there are changed imports etc so it is not the same thing. The trigger for 4.0 has to be specifically tailored to that version and it is not 1:1 replacement. I would suggest to triple check if the trigger jar loads fine and if it does not why it is so. I also do not understand why the author of this ticket tries to create a trigger again if it was already existing in 3.11 already and he just bumped the cassandra tarball as such but data dir was same for 3.11 / 4.0. > Create Trigger is not working on 4.x version cassandra > -- > > Key: CASSANDRA-19455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19455 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Hakan OTAL >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > > Current version is 3.11.16 , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both > of 4.x version gives below error. > > Reload triggers is executed , custom trigger jar put in correct path > "../conf/triggers". > > cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct > USING 'com..cassandra.trigger.RadAcctTrigger'; > > InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger > class 'com..cassandra.trigger.RadAcctTrigger' couldn't be loaded" > > -- 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-19398) Test Failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading
[
https://issues.apache.org/jira/browse/CASSANDRA-19398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823077#comment-17823077
]
Berenguer Blasi commented on CASSANDRA-19398:
-
Yes they are intended to be ran simultaneously imo as well. You just have no
warranties that will be the case. The truncate might complete and the upgrade
might have not even started yet i.e.
> Test Failure:
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading
> --
>
> Key: CASSANDRA-19398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19398
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2646/workflows/bc2bba74-9e56-4bea-8de7-4ff840c4f450/jobs/56028/tests#failed-test-0]
> {code:java}
> junit.framework.AssertionFailedError at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading(UpgradeSSTablesTest.java:220)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
--
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-19453) Enabling remote JMX fails to start
[
https://issues.apache.org/jira/browse/CASSANDRA-19453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823074#comment-17823074
]
Angelo Polo commented on CASSANDRA-19453:
-
I'm getting the exact same error with 5.0-beta1. This is a fresh install on a
fresh Amazon Linux 2023 on arm64 instance. JAVA_HOME seems to be correct.
{code:java}
$ java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)
$ which java
/usr/local/bin/jdk-17.0.2/bin/java
$ echo $JAVA_HOME
/usr/local/bin/jdk-17.0.2
$ echo $CASSANDRA_CONF
/home/cassandra/c_conf/5.0-beta1_01
$ echo $CASSANDRA_HOME
/usr/local/bin/apache-cassandra-5.0-beta1
{code}
("XXX"s indicate redaction.)
{code:java}
$ cd $CASSANDRA_CONF
$ diff cassandra.yaml.bak cassandra.yaml
11c11
< cluster_name: 'Test Cluster'
---
> cluster_name: 'XX'
154c154
< class_name : org.apache.cassandra.auth.AllowAllAuthenticator
---
> class_name : org.apache.cassandra.auth.PasswordAuthenticator
169c169
< authorizer: AllowAllAuthorizer
---
> authorizer: CassandraAuthorizer
974c974
< rpc_address: localhost
---
> rpc_address: XXX-XXX-XXX-XXX
$ diff cassandra-env.sh.bak cassandra-env.sh
206c206
< # JVM_OPTS="$JVM_OPTS -Djava.rmi.server.hostname="
---
> JVM_OPTS="$JVM_OPTS
> -Djava.rmi.server.hostname=ec2-XXX-XXX-XXX-XXX.compute-1.amazonaws.com"
216a217
> LOCAL_JMX=no
224c225
< JMX_PORT="7199"
---
> JMX_PORT="7488"
{code}
Get the same error whether or not I set "java.rmi.server.hostname".
If I do not set "LOCAL_JMX=no" in cassandra-env.sh, it runs fine.
Any ideas what could be wrong?
> Enabling remote JMX fails to start
> --
>
> Key: CASSANDRA-19453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19453
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
>
> If you set LOCAL_JMX to something other than 'yes' in conf/cassandra-env.sh,
> you receive:
> {noformat}
> Exception (java.lang.ExceptionInInitializerError) encountered during startup:
> null
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
> org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:172)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:240)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:721)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:855)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:306)
> ... 7 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> com.sun.jmx.remote.security.JMXPluggableAuthenticator.[Ljava.lang.Object;@afb5821/invokeSpecial,
> from class
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper
> (unnamed module @51dcb805)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:3882)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorCommon(MethodHandles.java:4117)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectConstructorNoSecurityManager(MethodHandles.java:4111)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflectConstructor(MethodHandles.java:3433)
> at
> org.apache.cassandra.utils.JMXServerUtils$JMXPluggableAuthenticatorWrapper.(JMXServerUtils.java:302)
> ... 7 more
> ERROR [main] 2024-03-01 06:16:00,028 CassandraDaemon.java:877 - Exception
> encountered during startup
> java.lang.ExceptionInInitializerError: null
> at
> org.apache.cassandra.utils.JMXServerUtils.configureJmxAuthentication(JMXServerUtils.java:188)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
> at
> org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:154)
> at
>
