[jira] [Commented] (CASSANDRA-18707) Test failure: junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASMultiDCTest-.jdk11
[
https://issues.apache.org/jira/browse/CASSANDRA-18707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764993#comment-17764993
]
Berenguer Blasi commented on CASSANDRA-18707:
-
I haven't been able to repro. {{testLocalSerialLocalCommit}} seems to be flaky
[in 4.1 as
well|https://ci-cassandra.apache.org/job/Cassandra-4.1/417/testReport/org.apache.cassandra.distributed.test/CASMultiDCTest/]
according to jenkins despite logs being lost by now already. #justfyi
> Test failure:
> junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASMultiDCTest-.jdk11
>
>
>
> Key: CASSANDRA-18707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18707
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit.framework/TestSuite/org_apache_cassandra_distributed_test_CASMultiDCTest__jdk11/]
> h3.
> {code:java}
> Error Message
> Schema agreement not reached. Schema versions of the instances:
> [ef1c8e05-a06d-388d-a46d-53cc22a94762, 6c386108-1805-3985-b48e-8016012a0207,
> 6c386108-1805-3985-b48e-8016012a0207, ef1c8e05-a06d-388d-a46d-53cc22a94762]
> Stacktrace
> java.lang.IllegalStateException: Schema agreement not reached. Schema
> versions of the instances: [ef1c8e05-a06d-388d-a46d-53cc22a94762,
> 6c386108-1805-3985-b48e-8016012a0207, 6c386108-1805-3985-b48e-8016012a0207,
> ef1c8e05-a06d-388d-a46d-53cc22a94762] at
> org.apache.cassandra.distributed.impl.AbstractCluster$ChangeMonitor.waitForCompletion(AbstractCluster.java:907)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.lambda$schemaChange$8(AbstractCluster.java:836)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {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-18707) Test failure: junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASMultiDCTest-.jdk11
[
https://issues.apache.org/jira/browse/CASSANDRA-18707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18707:
Fix Version/s: 4.1.x
> Test failure:
> junit.framework.TestSuite.org.apache.cassandra.distributed.test.CASMultiDCTest-.jdk11
>
>
>
> Key: CASSANDRA-18707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18707
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit.framework/TestSuite/org_apache_cassandra_distributed_test_CASMultiDCTest__jdk11/]
> h3.
> {code:java}
> Error Message
> Schema agreement not reached. Schema versions of the instances:
> [ef1c8e05-a06d-388d-a46d-53cc22a94762, 6c386108-1805-3985-b48e-8016012a0207,
> 6c386108-1805-3985-b48e-8016012a0207, ef1c8e05-a06d-388d-a46d-53cc22a94762]
> Stacktrace
> java.lang.IllegalStateException: Schema agreement not reached. Schema
> versions of the instances: [ef1c8e05-a06d-388d-a46d-53cc22a94762,
> 6c386108-1805-3985-b48e-8016012a0207, 6c386108-1805-3985-b48e-8016012a0207,
> ef1c8e05-a06d-388d-a46d-53cc22a94762] at
> org.apache.cassandra.distributed.impl.AbstractCluster$ChangeMonitor.waitForCompletion(AbstractCluster.java:907)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.lambda$schemaChange$8(AbstractCluster.java:836)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {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] [Assigned] (CASSANDRA-17798) Flaky org.apache.cassandra.tools TopPartitionsTest testServiceTopPartitionsSingleTable
[
https://issues.apache.org/jira/browse/CASSANDRA-17798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-17798:
---
Assignee: (was: Berenguer Blasi)
> Flaky org.apache.cassandra.tools TopPartitionsTest
> testServiceTopPartitionsSingleTable
> --
>
> Key: CASSANDRA-17798
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17798
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> h3.
> {code:java}
> Error Message
> If this failed you probably have to raise the beginLocalSampling duration
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: If this failed you probably have to
> raise the beginLocalSampling duration expected:<1> but was:<0> at
> org.apache.cassandra.tools.TopPartitionsTest.testServiceTopPartitionsSingleTable(TopPartitionsTest.java:83)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-02 01:49:49,333 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml DEBUG [main]
> 2022-08-02 01:49:49,339 YamlConfigurationLoader.java:124 - Loading settings
> from file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml INFO
> [main] 2022-08-02 01:49:49,642 Config.java:1167 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null; allow_extra_insecure
> ...[truncated 50809 chars]... lizing counter cache with capacity of 2 MiBs
> INFO [MemtableFlushWriter:1] 2022-08-02 01:49:53,519 CacheService.java:163 -
> Scheduling counter cache save to every 7200 seconds (going to save all keys).
> DEBUG [MemtableFlushWriter:1] 2022-08-02 01:49:53,575
> ColumnFamilyStore.java:1330 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/nb-1-big-Data.db')]
> (1 sstables, 4.915KiB), biggest 4.915KiB, smallest 4.915KiB
> {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] [Assigned] (CASSANDRA-17798) Flaky org.apache.cassandra.tools TopPartitionsTest testServiceTopPartitionsSingleTable
[
https://issues.apache.org/jira/browse/CASSANDRA-17798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-17798:
---
Assignee: Berenguer Blasi
> Flaky org.apache.cassandra.tools TopPartitionsTest
> testServiceTopPartitionsSingleTable
> --
>
> Key: CASSANDRA-17798
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17798
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> h3.
> {code:java}
> Error Message
> If this failed you probably have to raise the beginLocalSampling duration
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: If this failed you probably have to
> raise the beginLocalSampling duration expected:<1> but was:<0> at
> org.apache.cassandra.tools.TopPartitionsTest.testServiceTopPartitionsSingleTable(TopPartitionsTest.java:83)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-02 01:49:49,333 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml DEBUG [main]
> 2022-08-02 01:49:49,339 YamlConfigurationLoader.java:124 - Loading settings
> from file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml INFO
> [main] 2022-08-02 01:49:49,642 Config.java:1167 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null; allow_extra_insecure
> ...[truncated 50809 chars]... lizing counter cache with capacity of 2 MiBs
> INFO [MemtableFlushWriter:1] 2022-08-02 01:49:53,519 CacheService.java:163 -
> Scheduling counter cache save to every 7200 seconds (going to save all keys).
> DEBUG [MemtableFlushWriter:1] 2022-08-02 01:49:53,575
> ColumnFamilyStore.java:1330 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/nb-1-big-Data.db')]
> (1 sstables, 4.915KiB), biggest 4.915KiB, smallest 4.915KiB
> {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-18845) Waiting for gossip to settle on live endpoints
[
https://issues.apache.org/jira/browse/CASSANDRA-18845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764934#comment-17764934
]
Cameron Zemek commented on CASSANDRA-18845:
---
[~brandon.williams] [~smiklosovic] the existing conditions
{noformat}
currentSize == epSize && currentLive == liveSize{noformat}
are what stops it starting Native Transport too early if gossip is still being
updated (for example liveSize is changing).
waitToSettle waits by default 5 seconds then it starts polling every 1 second 3
times seeing if either liveSize or epSize changes and resets its numOkay if
either of these changes. The problem is when for example it took 79 seconds for
that first change in liveSize, liveSize was constantly at 1 so it goes okay
gossip is settled due to no changes in epSize or liveSize.
The extra condition therefore is don't consider gossip settled if there only 1
live endpoint (the node itself). Unless it's a single node cluster (epSize ==
liveSize)
> So when there is a cluster of 50 nodes, without this change, that "if" would
> return false (or it would not return true fast enough to increment numOkay to
> break from that while) as there would be new endpoints or live members
> detected each round.
To rephrase the problem is there is no new endpoints or live members changes.
waitToSettle will consider it settled with liveSize == 1 currently.
> why it takes almost minute and a half
This is a good question but in general it takes quite awhile for gossip to
complete on clusters with multiple datacenters and/or large number of nodes. I
think that is a different much more complex JIRA. The purpose of the attached
patch is so you don't need to guess what cassandra.gossip_settle_min_wait_ms to
use. It waits for at least one node to report is now UP in order to increment
numOkay and to continue with the rest of the waitToSettle logic.
!image-2023-09-14-11-16-23-020.png!
> Waiting for gossip to settle on live endpoints
> --
>
> Key: CASSANDRA-18845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18845
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Cameron Zemek
>Priority: Normal
> Attachments: 18845-3.11.patch, 18845-4.0.patch, 18845-4.1.patch,
> 18845-5.0.patch, image-2023-09-14-11-16-23-020.png
>
>
> This is a follow up to CASSANDRA-18543
> Although that ticket added ability to set cassandra.gossip_settle_min_wait_ms
> this is tedious and error prone. On a node just observed a 79 second gap
> between waiting for gossip and the first echo response to indicate a node is
> UP.
> The problem being that do not want to start Native Transport until gossip
> settles otherwise queries can fail consistency such as LOCAL_QUORUM as it
> thinks the replicas are still in DOWN state.
> Instead of having to set gossip_settle_min_wait_ms I am proposing that
> (outside single node cluster) wait for UP message from another node before
> considering gossip as settled. Eg.
> {code:java}
> if (currentSize == epSize && currentLive == liveSize && liveSize
> > 1)
> {
> logger.debug("Gossip looks settled.");
> numOkay++;
> } {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-18845) Waiting for gossip to settle on live endpoints
[
https://issues.apache.org/jira/browse/CASSANDRA-18845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cameron Zemek updated CASSANDRA-18845:
--
Attachment: image-2023-09-14-11-16-23-020.png
> Waiting for gossip to settle on live endpoints
> --
>
> Key: CASSANDRA-18845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18845
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Cameron Zemek
>Priority: Normal
> Attachments: 18845-3.11.patch, 18845-4.0.patch, 18845-4.1.patch,
> 18845-5.0.patch, image-2023-09-14-11-16-23-020.png
>
>
> This is a follow up to CASSANDRA-18543
> Although that ticket added ability to set cassandra.gossip_settle_min_wait_ms
> this is tedious and error prone. On a node just observed a 79 second gap
> between waiting for gossip and the first echo response to indicate a node is
> UP.
> The problem being that do not want to start Native Transport until gossip
> settles otherwise queries can fail consistency such as LOCAL_QUORUM as it
> thinks the replicas are still in DOWN state.
> Instead of having to set gossip_settle_min_wait_ms I am proposing that
> (outside single node cluster) wait for UP message from another node before
> considering gossip as settled. Eg.
> {code:java}
> if (currentSize == epSize && currentLive == liveSize && liveSize
> > 1)
> {
> logger.debug("Gossip looks settled.");
> numOkay++;
> } {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-18841) InstanceClassLoader leak in 5.0/trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-18841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764929#comment-17764929
]
Doug Rohrer commented on CASSANDRA-18841:
-
Yeah - not sure why the runsOnInstance is there in the patch - it's really just
wrapping the call in {{sync}} - I'll update it to make sure it's clean in the
morning.
Some more context as to why this fixed the problem we saw, there was some new
code added in the above-mentioned commit that eventually creates a new instance
of a {{o.netty.util.internal.InternalThreadLocalMap}} with the instance class
loader, but in the main thread. By calling {{sync}} we execute the code on the
instance's executor thread so when the instance is shut down the
{{InternalThreadLocalMap}} is removed appropriately.
> InstanceClassLoader leak in 5.0/trunk
> -
>
> Key: CASSANDRA-18841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: trunk_ThreadLocal_leak.patch
>
>
> Something in the 5.0/trunk branches has caused an in-jvm dtest
> InstanceClassLoader leak - it appears to have something to do with the Mutual
> TLS Authenticator (f078c02cb58bddd735490b07548f7352f0eb09aa) but nothing in
> that commit, so far, has stood out as causing issues.
> The culprit class appears to be
> {{io.netty.util.internal.InternalThreadLocalMap}}, which seems to no be
> removed when the threads stops for some reason.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-60) Sidecar API to expose cluster topology information
[ https://issues.apache.org/jira/browse/CASSANDRASC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764922#comment-17764922 ] Francisco Guerrero commented on CASSANDRASC-60: --- Latest CI for reference: https://app.circleci.com/pipelines/github/arjunashok/cassandra-sidecar/50 > Sidecar API to expose cluster topology information > -- > > Key: CASSANDRASC-60 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-60 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Arjun Ashok >Assignee: Arjun Ashok >Priority: Normal > Labels: pull-request-available > > This API will expose token ranges and the corresponding read and write > replicas. The write replica-set token ranges will include natural and pending > ranges, so clients can have a complete view of the cluster as nodes are > joining or leaving. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-60) Sidecar API to expose cluster topology information
[ https://issues.apache.org/jira/browse/CASSANDRASC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-60: - Status: Ready to Commit (was: Review In Progress) > Sidecar API to expose cluster topology information > -- > > Key: CASSANDRASC-60 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-60 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Arjun Ashok >Assignee: Arjun Ashok >Priority: Normal > Labels: pull-request-available > > This API will expose token ranges and the corresponding read and write > replicas. The write replica-set token ranges will include natural and pending > ranges, so clients can have a complete view of the cluster as nodes are > joining or leaving. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-60) Sidecar API to expose cluster topology information
[ https://issues.apache.org/jira/browse/CASSANDRASC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764917#comment-17764917 ] Francisco Guerrero commented on CASSANDRASC-60: --- +1, thanks for the patch and working through all the feedback > Sidecar API to expose cluster topology information > -- > > Key: CASSANDRASC-60 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-60 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Arjun Ashok >Assignee: Arjun Ashok >Priority: Normal > Labels: pull-request-available > > This API will expose token ranges and the corresponding read and write > replicas. The write replica-set token ranges will include natural and pending > ranges, so clients can have a complete view of the cluster as nodes are > joining or leaving. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-60) Sidecar API to expose cluster topology information
[ https://issues.apache.org/jira/browse/CASSANDRASC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-60: - Reviewers: Dinesh Joshi, Doug Rohrer, Francisco Guerrero, Yifan Cai (was: Doug Rohrer, Francisco Guerrero, Yifan Cai) > Sidecar API to expose cluster topology information > -- > > Key: CASSANDRASC-60 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-60 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Arjun Ashok >Assignee: Arjun Ashok >Priority: Normal > Labels: pull-request-available > > This API will expose token ranges and the corresponding read and write > replicas. The write replica-set token ranges will include natural and pending > ranges, so clients can have a complete view of the cluster as nodes are > joining or leaving. -- 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-18451) CEP-15: (C*) Improve the chaos generation for Burn Tests: slow/flakey connections and dropped messages
[ https://issues.apache.org/jira/browse/CASSANDRA-18451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18451: -- Source Control Link: https://github.com/apache/cassandra-accord/commit/fc3e1af12554e3befe6e44f4664278d91b4c0415 Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: (C*) Improve the chaos generation for Burn Tests: slow/flakey > connections and dropped messages > -- > > Key: CASSANDRA-18451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18451 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > Burn test should be enhanced to add the following: > 1) message dropping from one node to another (this is different than the > current partition set logic in accord.impl.basic.Cluster#partitionSet) > 2) for messages with callbacks, trigger failure case > 3) redundant message delivery > Related work: > * Simulator’s > org.apache.cassandra.simulator.systems.SimulatedAction#applyToMessage > - Figures out what delivery action to perform via > org.apache.cassandra.simulator.FutureActionScheduler#shouldDeliver > -- timeout if dropPartition[from] != dropPartition[to] // either to/from is > in drop partition, but not both > -- config asked to override and deliver > -- 50/50 chance to deliver, after that 50/50 to deliver w/ timeout, after > that cause a failure > - in C* failure is an enum with Timeout and Unknown > - knows the schedule time and the message expire time, and can promote a > DELIVER event to DELIVER_AND_TIMEOUT > - triggers the timeout -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-accord] branch trunk updated: CEP-15: (C*) Improve the chaos generation for Burn Tests: slow/flakey connections and dropped messages (#57)
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git
The following commit(s) were added to refs/heads/trunk by this push:
new fc3e1af1 CEP-15: (C*) Improve the chaos generation for Burn Tests:
slow/flakey connections and dropped messages (#57)
fc3e1af1 is described below
commit fc3e1af12554e3befe6e44f4664278d91b4c0415
Author: dcapwell
AuthorDate: Wed Sep 13 15:52:34 2023 -0700
CEP-15: (C*) Improve the chaos generation for Burn Tests: slow/flakey
connections and dropped messages (#57)
patch by David Capwell; reviewed by Benedict Elliott Smith for
CASSANDRA-18451
---
.../accord/impl/AbstractConfigurationService.java | 7 +
accord-core/src/main/java/accord/local/Node.java | 14 +-
.../src/main/java/accord/local/PreLoadContext.java | 25 +++
.../src/main/java/accord/messages/Accept.java | 2 +-
.../main/java/accord/messages/SafeCallback.java| 5 +
accord-core/src/test/java/accord/Utils.java| 2 +-
.../src/test/java/accord/burn/BurnTest.java| 66 ---
.../src/test/java/accord/burn/TopologyUpdates.java | 3 +
.../accord/burn/random/FrequentLargeRange.java | 134 +
.../src/test/java/accord/burn/random/IntRange.java | 5 +-
.../test/java/accord/burn/random/RandomInt.java| 32 ---
.../java/accord/burn/random/RandomRangeTest.java | 6 +-
.../java/accord/burn/random/RandomWalkRange.java | 13 +-
.../burn/random/SegmentedRandomRangeTest.java | 8 +-
.../coordinate/tracking/TrackerReconciler.java | 2 +-
.../src/test/java/accord/impl/MessageListener.java | 219 +
.../src/test/java/accord/impl/basic/Cluster.java | 57 +++---
.../accord/impl/basic/DelayedCommandStores.java| 2 +-
.../src/test/java/accord/impl/basic/NodeSink.java | 135 +++--
.../test/java/accord/impl/basic/PendingQueue.java | 1 +
.../accord/impl/basic/PropagatingPendingQueue.java | 14 +-
.../java/accord/impl/basic/RandomDelayQueue.java | 27 ++-
.../basic/SimulatedDelayedExecutorService.java | 29 +--
.../basic/SimulatedFault.java} | 11 +-
.../src/test/java/accord/impl/list/ListAgent.java | 2 +-
.../test/java/accord/impl/list/ListRequest.java| 141 +
.../src/test/java/accord/impl/list/ListResult.java | 57 ++
.../test/java/accord/impl/mock/MockCluster.java| 2 +-
.../java/accord/local/ImmutableCommandTest.java| 2 +-
accord-core/src/test/java/accord/utils/Gen.java| 68 ++-
.../src/test/java/accord/utils/GenTest.java| 76 +++
accord-core/src/test/java/accord/utils/Gens.java | 2 +-
.../src/main/java/accord/maelstrom/Cluster.java| 2 +-
.../src/main/java/accord/maelstrom/Main.java | 2 +-
.../src/main/groovy/accord.java-conventions.gradle | 4 +
35 files changed, 931 insertions(+), 246 deletions(-)
diff --git
a/accord-core/src/main/java/accord/impl/AbstractConfigurationService.java
b/accord-core/src/main/java/accord/impl/AbstractConfigurationService.java
index d8ebab8f..d33c1231 100644
--- a/accord-core/src/main/java/accord/impl/AbstractConfigurationService.java
+++ b/accord-core/src/main/java/accord/impl/AbstractConfigurationService.java
@@ -269,6 +269,13 @@ public abstract class
AbstractConfigurationService 0)
+{
+epochs.acknowledgeFuture(epochs.minEpoch()).addCallback(() ->
reportTopology(topology, startSync));
+return;
+}
if (lastAcked > 0 && topology.epoch() > lastAcked + 1)
{
epochs.acknowledgeFuture(lastAcked + 1).addCallback(() ->
reportTopology(topology, startSync));
diff --git a/accord-core/src/main/java/accord/local/Node.java
b/accord-core/src/main/java/accord/local/Node.java
index 1916f0bb..276f631e 100644
--- a/accord-core/src/main/java/accord/local/Node.java
+++ b/accord-core/src/main/java/accord/local/Node.java
@@ -169,10 +169,18 @@ public class Node implements
ConfigurationService.Listener, NodeTimeService
configService.registerListener(this);
}
-// TODO (cleanup, testing): remove, only used by Maelstrom
-public AsyncResult start()
+/**
+ * This starts the node for tests and makes sure that the provided
topology is acknowledged correctly. This method is not
+ * safe for production systems as it doesn't handle restarts and partially
acknowledged histories
+ * @return {@link EpochReady#metadata}
+ */
+@VisibleForTesting
+public AsyncResult unsafeStart()
{
-return onTopologyUpdateInternal(configService.currentTopology(),
false).metadata;
+EpochReady ready =
onTopologyUpdateInternal(configService.currentTopology(), false);
+ready.coordination.addCallback(() ->
this.topology.onEpochSyncComplete(id, topology.epoch()));
+configService.acknowledgeEpoch(ready, false);
+return
[jira] [Updated] (CASSANDRA-18451) CEP-15: (C*) Improve the chaos generation for Burn Tests: slow/flakey connections and dropped messages
[ https://issues.apache.org/jira/browse/CASSANDRA-18451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18451: -- Status: Ready to Commit (was: Review In Progress) +1 from [~benedict] in GH > CEP-15: (C*) Improve the chaos generation for Burn Tests: slow/flakey > connections and dropped messages > -- > > Key: CASSANDRA-18451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18451 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > Burn test should be enhanced to add the following: > 1) message dropping from one node to another (this is different than the > current partition set logic in accord.impl.basic.Cluster#partitionSet) > 2) for messages with callbacks, trigger failure case > 3) redundant message delivery > Related work: > * Simulator’s > org.apache.cassandra.simulator.systems.SimulatedAction#applyToMessage > - Figures out what delivery action to perform via > org.apache.cassandra.simulator.FutureActionScheduler#shouldDeliver > -- timeout if dropPartition[from] != dropPartition[to] // either to/from is > in drop partition, but not both > -- config asked to override and deliver > -- 50/50 chance to deliver, after that 50/50 to deliver w/ timeout, after > that cause a failure > - in C* failure is an enum with Timeout and Unknown > - knows the schedule time and the message expire time, and can promote a > DELIVER event to DELIVER_AND_TIMEOUT > - triggers the timeout -- 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-18451) CEP-15: (C*) Improve the chaos generation for Burn Tests: slow/flakey connections and dropped messages
[ https://issues.apache.org/jira/browse/CASSANDRA-18451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18451: -- Reviewers: Benedict Elliott Smith Status: Review In Progress (was: Patch Available) > CEP-15: (C*) Improve the chaos generation for Burn Tests: slow/flakey > connections and dropped messages > -- > > Key: CASSANDRA-18451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18451 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > Burn test should be enhanced to add the following: > 1) message dropping from one node to another (this is different than the > current partition set logic in accord.impl.basic.Cluster#partitionSet) > 2) for messages with callbacks, trigger failure case > 3) redundant message delivery > Related work: > * Simulator’s > org.apache.cassandra.simulator.systems.SimulatedAction#applyToMessage > - Figures out what delivery action to perform via > org.apache.cassandra.simulator.FutureActionScheduler#shouldDeliver > -- timeout if dropPartition[from] != dropPartition[to] // either to/from is > in drop partition, but not both > -- config asked to override and deliver > -- 50/50 chance to deliver, after that 50/50 to deliver w/ timeout, after > that cause a failure > - in C* failure is an enum with Timeout and Unknown > - knows the schedule time and the message expire time, and can promote a > DELIVER event to DELIVER_AND_TIMEOUT > - triggers the timeout -- 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-18841) InstanceClassLoader leak in 5.0/trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-18841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-18841:
---
Reviewers: Francisco Guerrero, Francisco Guerrero
Francisco Guerrero, Francisco Guerrero (was: Francisco Guerrero)
Status: Review In Progress (was: Patch Available)
> InstanceClassLoader leak in 5.0/trunk
> -
>
> Key: CASSANDRA-18841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: trunk_ThreadLocal_leak.patch
>
>
> Something in the 5.0/trunk branches has caused an in-jvm dtest
> InstanceClassLoader leak - it appears to have something to do with the Mutual
> TLS Authenticator (f078c02cb58bddd735490b07548f7352f0eb09aa) but nothing in
> that commit, so far, has stood out as causing issues.
> The culprit class appears to be
> {{io.netty.util.internal.InternalThreadLocalMap}}, which seems to no be
> removed when the threads stops for some reason.
--
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-18844) Cassandra 5 Debian package only runs on OpenJDK
[
https://issues.apache.org/jira/browse/CASSANDRA-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764895#comment-17764895
]
Jackson Fleming edited comment on CASSANDRA-18844 at 9/13/23 10:22 PM:
---
Actually even worse, if you don't have a JRE installed on book worm, Debian
will provide one currently that is not compatible by default..
1 - Start a bookworm debian container
{code:java}
docker run -it -u root debian:bookworm {code}
2 - Install cassandra apt repos and cassandra
{code:java}
apt-get update
apt-get install curl gnupg2
echo "deb https://debian.cassandra.apache.org 41x main" | tee -a
/etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
apt-get update
apt-get install cassandra {code}
3 - Run Cassandra, be sad because it doesn't work
{code:java}
root@868331497f27:/# cassandra -R
root@868331497f27:/# OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking
was deprecated in version 15.0 and will likely be removed in a future release.
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit. {code}
was (Author: JIRAUSER294685):
Actually even worse, if you don't have a JRE installed on book worm, Debian
will provide one currently that is not compatible by default..
1 - Start a bookworm debian container
{code:java}
docker run -it -u root debian:bookworm {code}
2 - Install cassandra apt repos and cassandra
apt-get update
apt-get install curl gnupg2
echo "deb https://debian.cassandra.apache.org 41x main" | tee -a
/etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
apt-get update
apt-get install cassandra
3 - Run Cassandra, be sad because it doesn't work
{code:java}
root@868331497f27:/# cassandra -R
root@868331497f27:/# OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking
was deprecated in version 15.0 and will likely be removed in a future release.
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit. {code}
> Cassandra 5 Debian package only runs on OpenJDK
> ---
>
> Key: CASSANDRA-18844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18844
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-2023-09-13-18-53-38-884.png,
> image-2023-09-13-21-03-57-010.png, image-2023-09-13-21-04-42-525.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A recent change to the Cassandra 5 branch has caused the Cassandra deb
> package to no longer install on systems that don't run OpenJDK
>
> The following line is too restrictive
> [https://github.com/apache/cassandra/blob/trunk/debian/control#L14]
> It should be modified to use the java11-runtime and java17-runtime virtual
> packages.
--
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-18844) Cassandra 5 Debian package only runs on OpenJDK
[
https://issues.apache.org/jira/browse/CASSANDRA-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764895#comment-17764895
]
Jackson Fleming commented on CASSANDRA-18844:
-
Actually even worse, if you don't have a JRE installed on book worm, Debian
will provide one currently that is not compatible by default..
1 - Start a bookworm debian container
{code:java}
docker run -it -u root debian:bookworm {code}
2 - Install cassandra apt repos and cassandra
apt-get update
apt-get install curl gnupg2
echo "deb https://debian.cassandra.apache.org 41x main" | tee -a
/etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
apt-get update
apt-get install cassandra
3 - Run Cassandra, be sad because it doesn't work
{code:java}
root@868331497f27:/# cassandra -R
root@868331497f27:/# OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking
was deprecated in version 15.0 and will likely be removed in a future release.
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit. {code}
> Cassandra 5 Debian package only runs on OpenJDK
> ---
>
> Key: CASSANDRA-18844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18844
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-2023-09-13-18-53-38-884.png,
> image-2023-09-13-21-03-57-010.png, image-2023-09-13-21-04-42-525.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A recent change to the Cassandra 5 branch has caused the Cassandra deb
> package to no longer install on systems that don't run OpenJDK
>
> The following line is too restrictive
> [https://github.com/apache/cassandra/blob/trunk/debian/control#L14]
> It should be modified to use the java11-runtime and java17-runtime virtual
> packages.
--
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-18844) Cassandra 5 Debian package only runs on OpenJDK
[
https://issues.apache.org/jira/browse/CASSANDRA-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764892#comment-17764892
]
Jackson Fleming edited comment on CASSANDRA-18844 at 9/13/23 10:18 PM:
---
I'd point out Cassandra is currently in this situation with the latest release
in the 4.1.x series, you can reproduce this below:
1 - Start a bookworm debian container
{code:java}
docker run -it -u root debian:bookworm {code}
2 - Inside this container Install the default-jre (and other tools we'll need
to setup cassandra)
{code:java}
apt-get update
apt-get install curl gnupg2 default-jre{code}
You'll get JDK 17 on bookworm
{code:java}
root@b7e68b93dfad:/# java -version
openjdk version "17.0.8" 2023-07-18
OpenJDK Runtime Environment (build 17.0.8+7-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.8+7-Debian-1deb12u1, mixed mode, sharing)
{code}
3 - Setup the cassandra debian apt repos (per
[https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html)]
Install cassandra
{code:java}
echo "deb https://debian.cassandra.apache.org 41x main" | tee -a
/etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
apt-get update
apt-get install cassandra{code}
The installation will work, cause openjdk-17-jre satisfies java11-runtime
{code:java}
root@b7e68b93dfad:/etc/cassandra# apt list --installed | grep cassandra
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
cassandra/unknown,now 4.1.3 all [installed] {code}
4 - Try to run Cassandra 4.1.3, be sad
{code:java}
root@b7e68b93dfad:/# cassandra -R
root@b7e68b93dfad:/# OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking
was deprecated in version 15.0 and will likely be removed in a future release.
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit {code}
So that raises the question if it's not a problem currently, then will it be a
problem for users on Cassandra 5?
If you were to follow the above steps on Cassandra 5 with the suggested
changes, you'd get JRE 17 on bookworm, and Cassandra should run.
Even if I go and change off CMS, Cassandra will fail to start
{code:java}
Exception (java.lang.AssertionError) encountered during startup:
java.lang.reflect.InaccessibleObjectException: Unable to make field private int
java.io.FileDescriptor.fd accessible: module java.base does not "opens java.io"
to unnamed module @34129c78
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
... 4 more
ERROR [main] 2023-09-13 22:14:24,220 CassandraDaemon.java:897 - Exception
encountered during startup
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
[jira] [Comment Edited] (CASSANDRA-18844) Cassandra 5 Debian package only runs on OpenJDK
[
https://issues.apache.org/jira/browse/CASSANDRA-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764892#comment-17764892
]
Jackson Fleming edited comment on CASSANDRA-18844 at 9/13/23 10:16 PM:
---
I'd point out Cassandra is currently in this situation with the latest release
in the 4.1.x series, you can reproduce this below:
1 - Start a bookworm debian container
{code:java}
docker run -it -u root debian:bookworm {code}
2 - Inside this container Install the default-jre (and other tools we'll need
to setup cassandra)
{code:java}
apt-get update
apt-get install curl gnupg2 default-jre{code}
You'll get JDK 17 on bookworm
{code:java}
root@b7e68b93dfad:/# java -version
openjdk version "17.0.8" 2023-07-18
OpenJDK Runtime Environment (build 17.0.8+7-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.8+7-Debian-1deb12u1, mixed mode, sharing)
{code}
3 - Setup the cassandra debian apt repos (per
[https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html)]
Install cassandra
{code:java}
echo "deb https://debian.cassandra.apache.org 41x main" | tee -a
/etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
apt-get update
apt-get install cassandra{code}
The installation will work, cause openjdk-17-jre satisfies java11-runtime
4 - Try to run Cassandra 4.1.3, be sad
{code:java}
root@b7e68b93dfad:/# cassandra -R
root@b7e68b93dfad:/# OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking
was deprecated in version 15.0 and will likely be removed in a future release.
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit {code}
So that raises the question if it's not a problem currently, then will it be a
problem for users on Cassandra 5?
If you were to follow the above steps on Cassandra 5 with the suggested
changes, you'd get JRE 17 on bookworm, and Cassandra should run.
Even if I go and change off CMS, Cassandra will fail to start
{code:java}
Exception (java.lang.AssertionError) encountered during startup:
java.lang.reflect.InaccessibleObjectException: Unable to make field private int
java.io.FileDescriptor.fd accessible: module java.base does not "opens java.io"
to unnamed module @34129c78
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
... 4 more
ERROR [main] 2023-09-13 22:14:24,220 CassandraDaemon.java:897 - Exception
encountered during startup
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at
[jira] [Comment Edited] (CASSANDRA-18844) Cassandra 5 Debian package only runs on OpenJDK
[
https://issues.apache.org/jira/browse/CASSANDRA-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764892#comment-17764892
]
Jackson Fleming edited comment on CASSANDRA-18844 at 9/13/23 10:16 PM:
---
I'd point out Cassandra is currently in this situation with the latest release
in the 4.1.x series, you can reproduce this below:
1 - Start a bookworm debian container
{code:java}
docker run -it -u root debian:bookworm {code}
2 - Inside this container Install the default-jre (and other tools we'll need
to setup cassandra)
{code:java}
apt-get update
apt-get install curl gnupg2 default-jre{code}
You'll get JDK 17 on bookworm
{code:java}
root@b7e68b93dfad:/# java -version
openjdk version "17.0.8" 2023-07-18
OpenJDK Runtime Environment (build 17.0.8+7-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.8+7-Debian-1deb12u1, mixed mode, sharing)
{code}
3 - Setup the cassandra debian apt repos (per
[https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html)]
Install cassandra
{code:java}
echo "deb https://debian.cassandra.apache.org 41x main" | tee -a
/etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
apt-get update
apt-get install cassandra{code}
The installation will work, cause openjdk-17-jre satisfies java11-runtime
4 - Try to run Cassandra 4.1.3, be sad
{code:java}
root@b7e68b93dfad:/# cassandra -R
root@b7e68b93dfad:/# OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking
was deprecated in version 15.0 and will likely be removed in a future release.
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit {code}
So that raises the question if it's not a problem currently, then will it be a
problem for users on Cassandra 5?
If you were to follow the above steps on Cassandra 5 with the suggested
changes, you'd get JRE 17 on bookworm, and Cassandra should run.
Even if I go and change off CMS, Cassandra will fail to start
{code:java}
Exception (java.lang.AssertionError) encountered during startup:
java.lang.reflect.InaccessibleObjectException: Unable to make field private int
java.io.FileDescriptor.fd accessible: module java.base does not "opens java.io"
to unnamed module @34129c78
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
... 4 more
ERROR [main] 2023-09-13 22:14:24,220 CassandraDaemon.java:897 - Exception
encountered during startup
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at
[jira] [Commented] (CASSANDRA-18841) InstanceClassLoader leak in 5.0/trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-18841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764893#comment-17764893
]
Francisco Guerrero commented on CASSANDRA-18841:
Taking a look at the patch, and it doesn't seem like {{runsOnInstance}} was
called previously:
https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/impl/Instance.java#L813
I wonder if that's something you've added interim as you were testing the fix?
> InstanceClassLoader leak in 5.0/trunk
> -
>
> Key: CASSANDRA-18841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: trunk_ThreadLocal_leak.patch
>
>
> Something in the 5.0/trunk branches has caused an in-jvm dtest
> InstanceClassLoader leak - it appears to have something to do with the Mutual
> TLS Authenticator (f078c02cb58bddd735490b07548f7352f0eb09aa) but nothing in
> that commit, so far, has stood out as causing issues.
> The culprit class appears to be
> {{io.netty.util.internal.InternalThreadLocalMap}}, which seems to no be
> removed when the threads stops for some reason.
--
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-18844) Cassandra 5 Debian package only runs on OpenJDK
[
https://issues.apache.org/jira/browse/CASSANDRA-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764892#comment-17764892
]
Jackson Fleming edited comment on CASSANDRA-18844 at 9/13/23 10:15 PM:
---
I'd point out Cassandra is current in this situation with the 4.1.x series, you
can reproduce this below:
1 - Start a bookworm debian container
{code:java}
docker run -it -u root debian:bookworm {code}
2 - Inside this container Install the default-jre (and other tools we'll need
to setup cassandra)
{code:java}
apt-get update
apt-get install curl gnupg2 default-jre{code}
You'll get JDK 17 on bookworm
{code:java}
root@b7e68b93dfad:/# java -version
openjdk version "17.0.8" 2023-07-18
OpenJDK Runtime Environment (build 17.0.8+7-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.8+7-Debian-1deb12u1, mixed mode, sharing)
{code}
3 - Setup the cassandra debian apt repos (per
[https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html)]
Install cassandra
{code:java}
echo "deb https://debian.cassandra.apache.org 41x main" | tee -a
/etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
apt-get update
apt-get install cassandra{code}
The installation will work, cause openjdk-17-jre satisfies java11-runtime
4 - Try to run Cassandra 4.1.3, be sad
{code:java}
root@b7e68b93dfad:/# cassandra -R
root@b7e68b93dfad:/# OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking
was deprecated in version 15.0 and will likely be removed in a future release.
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit {code}
So that raises the question if it's not a problem currently, then will it be a
problem for users on Cassandra 5?
If you were to follow the above steps on Cassandra 5 with the suggested
changes, you'd get JRE 17 on bookworm, and Cassandra should run.
Even if I go and change off CMS, Cassandra will fail to start
{code:java}
Exception (java.lang.AssertionError) encountered during startup:
java.lang.reflect.InaccessibleObjectException: Unable to make field private int
java.io.FileDescriptor.fd accessible: module java.base does not "opens java.io"
to unnamed module @34129c78
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
... 4 more
ERROR [main] 2023-09-13 22:14:24,220 CassandraDaemon.java:897 - Exception
encountered during startup
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at
[jira] [Comment Edited] (CASSANDRA-18844) Cassandra 5 Debian package only runs on OpenJDK
[
https://issues.apache.org/jira/browse/CASSANDRA-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764892#comment-17764892
]
Jackson Fleming edited comment on CASSANDRA-18844 at 9/13/23 10:15 PM:
---
I'd point out Cassandra is currently in this situation with the latest release
in the 4.1.x series, you can reproduce this below:
1 - Start a bookworm debian container
{code:java}
docker run -it -u root debian:bookworm {code}
2 - Inside this container Install the default-jre (and other tools we'll need
to setup cassandra)
{code:java}
apt-get update
apt-get install curl gnupg2 default-jre{code}
You'll get JDK 17 on bookworm
{code:java}
root@b7e68b93dfad:/# java -version
openjdk version "17.0.8" 2023-07-18
OpenJDK Runtime Environment (build 17.0.8+7-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.8+7-Debian-1deb12u1, mixed mode, sharing)
{code}
3 - Setup the cassandra debian apt repos (per
[https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html)]
Install cassandra
{code:java}
echo "deb https://debian.cassandra.apache.org 41x main" | tee -a
/etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
apt-get update
apt-get install cassandra{code}
The installation will work, cause openjdk-17-jre satisfies java11-runtime
4 - Try to run Cassandra 4.1.3, be sad
{code:java}
root@b7e68b93dfad:/# cassandra -R
root@b7e68b93dfad:/# OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking
was deprecated in version 15.0 and will likely be removed in a future release.
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit {code}
So that raises the question if it's not a problem currently, then will it be a
problem for users on Cassandra 5?
If you were to follow the above steps on Cassandra 5 with the suggested
changes, you'd get JRE 17 on bookworm, and Cassandra should run.
Even if I go and change off CMS, Cassandra will fail to start
{code:java}
Exception (java.lang.AssertionError) encountered during startup:
java.lang.reflect.InaccessibleObjectException: Unable to make field private int
java.io.FileDescriptor.fd accessible: module java.base does not "opens java.io"
to unnamed module @34129c78
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
... 4 more
ERROR [main] 2023-09-13 22:14:24,220 CassandraDaemon.java:897 - Exception
encountered during startup
java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException: Unable
to make field private int java.io.FileDescriptor.fd accessible: module
java.base does not "opens java.io" to unnamed module @34129c78
at
org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:83)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:252)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:751)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private int java.io.FileDescriptor.fd accessible: module java.base does not
"opens java.io" to unnamed module @34129c78
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at
[jira] [Commented] (CASSANDRA-18844) Cassandra 5 Debian package only runs on OpenJDK
[
https://issues.apache.org/jira/browse/CASSANDRA-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764892#comment-17764892
]
Jackson Fleming commented on CASSANDRA-18844:
-
I'd point out Cassandra is current in this situation with the 4.1.x series, you
can reproduce this below:
1 - Start a bookworm debian container
{code:java}
docker run -it -u root debian:bookworm {code}
2 - Inside this container Install the default-jre (and other tools we'll need
to setup cassandra)
{code:java}
apt-get update
apt-get install curl gnupg2 default-jre{code}
You'll get JDK 17 on bookworm
{code:java}
root@b7e68b93dfad:/# java -version
openjdk version "17.0.8" 2023-07-18
OpenJDK Runtime Environment (build 17.0.8+7-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.8+7-Debian-1deb12u1, mixed mode, sharing)
{code}
3 - Setup the cassandra debian apt repos (per
[https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html)]
Install cassandra
{code:java}
echo "deb https://debian.cassandra.apache.org 41x main" | tee -a
/etc/apt/sources.list.d/cassandra.sources.list
curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
apt-get update
apt-get install cassandra{code}
The installation will work, cause openjdk-17-jre satisfies java11-runtime
4 - Try to run Cassandra 4.1.3, be sad
{code:java}
root@b7e68b93dfad:/# cassandra -R
root@b7e68b93dfad:/# OpenJDK 64-Bit Server VM warning: Option UseBiasedLocking
was deprecated in version 15.0 and will likely be removed in a future release.
Unrecognized VM option 'UseConcMarkSweepGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit {code}
So that raises the question if it's not a problem currently, then will it be a
problem for users on Cassandra 5?
If you were to follow the above steps on Cassandra 5 with the suggested
changes, you'd get JRE 17 on bookworm, and Cassandra should run.
> Cassandra 5 Debian package only runs on OpenJDK
> ---
>
> Key: CASSANDRA-18844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18844
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
> Fix For: 5.x
>
> Attachments: image-2023-09-13-18-53-38-884.png,
> image-2023-09-13-21-03-57-010.png, image-2023-09-13-21-04-42-525.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A recent change to the Cassandra 5 branch has caused the Cassandra deb
> package to no longer install on systems that don't run OpenJDK
>
> The following line is too restrictive
> [https://github.com/apache/cassandra/blob/trunk/debian/control#L14]
> It should be modified to use the java11-runtime and java17-runtime virtual
> packages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[GitHub] [cassandra-analytics] 5 commented on a diff in pull request #15: [CASSANDRA-18810] Cassandra Analytics Start-Up Validation
5 commented on code in PR #15:
URL:
https://github.com/apache/cassandra-analytics/pull/15#discussion_r1325124176
##
cassandra-analytics-core/src/main/java/org/apache/cassandra/spark/validation/TruststoreValidation.java:
##
@@ -0,0 +1,22 @@
+package org.apache.cassandra.spark.validation;
+
+import org.apache.cassandra.secrets.SecretsProvider;
+
+public class TruststoreValidation implements StartupValidation
+{
+private final SecretsProvider secrets;
+
+public TruststoreValidation(SecretsProvider secrets)
+{
+this.secrets = secrets;
+}
+
+@Override
+public void validate()
+{
+if (!secrets.hasTrustStoreSecrets())
Review Comment:
Added everything we've discussed in a separate commit, could you take
another look?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18850) Building a Cassandra website fails when running on arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-18850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-18850:
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Building a Cassandra website fails when running on arm64
>
>
> Key: CASSANDRA-18850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18850
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Labels: pull-request-available
>
> It seems to me that building a Cassandra website is not supported when
> running on arm64 (tested on Mac M1). Running the build command throws the
> following exceptions below.
> Docker Version 4.23.0 (120376), the experimental feature "use Rosetta for
> x86/amd64 emulation on Apple Silicon" is enabled.
> {code:java}
> m@m1 cassandra-website % ./run.sh website build
> Server Docker Engine version: 20.10.21
> Executing docker command:
> docker build -f ./site-content/Dockerfile -t apache/cassandra-website:latest
> ./site-content/
> [+] Building 7.2s (12/23)
>
>
>
> => [internal] load build definition from Dockerfile
>
>
> 0.0s
> => => transferring dockerfile: 5.03kB
>
>
> 0.0s
> => [internal] load .dockerignore
>
>
> 0.0s
> => => transferring context: 2B
>
>
> 0.0s
> => [internal] load metadata for docker.io/library/ubuntu:18.04
>
>
> 0.6s
> => [ 1/19] FROM
> docker.io/library/ubuntu:18.04@sha256:152dc042452c496007f07ca9127571cb9c29697f42acbfad72324b2bb2e43c98
>
>
> 0.0s
> => [internal] load build context
>
>
> 0.0s
> => => transferring context: 42B
>
>
> 0.0s
> => CACHED [ 2/19] RUN echo "Building with arguments:" && echo " -
> BUILD_USER_ARG=build" && echo " - UID_ARG=1000" && echo " -
> GID_ARG=1000" && echo " - NODE_VERSION_ARG=v12.16.2" && echo " -
> ENTR_VERSION_ARG=4.6"
> 0.0s
> => CACHED [ 3/19] RUN apt update && apt install -y openjdk-8-jdk
> openjdk-11-jdk python3 python3-pip ant
> ant-optional make git gpg wget sudo
> 0.0s
> => CACHED [ 4/19] RUN apt-get install -y python-markupsafe
[jira] [Updated] (CASSANDRA-18850) Building a Cassandra website fails when running on arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-18850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CASSANDRA-18850:
---
Labels: pull-request-available (was: )
> Building a Cassandra website fails when running on arm64
>
>
> Key: CASSANDRA-18850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18850
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Labels: pull-request-available
>
> It seems to me that building a Cassandra website is not supported when
> running on arm64 (tested on Mac M1). Running the build command throws the
> following exceptions below.
> Docker Version 4.23.0 (120376), the experimental feature "use Rosetta for
> x86/amd64 emulation on Apple Silicon" is enabled.
> {code:java}
> m@m1 cassandra-website % ./run.sh website build
> Server Docker Engine version: 20.10.21
> Executing docker command:
> docker build -f ./site-content/Dockerfile -t apache/cassandra-website:latest
> ./site-content/
> [+] Building 7.2s (12/23)
>
>
>
> => [internal] load build definition from Dockerfile
>
>
> 0.0s
> => => transferring dockerfile: 5.03kB
>
>
> 0.0s
> => [internal] load .dockerignore
>
>
> 0.0s
> => => transferring context: 2B
>
>
> 0.0s
> => [internal] load metadata for docker.io/library/ubuntu:18.04
>
>
> 0.6s
> => [ 1/19] FROM
> docker.io/library/ubuntu:18.04@sha256:152dc042452c496007f07ca9127571cb9c29697f42acbfad72324b2bb2e43c98
>
>
> 0.0s
> => [internal] load build context
>
>
> 0.0s
> => => transferring context: 42B
>
>
> 0.0s
> => CACHED [ 2/19] RUN echo "Building with arguments:" && echo " -
> BUILD_USER_ARG=build" && echo " - UID_ARG=1000" && echo " -
> GID_ARG=1000" && echo " - NODE_VERSION_ARG=v12.16.2" && echo " -
> ENTR_VERSION_ARG=4.6"
> 0.0s
> => CACHED [ 3/19] RUN apt update && apt install -y openjdk-8-jdk
> openjdk-11-jdk python3 python3-pip ant
> ant-optional make git gpg wget sudo
> 0.0s
> => CACHED [ 4/19] RUN apt-get install -y python-markupsafe
>
[jira] [Commented] (CASSANDRA-18841) InstanceClassLoader leak in 5.0/trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-18841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764886#comment-17764886
]
Doug Rohrer commented on CASSANDRA-18841:
-
The patch should apply cleanly (or be easy enough to apply) to all branches - I
can submit PRs if necessary tomorrow.
> InstanceClassLoader leak in 5.0/trunk
> -
>
> Key: CASSANDRA-18841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: trunk_ThreadLocal_leak.patch
>
>
> Something in the 5.0/trunk branches has caused an in-jvm dtest
> InstanceClassLoader leak - it appears to have something to do with the Mutual
> TLS Authenticator (f078c02cb58bddd735490b07548f7352f0eb09aa) but nothing in
> that commit, so far, has stood out as causing issues.
> The culprit class appears to be
> {{io.netty.util.internal.InternalThreadLocalMap}}, which seems to no be
> removed when the threads stops for some reason.
--
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-18841) InstanceClassLoader leak in 5.0/trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-18841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764884#comment-17764884
]
Doug Rohrer edited comment on CASSANDRA-18841 at 9/13/23 9:20 PM:
--
Note I believe this patch should _also_ be applied to 4.1 as the same bug is
there, it just hasn't been hit because the code that is called in
{{postStartup}} today doesn't tickle the particular issue (it requires hitting
something that uses a {{ThreadLocal}}.
was (Author: drohrer):
Note I believe this patch should _also_ be applied to 4.1 as the same bug is
there, it just hasn't been hit because the code that is called in
{{postStartup}} today doesn't tickle the particular issue (it requires hitting
something that uses {{ThreadLocal}}s.
> InstanceClassLoader leak in 5.0/trunk
> -
>
> Key: CASSANDRA-18841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: trunk_ThreadLocal_leak.patch
>
>
> Something in the 5.0/trunk branches has caused an in-jvm dtest
> InstanceClassLoader leak - it appears to have something to do with the Mutual
> TLS Authenticator (f078c02cb58bddd735490b07548f7352f0eb09aa) but nothing in
> that commit, so far, has stood out as causing issues.
> The culprit class appears to be
> {{io.netty.util.internal.InternalThreadLocalMap}}, which seems to no be
> removed when the threads stops for some reason.
--
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-18841) InstanceClassLoader leak in 5.0/trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-18841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Rohrer updated CASSANDRA-18841:
Test and Documentation Plan:
Run {{ResourceLeakTest#looperTest}} after increasing the number of loops to 100
- without the patch, this will fail on 5.0 and trunk long before you get to 100
iterations.
With the patch, it should reach 100.
Status: Patch Available (was: Open)
Note I believe this patch should _also_ be applied to 4.1 as the same bug is
there, it just hasn't been hit because the code that is called in
{{postStartup}} today doesn't tickle the particular issue (it requires hitting
something that uses {{ThreadLocal}}s.
> InstanceClassLoader leak in 5.0/trunk
> -
>
> Key: CASSANDRA-18841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> Something in the 5.0/trunk branches has caused an in-jvm dtest
> InstanceClassLoader leak - it appears to have something to do with the Mutual
> TLS Authenticator (f078c02cb58bddd735490b07548f7352f0eb09aa) but nothing in
> that commit, so far, has stood out as causing issues.
> The culprit class appears to be
> {{io.netty.util.internal.InternalThreadLocalMap}}, which seems to no be
> removed when the threads stops for some reason.
--
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-18841) InstanceClassLoader leak in 5.0/trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-18841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Rohrer updated CASSANDRA-18841:
Attachment: trunk_ThreadLocal_leak.patch
> InstanceClassLoader leak in 5.0/trunk
> -
>
> Key: CASSANDRA-18841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Doug Rohrer
>Assignee: Doug Rohrer
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: trunk_ThreadLocal_leak.patch
>
>
> Something in the 5.0/trunk branches has caused an in-jvm dtest
> InstanceClassLoader leak - it appears to have something to do with the Mutual
> TLS Authenticator (f078c02cb58bddd735490b07548f7352f0eb09aa) but nothing in
> that commit, so far, has stood out as causing issues.
> The culprit class appears to be
> {{io.netty.util.internal.InternalThreadLocalMap}}, which seems to no be
> removed when the threads stops for some reason.
--
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-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18849:
Description:
Since recently, it fails regularly on 4.1, 5.0, and trunk:
{code:java}
Error Message
failed on teardown with "Failed: Unexpected error found in node logs (see
stdout for full details). Errors: [[node2] 'ERROR
[Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket
closed before session completion, peer 127.0.0.1:7000 is probably
down.\njava.nio.channels.ClosedChannelException: null\n\tat
org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.base/java.lang.Thread.run(Thread.java:829)']"
Stacktrace
Unexpected error found in node logs (see stdout for full details). Errors:
[[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
12:41:02,461 StreamSession.java:700 - [Stream
#cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session completion,
peer 127.0.0.1:7000 is probably
down.\njava.nio.channels.ClosedChannelException: null\n\tat
org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.base/java.lang.Thread.run(Thread.java:829)']
{code}
was:
Since recently, it fails regularly on 4.1, 5.0, and trunk:
h3.
{code:java}
Error Message
failed on teardown with "Failed: Unexpected error found in node logs (see
stdout for full details). Errors: [[node2] 'ERROR
[Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket
closed before session completion, peer 127.0.0.1:7000 is probably
down.\njava.nio.channels.ClosedChannelException: null\n\tat
org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.base/java.lang.Thread.run(Thread.java:829)']"
Stacktrace
Unexpected error found in node logs (see stdout for full details). Errors:
[[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
12:41:02,461 StreamSession.java:700 - [Stream
#cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session completion,
peer 127.0.0.1:7000 is probably
down.\njava.nio.channels.ClosedChannelException: null\n\tat
org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.base/java.lang.Thread.run(Thread.java:829)']
{code}
> Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
> --
>
> Key: CASSANDRA-18849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Since recently, it fails regularly on 4.1, 5.0, and trunk:
> {code:java}
> Error Message
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
>
[jira] [Commented] (CASSANDRA-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764883#comment-17764883
]
Ekaterina Dimitrova commented on CASSANDRA-18849:
-
Yeah, I just left a message with the same observation on CASSANDRA-18225
> Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
> --
>
> Key: CASSANDRA-18849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Since recently, it fails regularly on 4.1, 5.0, and trunk:
> h3.
> {code:java}
> Error Message
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
> StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']"
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
> 12:41:02,461 StreamSession.java:700 - [Stream
> #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session
> completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']
> {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] [Comment Edited] (CASSANDRA-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764883#comment-17764883
]
Ekaterina Dimitrova edited comment on CASSANDRA-18849 at 9/13/23 9:11 PM:
--
Yeah, I just left a message with the same observation on CASSANDRA-18825
was (Author: e.dimitrova):
Yeah, I just left a message with the same observation on CASSANDRA-18225
> Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
> --
>
> Key: CASSANDRA-18849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Since recently, it fails regularly on 4.1, 5.0, and trunk:
> h3.
> {code:java}
> Error Message
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
> StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']"
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
> 12:41:02,461 StreamSession.java:700 - [Stream
> #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session
> completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']
> {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-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764882#comment-17764882
]
Brandon Williams commented on CASSANDRA-18849:
--
No, it didn't appear there, that's why I made CASSANDRA-18825... but it looks
like it does, sometimes, which I guess further complicates the mystery, heh.
> Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
> --
>
> Key: CASSANDRA-18849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Since recently, it fails regularly on 4.1, 5.0, and trunk:
> h3.
> {code:java}
> Error Message
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
> StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']"
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
> 12:41:02,461 StreamSession.java:700 - [Stream
> #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session
> completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']
> {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] [Created] (CASSANDRA-18850) Building a Cassandra website fails when running on arm64
Maxim Muzafarov created CASSANDRA-18850:
---
Summary: Building a Cassandra website fails when running on arm64
Key: CASSANDRA-18850
URL: https://issues.apache.org/jira/browse/CASSANDRA-18850
Project: Cassandra
Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
It seems to me that building a Cassandra website is not supported when running
on arm64 (tested on Mac M1). Running the build command throws the following
exceptions below.
Docker Version 4.23.0 (120376), the experimental feature "use Rosetta for
x86/amd64 emulation on Apple Silicon" is enabled.
{code:java}
m@m1 cassandra-website % ./run.sh website build
Server Docker Engine version: 20.10.21
Executing docker command:
docker build -f ./site-content/Dockerfile -t apache/cassandra-website:latest
./site-content/
[+] Building 7.2s (12/23)
=> [internal] load build definition from Dockerfile
0.0s
=> => transferring dockerfile: 5.03kB
0.0s
=> [internal] load .dockerignore
0.0s
=> => transferring context: 2B
0.0s
=> [internal] load metadata for docker.io/library/ubuntu:18.04
0.6s
=> [ 1/19] FROM
docker.io/library/ubuntu:18.04@sha256:152dc042452c496007f07ca9127571cb9c29697f42acbfad72324b2bb2e43c98
0.0s
=> [internal] load build context
0.0s
=> => transferring context: 42B
0.0s
=> CACHED [ 2/19] RUN echo "Building with arguments:" && echo " -
BUILD_USER_ARG=build" && echo " - UID_ARG=1000" && echo " -
GID_ARG=1000" && echo " - NODE_VERSION_ARG=v12.16.2" && echo " -
ENTR_VERSION_ARG=4.6"
0.0s
=> CACHED [ 3/19] RUN apt update && apt install -y openjdk-8-jdk
openjdk-11-jdk python3 python3-pip ant
ant-optional make git gpg wget sudo
0.0s
=> CACHED [ 4/19] RUN apt-get install -y python-markupsafe
0.0s
=> [ 5/19] RUN apt-get install -y python-jinja2
[jira] [Updated] (CASSANDRA-18850) Building a Cassandra website fails when running on arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-18850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-18850:
Component/s: Documentation/Website
> Building a Cassandra website fails when running on arm64
>
>
> Key: CASSANDRA-18850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18850
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
>
> It seems to me that building a Cassandra website is not supported when
> running on arm64 (tested on Mac M1). Running the build command throws the
> following exceptions below.
> Docker Version 4.23.0 (120376), the experimental feature "use Rosetta for
> x86/amd64 emulation on Apple Silicon" is enabled.
> {code:java}
> m@m1 cassandra-website % ./run.sh website build
> Server Docker Engine version: 20.10.21
> Executing docker command:
> docker build -f ./site-content/Dockerfile -t apache/cassandra-website:latest
> ./site-content/
> [+] Building 7.2s (12/23)
>
>
>
> => [internal] load build definition from Dockerfile
>
>
> 0.0s
> => => transferring dockerfile: 5.03kB
>
>
> 0.0s
> => [internal] load .dockerignore
>
>
> 0.0s
> => => transferring context: 2B
>
>
> 0.0s
> => [internal] load metadata for docker.io/library/ubuntu:18.04
>
>
> 0.6s
> => [ 1/19] FROM
> docker.io/library/ubuntu:18.04@sha256:152dc042452c496007f07ca9127571cb9c29697f42acbfad72324b2bb2e43c98
>
>
> 0.0s
> => [internal] load build context
>
>
> 0.0s
> => => transferring context: 42B
>
>
> 0.0s
> => CACHED [ 2/19] RUN echo "Building with arguments:" && echo " -
> BUILD_USER_ARG=build" && echo " - UID_ARG=1000" && echo " -
> GID_ARG=1000" && echo " - NODE_VERSION_ARG=v12.16.2" && echo " -
> ENTR_VERSION_ARG=4.6"
> 0.0s
> => CACHED [ 3/19] RUN apt update && apt install -y openjdk-8-jdk
> openjdk-11-jdk python3 python3-pip ant
> ant-optional make git gpg wget sudo
> 0.0s
> => CACHED [ 4/19] RUN apt-get install -y python-markupsafe
>
>
[jira] [Commented] (CASSANDRA-18825) Investigate suppressed streaming error
[ https://issues.apache.org/jira/browse/CASSANDRA-18825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764881#comment-17764881 ] Ekaterina Dimitrova commented on CASSANDRA-18825: - Maybe appears, but not that often? Check CASSANDRA-18849 > Investigate suppressed streaming error > -- > > Key: CASSANDRA-18825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18825 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Streaming >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.1.x > > > In CASSANDRA-18815, a [previously suppressed > exception|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/streaming/StreamSession.java#L700] > began to surface, requiring the tests to ignore it. However, the exception > does not appear on the 4.1 branch even though it looks like it should. We > should investigate and solve this. -- 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-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764880#comment-17764880
]
Ekaterina Dimitrova commented on CASSANDRA-18849:
-
Thanks for confirming.
>From reading CASSANDRA-18815, it seems we revealed the message pops up also in
>4.1?
{quote} This would mean that CASSANDRA-18733 actually fixed whatever was
suppressing this message before, and the bug is now in 4.1 where we don't see
it. WDYT, [~jmeredithco]?
If this is the case, then in this ticket we should accept this error in the
dtests, and make a new ticket to fix whatever is hiding it in 4.1.
{quote}
> Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
> --
>
> Key: CASSANDRA-18849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Since recently, it fails regularly on 4.1, 5.0, and trunk:
> h3.
> {code:java}
> Error Message
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
> StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']"
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
> 12:41:02,461 StreamSession.java:700 - [Stream
> #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session
> completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']
> {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-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764877#comment-17764877
]
Brandon Williams commented on CASSANDRA-18849:
--
Yeah, this looks like CASSANDRA-18815 and CASSANDRA-18828
> Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
> --
>
> Key: CASSANDRA-18849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Since recently, it fails regularly on 4.1, 5.0, and trunk:
> h3.
> {code:java}
> Error Message
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
> StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']"
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
> 12:41:02,461 StreamSession.java:700 - [Stream
> #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session
> completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']
> {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] [Comment Edited] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apac
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764876#comment-17764876
]
Ekaterina Dimitrova edited comment on CASSANDRA-18747 at 9/13/23 8:56 PM:
--
I haven't seen this one recently, and It was seen before very often. Though
trying to reproduce test_failed_snitch_update_property_file_snitch on current
5.0 and the commit where I saw it, I cannot do it running it hundreds of times
(500).
The Jenkins link is expired. I tried to find the run in nightlies to check in
the logs what happened - build 1 is missing.
I will try with the other test mentioned.
was (Author: e.dimitrova):
I haven't seen this one recently, and It was seen before very often. Though
trying to reproduce test_failed_snitch_update_property_file_snitch on current
5.0 and the commit where I saw it, I cannot do it running it hundreds of times.
The Jenkins link is expired. I tried to find the run in nightlies to check in
the logs what happened - build 1 is missing.
I will try with the other test mentioned.
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
>
[jira] [Commented] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.ca
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764876#comment-17764876
]
Ekaterina Dimitrova commented on CASSANDRA-18747:
-
I haven't seen this one recently, and It was seen before very often. Though
trying to reproduce test_failed_snitch_update_property_file_snitch on current
5.0 and the commit where I saw it, I cannot do it running it hundreds of times.
The Jenkins link is expired. I tried to find the run in nightlies to check in
the logs what happened - build 1 is missing.
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1666/testReport/junit/dtest.materialized_views_test/TestMaterializedViews/test_gcgs_validation/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apac
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764876#comment-17764876
]
Ekaterina Dimitrova edited comment on CASSANDRA-18747 at 9/13/23 8:55 PM:
--
I haven't seen this one recently, and It was seen before very often. Though
trying to reproduce test_failed_snitch_update_property_file_snitch on current
5.0 and the commit where I saw it, I cannot do it running it hundreds of times.
The Jenkins link is expired. I tried to find the run in nightlies to check in
the logs what happened - build 1 is missing.
I will try with the other test mentioned.
was (Author: e.dimitrova):
I haven't seen this one recently, and It was seen before very often. Though
trying to reproduce test_failed_snitch_update_property_file_snitch on current
5.0 and the commit where I saw it, I cannot do it running it hundreds of times.
The Jenkins link is expired. I tried to find the run in nightlies to check in
the logs what happened - build 1 is missing.
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
>
[jira] [Commented] (CASSANDRA-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764871#comment-17764871
]
Ekaterina Dimitrova commented on CASSANDRA-18849:
-
4.1:
[https://ci-cassandra.apache.org/job/Cassandra-4.1/409/testReport/dtest-novnode.secondary_indexes_test/TestPreJoinCallback/test_resume/]
5.0:
https://ci-cassandra.apache.org/job/Cassandra-5.0/31/testReport/dtest-offheap.secondary_indexes_test/TestPreJoinCallback/test_resume_2/
trunk:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1706/testReport/junit/dtest.secondary_indexes_test/TestPreJoinCallback/test_resume/]
[~brandonwilliams] , weren't you looking into new streaming exceptions in the
logs or so, or was it something different?
> Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
> --
>
> Key: CASSANDRA-18849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Since recently, it fails regularly on 4.1, 5.0, and trunk:
> h3.
> {code:java}
> Error Message
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
> StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']"
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
> 12:41:02,461 StreamSession.java:700 - [Stream
> #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session
> completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']
> {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-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18849:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/dtest/python
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
> --
>
> Key: CASSANDRA-18849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Since recently, it fails regularly on 4.1, 5.0, and trunk:
> h3.
> {code:java}
> Error Message
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
> StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']"
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
> 12:41:02,461 StreamSession.java:700 - [Stream
> #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session
> completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']
> {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-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
[
https://issues.apache.org/jira/browse/CASSANDRA-18849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18849:
Fix Version/s: 4.1.x
5.0.x
5.x
> Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
> --
>
> Key: CASSANDRA-18849
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> Since recently, it fails regularly on 4.1, 5.0, and trunk:
> h3.
> {code:java}
> Error Message
> failed on teardown with "Failed: Unexpected error found in node logs (see
> stdout for full details). Errors: [[node2] 'ERROR
> [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
> StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae]
> Socket closed before session completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']"
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
> 12:41:02,461 StreamSession.java:700 - [Stream
> #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session
> completion, peer 127.0.0.1:7000 is probably
> down.\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
>
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']
> {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] [Created] (CASSANDRA-18849) Test failure: dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
Ekaterina Dimitrova created CASSANDRA-18849:
---
Summary: Test failure:
dtest.secondary_indexes_test.TestPreJoinCallback.test_resume
Key: CASSANDRA-18849
URL: https://issues.apache.org/jira/browse/CASSANDRA-18849
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Since recently, it fails regularly on 4.1, 5.0, and trunk:
h3.
{code:java}
Error Message
failed on teardown with "Failed: Unexpected error found in node logs (see
stdout for full details). Errors: [[node2] 'ERROR
[Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13 12:41:02,461
StreamSession.java:700 - [Stream #cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket
closed before session completion, peer 127.0.0.1:7000 is probably
down.\njava.nio.channels.ClosedChannelException: null\n\tat
org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.base/java.lang.Thread.run(Thread.java:829)']"
Stacktrace
Unexpected error found in node logs (see stdout for full details). Errors:
[[node2] 'ERROR [Stream-Deserializer-/127.0.0.1:7000-6e2ae2f5] 2023-09-13
12:41:02,461 StreamSession.java:700 - [Stream
#cc2010c0-5232-11ee-bc8b-4945091d03ae] Socket closed before session completion,
peer 127.0.0.1:7000 is probably
down.\njava.nio.channels.ClosedChannelException: null\n\tat
org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
org.apache.cassandra.io.util.RebufferingInputStream.readByte(RebufferingInputStream.java:178)\n\tat
org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)\n\tat
org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:59)\n\tat
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
java.base/java.lang.Thread.run(Thread.java:829)']
{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-17475) Test failure: org.apache.cassandra.db.ImportTest.testImportInvalidateCache
[
https://issues.apache.org/jira/browse/CASSANDRA-17475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17475:
Fix Version/s: 5.x
> Test failure: org.apache.cassandra.db.ImportTest.testImportInvalidateCache
> --
>
> Key: CASSANDRA-17475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17475
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 5.x
>
>
> Intermittent failure in
> {{org.apache.cassandra.db.ImportTest#testImportInvalidateCache}} in 4.0:
> [https://ci-cassandra.apache.org/job/Cassandra-4.0/365/testReport/org.apache.cassandra.db/ImportTest/testImportInvalidateCache_compression/]
> {code:java}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> expected:<10> but was:<20>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<10> but was:<20>
> at
> org.apache.cassandra.db.ImportTest.testImportInvalidateCache(ImportTest.java:537)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-03-22 18:08:35,065 YamlConfigurationLoader.java:97 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-03-22 18:08:35,078 YamlConfigurationLoader.java:116 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-03-22 18:08:35,198 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-03-22 18:08:35,227 PlatformDependent0
> ...[truncated 1295721 chars]...
> ed transaction log, deleting
> /home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb_txn_flush_25995250-aa0b-11ec-b648-21f6c2fa4f09.log
>
> DEBUG [MemtableFlushWriter:1] 2022-03-22 18:08:59,398
> ColumnFamilyStore.java:1197 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-90-big-Data.db')]
> (1 sstables, 4.895KiB), biggest 4.895KiB, smallest 4.895KiB
> {code}
> There is only one failure in Jenkins, and I haven't been able to reproduce
> the failure with 1000 rounds in the multiplexer, with and without compression:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1411/workflows/01965c3d-3e5b-4f8f-b77c-248e2766518a]
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1414/workflows/6a872fa8-536f-4a71-a689-4e8b8c3735a5]
--
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-17475) Test failure: org.apache.cassandra.db.ImportTest.testImportInvalidateCache
[
https://issues.apache.org/jira/browse/CASSANDRA-17475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764870#comment-17764870
]
Ekaterina Dimitrova commented on CASSANDRA-17475:
-
I saw it today here in a run with very few failures on trunk -
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1706/testReport/junit/org.apache.cassandra.db/ImportTest/testImportInvalidateCache_cdc_jdk17/]
It seems that it is more of a Jenkins "thing"
> Test failure: org.apache.cassandra.db.ImportTest.testImportInvalidateCache
> --
>
> Key: CASSANDRA-17475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17475
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x
>
>
> Intermittent failure in
> {{org.apache.cassandra.db.ImportTest#testImportInvalidateCache}} in 4.0:
> [https://ci-cassandra.apache.org/job/Cassandra-4.0/365/testReport/org.apache.cassandra.db/ImportTest/testImportInvalidateCache_compression/]
> {code:java}
> Failed 1 times in the last 27 runs. Flakiness: 3%, Stability: 96%
> Error Message
> expected:<10> but was:<20>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<10> but was:<20>
> at
> org.apache.cassandra.db.ImportTest.testImportInvalidateCache(ImportTest.java:537)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-03-22 18:08:35,065 YamlConfigurationLoader.java:97 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-03-22 18:08:35,078 YamlConfigurationLoader.java:116 -
> Loading settings from
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-03-22 18:08:35,198 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-03-22 18:08:35,227 PlatformDependent0
> ...[truncated 1295721 chars]...
> ed transaction log, deleting
> /home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb_txn_flush_25995250-aa0b-11ec-b648-21f6c2fa4f09.log
>
> DEBUG [MemtableFlushWriter:1] 2022-03-22 18:08:59,398
> ColumnFamilyStore.java:1197 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system_schema/keyspaces-abac5682dea631c5b535b3d6cffd0fb6/nb-90-big-Data.db')]
> (1 sstables, 4.895KiB), biggest 4.895KiB, smallest 4.895KiB
> {code}
> There is only one failure in Jenkins, and I haven't been able to reproduce
> the failure with 1000 rounds in the multiplexer, with and without compression:
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1411/workflows/01965c3d-3e5b-4f8f-b77c-248e2766518a]
> *
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1414/workflows/6a872fa8-536f-4a71-a689-4e8b8c3735a5]
--
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-18792) Test failure: transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_between_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764866#comment-17764866
]
Brandon Williams commented on CASSANDRA-18792:
--
bq. they appear to just miss the message
>From the 'Head' and 'Tail' in the error from watch_log_for, I can see that the
>UP message is indeed between those and present in the log, but somehow missed.
>Which doesn't really make any sense since we know that should work.
> Test failure:
> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_between_and_cleanup
> --
>
> Key: CASSANDRA-18792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18792
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> The Python dtest {{Test failure:
> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_between_and_cleanup}}
> seems to be flaky at least in {{trunk}}:
> *
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/2993/workflows/80ac4db3-fc3d-4908-bc39-dfff6ab88871/jobs/105464/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3128/workflows/b0cf2754-81fd-491e-bac4-cc7fe8b0ac1b/jobs/70390/tests
> {code}
> ccmlib.node.ToolError: Subprocess ['nodetool', '-h', 'localhost', '-p',
> '7200', 'cleanup'] exited with non-zero status; exit status: 2;
> stderr: error: Node is involved in cluster membership changes. Not safe to
> run cleanup.
> -- StackTrace --
> java.lang.RuntimeException: Node is involved in cluster membership changes.
> Not safe to run cleanup.
> at
> org.apache.cassandra.service.StorageService.forceKeyspaceCleanup(StorageService.java:4037)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:262)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:814)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1472)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1310)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1405)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
> at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
>
[jira] [Updated] (CASSANDRA-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18843:
--
Severity: Low (was: Normal)
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Low
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
> at
> org.apache.cassandra.cql3.QueryProcessor.parse(QueryProcessor.java:329)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:255)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:166)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:185)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:212)
> at
> org.apache.cassandra.transport.Dispatcher$RequestProcessor.run(Dispatcher.java:109)
> at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:142)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> The incorrect user input should be captured inside the system (invisible to
> users) and only return the SyntaxException. (I have attached the system.log.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764833#comment-17764833
]
Stefan Miklosovic edited comment on CASSANDRA-18843 at 9/13/23 6:59 PM:
{code}
cqlsh> UPDATE ks.tb SET 9AMu = 2, c2 = 'v2' where c1 = 1;
SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c2 =
'v2' where c1 = 1;] reason: NullPointerException null
cqlsh> UPDATE ks.tb SET abc = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name abc in table ks.tb"
cqlsh> UPDATE ks.tb SET "9AMu" = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name "9AMu" in table ks.tb"
{code}
It does not work in case 9AMu is not in quotes.
While I think it is definitely something which could be improved, at the same
time is not it documented that columns can not start with a number or if they
do it has to be quoted?
That query itself is illegal as such. I think this is low priority, sure we
could improve that so it does not throw but else ...
was (Author: smiklosovic):
{code}
cqlsh> UPDATE ks.tb SET 9AMu = 2, c2 = 'v2' where c1 = 1;
SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c2 =
'v2' where c1 = 1;] reason: NullPointerException null
cqlsh> UPDATE ks.tb SET abc = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name abc in table ks.tb"
cqlsh> UPDATE ks.tb SET "9AMu" = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name "9AMu" in table ks.tb"
{code}
It does not work in case 9AMu is not in quotes.
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
> at
> org.apache.cassandra.cql3.QueryProcessor.parse(QueryProcessor.java:329)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:255)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:166)
> at
>
[jira] [Comment Edited] (CASSANDRA-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764833#comment-17764833
]
Stefan Miklosovic edited comment on CASSANDRA-18843 at 9/13/23 7:00 PM:
{code}
cqlsh> UPDATE ks.tb SET 9AMu = 2, c2 = 'v2' where c1 = 1;
SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c2 =
'v2' where c1 = 1;] reason: NullPointerException null
cqlsh> UPDATE ks.tb SET abc = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name abc in table ks.tb"
cqlsh> UPDATE ks.tb SET "9AMu" = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name "9AMu" in table ks.tb"
{code}
It does not work in case 9AMu is not in quotes.
While I think it is definitely something which could be improved, at the same
time is not it documented that columns can not start with a number or if they
do it has to be quoted?
That query itself is illegal as such. I think this is low priority, sure we
could improve that so has a different error message instead of a NPE but else
... it throws SyntaxException which is correct.
was (Author: smiklosovic):
{code}
cqlsh> UPDATE ks.tb SET 9AMu = 2, c2 = 'v2' where c1 = 1;
SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c2 =
'v2' where c1 = 1;] reason: NullPointerException null
cqlsh> UPDATE ks.tb SET abc = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name abc in table ks.tb"
cqlsh> UPDATE ks.tb SET "9AMu" = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name "9AMu" in table ks.tb"
{code}
It does not work in case 9AMu is not in quotes.
While I think it is definitely something which could be improved, at the same
time is not it documented that columns can not start with a number or if they
do it has to be quoted?
That query itself is illegal as such. I think this is low priority, sure we
could improve that so it does not throw but else ...
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
>
[jira] [Comment Edited] (CASSANDRA-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764833#comment-17764833
]
Stefan Miklosovic edited comment on CASSANDRA-18843 at 9/13/23 6:56 PM:
{code}
cqlsh> UPDATE ks.tb SET 9AMu = 2, c2 = 'v2' where c1 = 1;
SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c2 =
'v2' where c1 = 1;] reason: NullPointerException null
cqlsh> UPDATE ks.tb SET abc = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name abc in table ks.tb"
cqlsh> UPDATE ks.tb SET "9AMu" = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name "9AMu" in table ks.tb"
{code}
It does not work in case 9AMu is not in quotes.
was (Author: smiklosovic):
{code}
cqlsh> UPDATE ks.tb SET 9AMu = 2, c2 = 'v2' where c1 = 1;
SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c2 =
'v2' where c1 = 1;] reason: NullPointerException null
cqlsh> UPDATE ks.tb SET abc = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name abc in table ks.tb"
cqlsh> UPDATE ks.tb SET "9AMu" = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name "9AMu" in table ks.tb"
{code}
It does not work in case 9AMu is not in quotes.
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
> at
> org.apache.cassandra.cql3.QueryProcessor.parse(QueryProcessor.java:329)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:255)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:166)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:185)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:212)
> at
> org.apache.cassandra.transport.Dispatcher$RequestProcessor.run(Dispatcher.java:109)
> at
>
[jira] [Comment Edited] (CASSANDRA-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764833#comment-17764833
]
Stefan Miklosovic edited comment on CASSANDRA-18843 at 9/13/23 6:56 PM:
{code}
cqlsh> UPDATE ks.tb SET 9AMu = 2, c2 = 'v2' where c1 = 1;
SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c2 =
'v2' where c1 = 1;] reason: NullPointerException null
cqlsh> UPDATE ks.tb SET abc = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name abc in table ks.tb"
cqlsh> UPDATE ks.tb SET "9AMu" = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name "9AMu" in table ks.tb"
{code}
It does not work in case 9AMu is not in quotes.
was (Author: smiklosovic):
{code}
cqlsh> UPDATE ks.tb SET 9AMu = 2, c2 = 'v2' where c1 = 1;
SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c2 =
'v2' where c1 = 1;] reason: NullPointerException null
cqlsh> UPDATE ks.tb SET abc = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name abc in table ks.tb"
{code}
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
> at
> org.apache.cassandra.cql3.QueryProcessor.parse(QueryProcessor.java:329)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:255)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:166)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:185)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:212)
> at
> org.apache.cassandra.transport.Dispatcher$RequestProcessor.run(Dispatcher.java:109)
> at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
[jira] [Commented] (CASSANDRA-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764833#comment-17764833
]
Stefan Miklosovic commented on CASSANDRA-18843:
---
{code}
cqlsh> UPDATE ks.tb SET 9AMu = 2, c2 = 'v2' where c1 = 1;
SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c2 =
'v2' where c1 = 1;] reason: NullPointerException null
cqlsh> UPDATE ks.tb SET abc = 2, c2 = 'v2' where c1 = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Undefined
column name abc in table ks.tb"
{code}
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
> at
> org.apache.cassandra.cql3.QueryProcessor.parse(QueryProcessor.java:329)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:255)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:166)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:185)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:212)
> at
> org.apache.cassandra.transport.Dispatcher$RequestProcessor.run(Dispatcher.java:109)
> at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:142)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> The incorrect user input should be captured inside the system (invisible to
> users) and only return the SyntaxException. (I have attached the system.log.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764831#comment-17764831
]
Stefan Miklosovic commented on CASSANDRA-18843:
---
Something for [~blerer] maybe?
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
> at
> org.apache.cassandra.cql3.QueryProcessor.parse(QueryProcessor.java:329)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:255)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:166)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:185)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:212)
> at
> org.apache.cassandra.transport.Dispatcher$RequestProcessor.run(Dispatcher.java:109)
> at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:142)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> The incorrect user input should be captured inside the system (invisible to
> users) and only return the SyntaxException. (I have attached the system.log.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[ https://issues.apache.org/jira/browse/CASSANDRA-18843 ]
Stefan Miklosovic deleted comment on CASSANDRA-18843:
---
was (Author: smiklosovic):
Does it work if you put 9AMu into quotes?
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
> at
> org.apache.cassandra.cql3.QueryProcessor.parse(QueryProcessor.java:329)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:255)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:166)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:185)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:212)
> at
> org.apache.cassandra.transport.Dispatcher$RequestProcessor.run(Dispatcher.java:109)
> at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:142)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> The incorrect user input should be captured inside the system (invisible to
> users) and only return the SyntaxException. (I have attached the system.log.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764827#comment-17764827
]
Stefan Miklosovic commented on CASSANDRA-18843:
---
Does it work if you put 9AMu into quotes?
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
> at
> org.apache.cassandra.cql3.QueryProcessor.parse(QueryProcessor.java:329)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:255)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:166)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:185)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:212)
> at
> org.apache.cassandra.transport.Dispatcher$RequestProcessor.run(Dispatcher.java:109)
> at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:142)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> The incorrect user input should be captured inside the system (invisible to
> users) and only return the SyntaxException. (I have attached the system.log.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18686) Test failure: test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-18686:
Assignee: Brandon Williams
> Test failure: test_move_backwards_and_cleanup
> -
>
> Key: CASSANDRA-18686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18686
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> {code:java}
> ccmlib.node.ToolError: Subprocess ['nodetool', '-h', 'localhost', '-p',
> '7200', 'cleanup'] exited with non-zero status; exit status: 2; stderr:
> error: Node is involved in cluster membership changes. Not safe to run
> cleanup. -- StackTrace -- java.lang.RuntimeException: Node is involved in
> cluster membership changes. Not safe to run cleanup. at
> org.apache.cassandra.service.StorageService.forceKeyspaceCleanup(StorageService.java:4004)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72) 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:262) at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:814)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1472)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1310)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1405)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
> at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) self =
> 0x7f7b4db079b0> @flaky(max_runs=1) @pytest.mark.no_vnodes def
> test_move_backwards_and_cleanup(self): """Test moving a node backwards
> without moving past a neighbor token""" move_token = '5'
> expected_after_move =
[jira] [Commented] (CASSANDRA-18792) Test failure: transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_between_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764813#comment-17764813
]
Ekaterina Dimitrova commented on CASSANDRA-18792:
-
I suspect this is the issue with this one too - CASSANDRA-18686
> Test failure:
> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_between_and_cleanup
> --
>
> Key: CASSANDRA-18792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18792
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> The Python dtest {{Test failure:
> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_between_and_cleanup}}
> seems to be flaky at least in {{trunk}}:
> *
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/2993/workflows/80ac4db3-fc3d-4908-bc39-dfff6ab88871/jobs/105464/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3128/workflows/b0cf2754-81fd-491e-bac4-cc7fe8b0ac1b/jobs/70390/tests
> {code}
> ccmlib.node.ToolError: Subprocess ['nodetool', '-h', 'localhost', '-p',
> '7200', 'cleanup'] exited with non-zero status; exit status: 2;
> stderr: error: Node is involved in cluster membership changes. Not safe to
> run cleanup.
> -- StackTrace --
> java.lang.RuntimeException: Node is involved in cluster membership changes.
> Not safe to run cleanup.
> at
> org.apache.cassandra.service.StorageService.forceKeyspaceCleanup(StorageService.java:4037)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:262)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:814)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1472)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1310)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1405)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
> at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
> at
>
[jira] [Updated] (CASSANDRA-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15254: -- Reviewers: Benjamin Lerer (was: Benjamin Lerer, David Capwell) > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: Configuration Registry Diagram.png > > Time Spent: 20h 10m > Remaining Estimate: 0h > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/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-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764811#comment-17764811 ] David Capwell commented on CASSANDRA-15254: --- removed myself as reviewer as I won't have time until accord is stable on trunk > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: Configuration Registry Diagram.png > > Time Spent: 20h 10m > Remaining Estimate: 0h > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/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] [Assigned] (CASSANDRA-18675) (Accord): C* stores keyspace in Range which will cause ranges to be removed from Accord when DROP KEYSPACE is performed
[
https://issues.apache.org/jira/browse/CASSANDRA-18675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell reassigned CASSANDRA-18675:
-
Assignee: (was: David Capwell)
> (Accord): C* stores keyspace in Range which will cause ranges to be removed
> from Accord when DROP KEYSPACE is performed
> ---
>
> Key: CASSANDRA-18675
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18675
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>
> When translating the C* model to Accord we store the keyspace in the Range,
> this has the side effect that DROP KEYSPACE will cause Accord to see ranges
> removed between epoch versions. When this is enabled in BurnTest we see that
> there are cases where we stop making progress and can loop forever (until we
> OOM).
> Example
> {code}
> Failed on seed -1330125844737109546
> accord.burn.SimulationException: Failed on seed -1330125844737109546
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.util.HashMap.newNode(HashMap.java:1774)
> at java.util.HashMap.putVal(HashMap.java:632)
> at java.util.HashMap.put(HashMap.java:613)
> at
> accord.impl.InMemoryCommandStore$InMemorySafeStore.addCommandInternal(InMemoryCommandStore.java:582)
> at
> accord.impl.InMemoryCommandStore$InMemorySafeStore.addCommandInternal(InMemoryCommandStore.java:557)
> at
> accord.impl.AbstractSafeCommandStore$$Lambda$516/1241529534.accept(Unknown
> Source)
> at
> accord.impl.AbstractSafeCommandStore.getIfLoaded(AbstractSafeCommandStore.java:84)
> at
> accord.impl.AbstractSafeCommandStore.getInternalIfLoadedAndInitialised(AbstractSafeCommandStore.java:91)
> at
> accord.local.SafeCommandStore.ifLoadedAndInitialised(SafeCommandStore.java:194)
> at accord.local.Commands.lambda$updateWaitingOn$3(Commands.java:687)
> at accord.local.Commands$$Lambda$514/809300666.accept(Unknown Source)
> at accord.utils.SimpleBitSet.reverseForEach(SimpleBitSet.java:358)
> at
> accord.local.Command$WaitingOn$Update.forEachWaitingOnCommit(Command.java:1280)
> at accord.local.Commands.updateWaitingOn(Commands.java:685)
> at accord.local.Commands.initialiseWaitingOn(Commands.java:675)
> at accord.local.Commands.apply(Commands.java:481)
> at accord.messages.Apply.apply(Apply.java:121)
> at accord.messages.Apply.apply(Apply.java:34)
> {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-18686) Test failure: test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764806#comment-17764806
]
Ekaterina Dimitrova commented on CASSANDRA-18686:
-
This test only times out 3 times out of 500 in 4.1 as per this run -
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2514/workflows/e16127ba-0826-443d-8a34-bbcf161e336a/jobs/40965/tests]
But we can see the failure reported here also in 5.0, further to the timeouts -
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2515/workflows/003d3f6f-32aa-43e9-b721-6adc5600afa9/jobs/41071/tests
> Test failure: test_move_backwards_and_cleanup
> -
>
> Key: CASSANDRA-18686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18686
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> {code:java}
> ccmlib.node.ToolError: Subprocess ['nodetool', '-h', 'localhost', '-p',
> '7200', 'cleanup'] exited with non-zero status; exit status: 2; stderr:
> error: Node is involved in cluster membership changes. Not safe to run
> cleanup. -- StackTrace -- java.lang.RuntimeException: Node is involved in
> cluster membership changes. Not safe to run cleanup. at
> org.apache.cassandra.service.StorageService.forceKeyspaceCleanup(StorageService.java:4004)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72) 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:262) at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:814)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1472)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1310)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1405)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
> at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
> at
>
[jira] [Updated] (CASSANDRA-18686) Test failure: test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18686:
Fix Version/s: 5.0.x
> Test failure: test_move_backwards_and_cleanup
> -
>
> Key: CASSANDRA-18686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18686
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> {code:java}
> ccmlib.node.ToolError: Subprocess ['nodetool', '-h', 'localhost', '-p',
> '7200', 'cleanup'] exited with non-zero status; exit status: 2; stderr:
> error: Node is involved in cluster membership changes. Not safe to run
> cleanup. -- StackTrace -- java.lang.RuntimeException: Node is involved in
> cluster membership changes. Not safe to run cleanup. at
> org.apache.cassandra.service.StorageService.forceKeyspaceCleanup(StorageService.java:4004)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72) 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:262) at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:814)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1472)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1310)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1405)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
> at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) self =
> 0x7f7b4db079b0> @flaky(max_runs=1) @pytest.mark.no_vnodes def
> test_move_backwards_and_cleanup(self): """Test moving a node backwards
> without moving past a neighbor token""" move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>
[jira] [Commented] (CASSANDRASC-60) Sidecar API to expose cluster topology information
[ https://issues.apache.org/jira/browse/CASSANDRASC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764805#comment-17764805 ] Dinesh Joshi commented on CASSANDRASC-60: - +1, thanks for the patch! > Sidecar API to expose cluster topology information > -- > > Key: CASSANDRASC-60 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-60 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Arjun Ashok >Assignee: Arjun Ashok >Priority: Normal > Labels: pull-request-available > > This API will expose token ranges and the corresponding read and write > replicas. The write replica-set token ranges will include natural and pending > ranges, so clients can have a complete view of the cluster as nodes are > joining or leaving. -- 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-18836) Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
[
https://issues.apache.org/jira/browse/CASSANDRA-18836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764771#comment-17764771
]
Maxim Muzafarov commented on CASSANDRA-18836:
-
I have checked the sources and found {{BufferedChecksumIndexInput}} which is
used in several places, but still initialized to the CRC32 (not the CRC32C in
jdk11+). This class is a part of the Lucene library itself, so it is not easy
to make it to use CRC32C instead of the default CRC32.
It is out of the scope mentioned in the issue description since we only have to
deal with the IndexFileUtils. It should not be a big problem to write our own
extension of the ChecksumIndexInput that uses CRC32C checksum algorithm
considering the fact that we already have our SAICodecUtils. The question here
- do we want to have our own ChecksumIndexInput that uses crc32c or is it
enough to just fix the IndexFileUtils?
> Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
>
>
> Key: CASSANDRA-18836
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18836
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index, Feature/SAI
>Reporter: Caleb Rackliffe
>Priority: Normal
>
> It seems that now we're on Java 11 for 5.0, there isn't much reason not to
> use CRC32C as a drop-in replacement for CRC32. SAI isn't even released, so
> has no binary compatibility entanglements, and this should be pretty
> straightforward.
> See https://github.com/apache/bookkeeper/pull/3309
--
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-18792) Test failure: transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_between_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764769#comment-17764769
]
Brandon Williams commented on CASSANDRA-18792:
--
There's no real pattern to which node doesn't see node2 (the one that's always
moved) come back up, and they appear to just miss the message:
bq. INFO [GossipStage:1] 2023-09-12 20:41:08,196 Gossiper.java:1465 - Node
/127.0.0.2:7000 has restarted, now UP
...
bq. ccmlib.node.TimeoutError: 12 Sep 2023 20:43:08 [node4] after 120.11/120
seconds Missing: ['127.0.0.2:7000.* is now UP'] not found in system.log:
> Test failure:
> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_between_and_cleanup
> --
>
> Key: CASSANDRA-18792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18792
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Andres de la Peña
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> The Python dtest {{Test failure:
> transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_between_and_cleanup}}
> seems to be flaky at least in {{trunk}}:
> *
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/2993/workflows/80ac4db3-fc3d-4908-bc39-dfff6ab88871/jobs/105464/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3128/workflows/b0cf2754-81fd-491e-bac4-cc7fe8b0ac1b/jobs/70390/tests
> {code}
> ccmlib.node.ToolError: Subprocess ['nodetool', '-h', 'localhost', '-p',
> '7200', 'cleanup'] exited with non-zero status; exit status: 2;
> stderr: error: Node is involved in cluster membership changes. Not safe to
> run cleanup.
> -- StackTrace --
> java.lang.RuntimeException: Node is involved in cluster membership changes.
> Not safe to run cleanup.
> at
> org.apache.cassandra.service.StorageService.forceKeyspaceCleanup(StorageService.java:4037)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:262)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:814)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1472)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1310)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1405)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
> at
>
[jira] [Commented] (CASSANDRA-18781) Add the ability to disable bulk loading of SSTables on a node
[ https://issues.apache.org/jira/browse/CASSANDRA-18781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764759#comment-17764759 ] Runtian Liu commented on CASSANDRA-18781: - cool, just reverted the last commit and squash all commits. Please check if there is anything more need to be changed. > Add the ability to disable bulk loading of SSTables on a node > - > > Key: CASSANDRA-18781 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18781 > Project: Cassandra > Issue Type: Improvement > Components: Tool/bulk load >Reporter: Runtian Liu >Assignee: Runtian Liu >Priority: Normal > Fix For: 5.x > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, Cassandra database users can use sstableloader to bulk load data > into Cassandra. However, for a Cassandra operator, there is no way to > forcibly block this behavior. Additionally, there is no metric indicating > whether the bulk load is being used on the server side. If a client is using > sstableloader, they will also need to upgrade the sstableloader code to the > new major version. This lack of control and visibility can become a blocker > during a major version upgrade. > > 1. Can we add a config to disable bulk load feature? Or it falls into > https://issues.apache.org/jira/browse/CASSANDRA-8303 > 2. Can we add metrics for bulk load used on server end? -- 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-18848) GCInspector "Error accessing field of java.nio.Bits" under java17
[
https://issues.apache.org/jira/browse/CASSANDRA-18848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18848:
--
Status: Patch Available (was: Review In Progress)
> GCInspector "Error accessing field of java.nio.Bits" under java17
> -
>
> Key: CASSANDRA-18848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18848
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 5.0.x, 5.x
>
>
> Running under java17, {{GCInspector}} throws the following exception:
> {noformat}
> DEBUG [main] 2023-09-13 09:35:28,031 GCInspector.java:85 - Error accessing
> field of java.nio.Bits
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> static final java.util.concurrent.atomic.AtomicLong
> java.nio.Bits.TOTAL_CAPACITY accessible: module java.base does not "opens
> java.nio" to unnamed module @503d687a
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at
> org.apache.cassandra.service.GCInspector.(GCInspector.java:80)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:328)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:729)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:853)
> INFO [main] 2023-09-13 09:35:28,039 PaxosUncommittedTracker.java:236 -
> enabling PaxosUncommittedTracker {noformat}
> This is because {{GCInspector}} uses reflection to read the
> {{TOTAL_CAPACITY}} from {{{}java.nio.Bits{}}}. Access was restricted
> somewhere between 11 and 17.
> Note: this is a rather harmless error, as we only look at
> {{Bits.totalCapacity}} for metrics collection on how much direct memory is
> being used by \{{ByteBuffer}}s. If we fail to read the field, we simply
> return -1 for the metric value.
--
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-18848) GCInspector "Error accessing field of java.nio.Bits" under java17
[
https://issues.apache.org/jira/browse/CASSANDRA-18848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764755#comment-17764755
]
Stefan Miklosovic commented on CASSANDRA-18848:
---
I verified that it does not throw that exception anymore on Java 17 so I am +1
in that regard. TOTAL_CAPACITY change makes sense to me as well.
> GCInspector "Error accessing field of java.nio.Bits" under java17
> -
>
> Key: CASSANDRA-18848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18848
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 5.0.x, 5.x
>
>
> Running under java17, {{GCInspector}} throws the following exception:
> {noformat}
> DEBUG [main] 2023-09-13 09:35:28,031 GCInspector.java:85 - Error accessing
> field of java.nio.Bits
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> static final java.util.concurrent.atomic.AtomicLong
> java.nio.Bits.TOTAL_CAPACITY accessible: module java.base does not "opens
> java.nio" to unnamed module @503d687a
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at
> org.apache.cassandra.service.GCInspector.(GCInspector.java:80)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:328)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:729)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:853)
> INFO [main] 2023-09-13 09:35:28,039 PaxosUncommittedTracker.java:236 -
> enabling PaxosUncommittedTracker {noformat}
> This is because {{GCInspector}} uses reflection to read the
> {{TOTAL_CAPACITY}} from {{{}java.nio.Bits{}}}. Access was restricted
> somewhere between 11 and 17.
> Note: this is a rather harmless error, as we only look at
> {{Bits.totalCapacity}} for metrics collection on how much direct memory is
> being used by \{{ByteBuffer}}s. If we fail to read the field, we simply
> return -1 for the metric value.
--
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-18274) Test failure: org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression
[ https://issues.apache.org/jira/browse/CASSANDRA-18274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18274: Fix Version/s: 4.1.x > Test failure: > org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression > - > > Key: CASSANDRA-18274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18274 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Maxwell Guo >Assignee: Maxwell Guo >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > > https://ci-cassandra.apache.org/job/Cassandra-4.1/277/testReport/org.apache.cassandra.utils.binlog/BinLogTest/testTruncationReleasesLogSpace_compression/ -- 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-18274) Test failure: org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression
[ https://issues.apache.org/jira/browse/CASSANDRA-18274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764753#comment-17764753 ] Ekaterina Dimitrova commented on CASSANDRA-18274: - Still seen: 5.0.x - [https://ci-cassandra.apache.org/job/Cassandra-5.0/28/testReport/org.apache.cassandra.utils.binlog/BinLogTest/testTruncationReleasesLogSpace__jdk11/] But also, we can say it is not a regression in the 5.x series, as seen in 4.1 recently: https://ci-cassandra.apache.org/job/Cassandra-4.1/409/testReport/org.apache.cassandra.utils.binlog/BinLogTest/testTruncationReleasesLogSpace_2/ > Test failure: > org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression > - > > Key: CASSANDRA-18274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18274 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Maxwell Guo >Assignee: Maxwell Guo >Priority: Normal > Fix For: 5.0.x, 5.x > > > https://ci-cassandra.apache.org/job/Cassandra-4.1/277/testReport/org.apache.cassandra.utils.binlog/BinLogTest/testTruncationReleasesLogSpace_compression/ -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (2cf719cf -> 7e3ab5aa)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 2cf719cf generate docs for ba5f9001 new 7e3ab5aa generate docs for ba5f9001 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (2cf719cf) \ N -- N -- N refs/heads/asf-staging (7e3ab5aa) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4881412 -> 4881412 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18848) GCInspector "Error accessing field of java.nio.Bits" under java17
[
https://issues.apache.org/jira/browse/CASSANDRA-18848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18848:
--
Reviewers: Stefan Miklosovic, Stefan Miklosovic
Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> GCInspector "Error accessing field of java.nio.Bits" under java17
> -
>
> Key: CASSANDRA-18848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18848
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 5.0.x, 5.x
>
>
> Running under java17, {{GCInspector}} throws the following exception:
> {noformat}
> DEBUG [main] 2023-09-13 09:35:28,031 GCInspector.java:85 - Error accessing
> field of java.nio.Bits
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> static final java.util.concurrent.atomic.AtomicLong
> java.nio.Bits.TOTAL_CAPACITY accessible: module java.base does not "opens
> java.nio" to unnamed module @503d687a
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at
> org.apache.cassandra.service.GCInspector.(GCInspector.java:80)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:328)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:729)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:853)
> INFO [main] 2023-09-13 09:35:28,039 PaxosUncommittedTracker.java:236 -
> enabling PaxosUncommittedTracker {noformat}
> This is because {{GCInspector}} uses reflection to read the
> {{TOTAL_CAPACITY}} from {{{}java.nio.Bits{}}}. Access was restricted
> somewhere between 11 and 17.
> Note: this is a rather harmless error, as we only look at
> {{Bits.totalCapacity}} for metrics collection on how much direct memory is
> being used by \{{ByteBuffer}}s. If we fail to read the field, we simply
> return -1 for the metric value.
--
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-18843) Query parsing error handling problem: NPE when user types an incorrect query statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764742#comment-17764742
]
Ke Han commented on CASSANDRA-18843:
[~maxwellguo] It's an incorrect user input and actually means nothing.
Normally, this will be processed by error handling logic. But if there's an
special string like "9AMu", it could jump out of the scope of error-handing
logic and throw NPE.
> Query parsing error handling problem: NPE when user types an incorrect query
> statement
> --
>
> Key: CASSANDRA-18843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18843
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Syntax
>Reporter: Ke Han
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Attachments: system.log
>
>
> When using cassandra cqlsh shell (4.1.3 or 3.11.16), typing the following
> query will lead to an null pointer exception
> {code:java}
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.tb (c1 INT,c2 TEXT, PRIMARY KEY (c1));
> cqlsh> INSERT INTO ks.tb (c1, c2) VALUES (0, 'v1');
> cqlsh> UPDATE ks.tb SET c2 = 'v2' WHERE c1 = 0;
> cqlsh> UPDATE ks.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> Only typing the update query without creating ks can already trigger it.
> {code:java}
> cqlsh> UPDATE ks2.tb SET 9AMu = 2, c1 = 0,c2 = 'v2';
> SyntaxException: Failed parsing statement: [UPDATE ks2.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] reason: NullPointerException null {code}
> In system.log, it shows the following exception
> {code:java}
> ERROR [Native-Transport-Requests-1] 2023-09-13 00:17:01,463
> QueryProcessor.java:891 - The statement: [UPDATE ks.tb SET 9AMu = 2, c1 =
> 0,c2 = 'v2';] could not be parsed.
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.cql3.Cql_Parser.addRawUpdate(Cql_Parser.java:396)
> at
> org.apache.cassandra.cql3.Cql_Parser.normalColumnOperation(Cql_Parser.java:14334)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperationDifferentiator(Cql_Parser.java:14233)
> at
> org.apache.cassandra.cql3.Cql_Parser.columnOperation(Cql_Parser.java:14172)
> at
> org.apache.cassandra.cql3.Cql_Parser.updateStatement(Cql_Parser.java:3846)
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:536)
> at
> org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:609)
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:363)
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:883)
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:853)
> at
> org.apache.cassandra.cql3.QueryProcessor.parse(QueryProcessor.java:329)
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:115)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:255)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:166)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:185)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:212)
> at
> org.apache.cassandra.transport.Dispatcher$RequestProcessor.run(Dispatcher.java:109)
> at
> org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:142)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:750) {code}
>
> The incorrect user input should be captured inside the system (invisible to
> users) and only return the SyntaxException. (I have attached the system.log.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16061) Test failure: transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16061: Fix Version/s: 4.1.x 5.0.x > Test failure: > transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup > -- > > Key: CASSANDRA-16061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16061 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1.x, 5.0.x, 5.x > > > Failing here, also locally: > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/312/workflows/da4ce69c-e778-467e-b9f3-27ab166a8321/jobs/1945] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14667) Upgrade Dropwizard Metrics to 4.x
[ https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764737#comment-17764737 ] Stefan Miklosovic edited comment on CASSANDRA-14667 at 9/13/23 3:10 PM: I am not sure I have ever encountered this "code style" elsewhere. Nothing indicates that exclusions are used for readability (1). As I understand that, that is used solely and primarily for excluding unwanted dependencies on purpose. As we are effectively not excluding anything as it is on the classpath anyway, maybe just putting a comment that logback-core and logback-classic "shadow" the respective dependecies in metrics-logback would be just enough. If we bumped the version of metric-logback in the future which would use newer versions of these logback libraries, the older libraries declared directly in the pom would be used because of the rule that "closer dep to the root wins". On the other hand, if we bumped the versions of the dependencies in pom.xml directly, based on that rule metrics-logback would use newer ones. As long as we use patch releases it should all just play together. In neither case there is any reason we should exclude it. A comment is just enough. Or maybe there is some hidden meaning here which I am not aware of. https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html was (Author: smiklosovic): I am not sure I have ever encountered this "code style" elsewhere. Nothing indicates that exclusions are used for readability (1). As I understand that, that is used solely and primarily for excluding unwanted dependencies on purpose. As we are effectively not excluding anything as it is on the classpath anyway, maybe just putting a comment that logback-core and logback-classic "shadow" the respective dependecies in metrics-logback would be just enough. https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html > Upgrade Dropwizard Metrics to 4.x > - > > Key: CASSANDRA-14667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14667 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Stig Rohde Døssing >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: signature.asc, signature.asc, signature.asc, > signature.asc > > Time Spent: 1.5h > Remaining Estimate: 0h > > Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for > Java 9 compatibility. It would be good to upgrade the Metrics library as part > of the version of Cassandra that adds Java 9 compatibility > (https://issues.apache.org/jira/browse/CASSANDRA-9608). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16061) Test failure: transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16061: Summary: Test failure: transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup (was: transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup) > Test failure: > transient_replication_ring_test.py::TestTransientReplicationRing::test_move_forwards_and_cleanup > -- > > Key: CASSANDRA-16061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16061 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > Failing here, also locally: > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/312/workflows/da4ce69c-e778-467e-b9f3-27ab166a8321/jobs/1945] -- 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-17634) Test failure: dtest-upgrade.upgrade_tests.drop_compact_storage_upgrade_test.TestDropCompactStorage.test_drop_compact_storage_mixed_cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-17634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17634:
Summary: Test failure:
dtest-upgrade.upgrade_tests.drop_compact_storage_upgrade_test.TestDropCompactStorage.test_drop_compact_storage_mixed_cluster
(was: Fix test:
dtest-upgrade.upgrade_tests.drop_compact_storage_upgrade_test.TestDropCompactStorage.test_drop_compact_storage_mixed_cluster)
> Test failure:
> dtest-upgrade.upgrade_tests.drop_compact_storage_upgrade_test.TestDropCompactStorage.test_drop_compact_storage_mixed_cluster
> --
>
> Key: CASSANDRA-17634
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17634
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> From
> https://ci-cassandra.apache.org/job/Cassandra-4.1/24/testReport/dtest-upgrade.upgrade_tests.drop_compact_storage_upgrade_test/TestDropCompactStorage/test_drop_compact_storage_mixed_cluster/
> {noformat}
> Error Message
> test teardown failure
> Stacktrace
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node2] 'ERROR [NonPeriodicTasks:1] 2022-05-18 11:36:18,780
> LogTransaction.java:398 - SSTableTidier ran with no existing data file for an
> sstable that was not new', [node2] 'ERROR [NonPeriodicTasks:1] 2022-05-18
> 11:36:18,788 LogTransaction.java:250 - Unable to delete
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-vk4cgziz/test/node2/data0/system_schema/columns-24101c25a2ae3af787c1b40ee1aca33f/nb_txn_upgradesstables_bbe470a4-d69e-11ec-8d33-579a578037c7.log
> as it does not exist, see debug log file for stack trace', [node2] 'ERROR
> [NonPeriodicTasks:1] 2022-05-18 11:36:18,821 LogTransaction.java:250 - Unable
> to delete
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-vk4cgziz/test/node2/data0/system_schema/columns-24101c25a2ae3af787c1b40ee1aca33f/nb_txn_upgradesstables_bbe4709a-d69e-11ec-8d33-579a578037c7.log
> as it does not exist, see debug log file for stack trace', [node2] 'ERROR
> [CompactionExecutor:1] 2022-05-18 11:36:29,589 JVMStabilityInspector.java:68
> - Exception in thread
> Thread[CompactionExecutor:1,5,CompactionExecutor]\njava.lang.NullPointerException:
> null\n\tat
> org.apache.cassandra.db.lifecycle.LogFile.makeRecord(LogFile.java:346)\n\tat
> org.apache.cassandra.db.lifecycle.LogFile.contains(LogFile.java:381)\n\tat
> org.apache.cassandra.db.lifecycle.LogTransaction.obsoleted(LogTransaction.java:183)\n\tat
>
> org.apache.cassandra.db.lifecycle.Helpers.prepareForObsoletion(Helpers.java:136)\n\tat
>
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.doPrepare(LifecycleTransaction.java:206)\n\tat
>
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:168)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:386)\n\tat
>
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:168)\n\tat
>
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:106)\n\tat
>
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:168)\n\tat
>
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:179)\n\tat
>
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:116)\n\tat
>
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:218)\n\tat
>
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)\n\tat
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)\n\tat
>
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)\n\tat
>
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:299)\n\tat
> org.apache.cassandra.concurrent.FutureTask$2.call(FutureTask.java:98)\n\tat
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)\n\tat
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.lang.Thread.run(Thread.java:748)']
> {noformat}
--
This
[jira] [Updated] (CASSANDRA-18151) Test failure: org.apache.cassandra.distributed.test.SchemaTest timeout
[ https://issues.apache.org/jira/browse/CASSANDRA-18151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18151: Fix Version/s: 5.0.x > Test failure: org.apache.cassandra.distributed.test.SchemaTest timeout > -- > > Key: CASSANDRA-18151 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18151 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > > See here for another timeout of this test > https://app.circleci.com/pipelines/github/bereng/cassandra/836/workflows/dd9f0441-df59-40e7-b00b-c0788f0235a6/jobs/7597/tests#failed-test-0 > It is unclear if it's an env issue or related to CASSANDRA-17819 or similar > ones as this test has some history to it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18151) Test failure: org.apache.cassandra.distributed.test.SchemaTest timeout
[ https://issues.apache.org/jira/browse/CASSANDRA-18151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18151: Summary: Test failure: org.apache.cassandra.distributed.test.SchemaTest timeout (was: org.apache.cassandra.distributed.test.SchemaTest timeout) > Test failure: org.apache.cassandra.distributed.test.SchemaTest timeout > -- > > Key: CASSANDRA-18151 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18151 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 5.x > > > See here for another timeout of this test > https://app.circleci.com/pipelines/github/bereng/cassandra/836/workflows/dd9f0441-df59-40e7-b00b-c0788f0235a6/jobs/7597/tests#failed-test-0 > It is unclear if it's an env issue or related to CASSANDRA-17819 or similar > ones as this test has some history to it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18189) Test failure: cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_timeouts
[
https://issues.apache.org/jira/browse/CASSANDRA-18189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18189:
Summary: Test failure:
cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_timeouts
(was: Test failure in
cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_timeouts)
> Test failure:
> cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_timeouts
> --
>
> Key: CASSANDRA-18189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18189
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Caleb Rackliffe
>Priority: Normal
> Labels: cqlsh, dtest, python, test
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/523/testReport/dtest.cqlsh_tests.test_cqlsh_copy/TestCqlshCopy/test_bulk_round_trip_with_timeouts/
> {noformat}
> assert 10 == 94764
> + where 10 = sum( TestCqlshCopy._test_bulk_round_trip.. at 0x7f8b21987b90>)
> + and 94764 = sum( TestCqlshCopy._test_bulk_round_trip.. at 0x7f8b21986dc0>)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18222) Test failure: org.apache.cassandra.distributed.test.accord.AccordIntegrationTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18222: Summary: Test failure: org.apache.cassandra.distributed.test.accord.AccordIntegrationTest (was: Fix flaky test org.apache.cassandra.distributed.test.accord.AccordIntegrationTest) > Test failure: > org.apache.cassandra.distributed.test.accord.AccordIntegrationTest > > > Key: CASSANDRA-18222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18222 > Project: Cassandra > Issue Type: Bug > Components: Accord, CI >Reporter: David Capwell >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > The accord integration tests are currently flaky due to Preempt happening (we > convert that to a timeout). We need to address this to make sure the tests > are stable. > One solution may be make SimpleProgressLog’s frequency run different for > jvm-dtest (likely to depend on CASSANDRA-18221 ), this would be similar to > what we already do as timeouts maybe larger in jvm-dtest due to the extra > complexity running multiple processes in the same JVM. Another solution may > be to have the client coordinator “attach” to the new coordinator, this would > avoid the user being impacted by this preempt when the coordinator is > healthy. > Example: > https://app.circleci.com/pipelines/github/dcapwell/cassandra/1822/workflows/0d92898f-ad7d-4a7d-9198-3a7ce844ee93/jobs/16464 -- 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-18222) Test failure: org.apache.cassandra.distributed.test.accord.AccordIntegrationTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18222: Fix Version/s: 5.0.x > Test failure: > org.apache.cassandra.distributed.test.accord.AccordIntegrationTest > > > Key: CASSANDRA-18222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18222 > Project: Cassandra > Issue Type: Bug > Components: Accord, CI >Reporter: David Capwell >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.0.x, 5.x > > > The accord integration tests are currently flaky due to Preempt happening (we > convert that to a timeout). We need to address this to make sure the tests > are stable. > One solution may be make SimpleProgressLog’s frequency run different for > jvm-dtest (likely to depend on CASSANDRA-18221 ), this would be similar to > what we already do as timeouts maybe larger in jvm-dtest due to the extra > complexity running multiple processes in the same JVM. Another solution may > be to have the client coordinator “attach” to the new coordinator, this would > avoid the user being impacted by this preempt when the coordinator is > healthy. > Example: > https://app.circleci.com/pipelines/github/dcapwell/cassandra/1822/workflows/0d92898f-ad7d-4a7d-9198-3a7ce844ee93/jobs/16464 -- 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-18274) Test failure: org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression
[ https://issues.apache.org/jira/browse/CASSANDRA-18274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18274: Fix Version/s: 5.0.x > Test failure: > org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression > - > > Key: CASSANDRA-18274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18274 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Maxwell Guo >Assignee: Maxwell Guo >Priority: Normal > Fix For: 5.0.x, 5.x > > > https://ci-cassandra.apache.org/job/Cassandra-4.1/277/testReport/org.apache.cassandra.utils.binlog/BinLogTest/testTruncationReleasesLogSpace_compression/ -- 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-18274) Test failure: org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression
[ https://issues.apache.org/jira/browse/CASSANDRA-18274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18274: Summary: Test failure: org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression (was: org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression) > Test failure: > org.apache.cassandra.utils.binlog.BinLogTest.testTruncationReleasesLogSpace-compression > - > > Key: CASSANDRA-18274 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18274 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Maxwell Guo >Assignee: Maxwell Guo >Priority: Normal > Fix For: 5.x > > > https://ci-cassandra.apache.org/job/Cassandra-4.1/277/testReport/org.apache.cassandra.utils.binlog/BinLogTest/testTruncationReleasesLogSpace_compression/ -- 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-18455) Test failure: test_putget – dtest.putget_test.TestPutGet
[
https://issues.apache.org/jira/browse/CASSANDRA-18455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18455:
Summary: Test failure: test_putget – dtest.putget_test.TestPutGet (was:
Fix test_putget – dtest.putget_test.TestPutGet)
> Test failure: test_putget – dtest.putget_test.TestPutGet
>
>
> Key: CASSANDRA-18455
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18455
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Seen on current trunk, here:
> [https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2416/tests]
> {code:java}
> Error failed on teardown with "Unexpected error found in node logs (see
> stdout for full details). Errors: [[node3] 'ERROR [PendingRangeCalculator:1]
> 2023-04-08 00:54:06,468 JVMStabilityInspector.java:68 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_traces\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:325)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:163)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:163)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:152)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.lang.Thread.run(Thread.java:750)']" Stacktrace Unexpected error found
> in node logs (see stdout for full details). Errors: [[node3] 'ERROR
> [PendingRangeCalculator:1] 2023-04-08 00:54:06,468
> JVMStabilityInspector.java:68 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_traces\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:325)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:163)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:163)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:152)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.lang.Thread.run(Thread.java:750)']{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-14667) Upgrade Dropwizard Metrics to 4.x
[ https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17764737#comment-17764737 ] Stefan Miklosovic commented on CASSANDRA-14667: --- I am not sure I have ever encountered this "code style" elsewhere. Nothing indicates that exclusions are used for readability (1). As I understand that, that is used solely and primarily for excluding unwanted dependencies on purpose. As we are effectively not excluding anything as it is on the classpath anyway, maybe just putting a comment that logback-core and logback-classic "shadow" the respective dependecies in metrics-logback would be just enough. https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html > Upgrade Dropwizard Metrics to 4.x > - > > Key: CASSANDRA-14667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14667 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Stig Rohde Døssing >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: signature.asc, signature.asc, signature.asc, > signature.asc > > Time Spent: 1.5h > Remaining Estimate: 0h > > Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for > Java 9 compatibility. It would be good to upgrade the Metrics library as part > of the version of Cassandra that adds Java 9 compatibility > (https://issues.apache.org/jira/browse/CASSANDRA-9608). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18440) Test failure: org.apache.cassandra.distributed.test.RepairTest.testForcedNormalRepairWithOneNodeDown
[
https://issues.apache.org/jira/browse/CASSANDRA-18440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18440:
Summary: Test failure:
org.apache.cassandra.distributed.test.RepairTest.testForcedNormalRepairWithOneNodeDown
(was: Fix
org.apache.cassandra.distributed.test.RepairTest.testForcedNormalRepairWithOneNodeDown)
> Test failure:
> org.apache.cassandra.distributed.test.RepairTest.testForcedNormalRepairWithOneNodeDown
>
>
> Key: CASSANDRA-18440
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18440
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> The test appears to be flaky as seen in
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1509/testReport/org.apache.cassandra.distributed.test/RepairTest/testForcedNormalRepairWithOneNodeDown__jdk1_8/
> and
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2329/workflows/f56b57d8-a283-4c76-968a-a2a553bf57b7/jobs/20786/tests#failed-test-0
> {code:java}
> junit.framework.AssertionFailedError: Exception found expected null, but
> was: at
> org.apache.cassandra.service.ActiveRepairService.failRepair(ActiveRepairService.java:748)
> at
> org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:681)
> at
> org.apache.cassandra.repair.RepairRunnable.prepare(RepairRunnable.java:400)
> at
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:279)
> at
> org.apache.cassandra.repair.RepairRunnable.run(RepairRunnable.java:248)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:750)
> >
> at
> org.apache.cassandra.distributed.test.DistributedRepairUtils.lambda$assertParentRepairSuccess$4(DistributedRepairUtils.java:129)
> at
> org.apache.cassandra.distributed.test.DistributedRepairUtils.validateExistingParentRepair(DistributedRepairUtils.java:164)
> at
> org.apache.cassandra.distributed.test.DistributedRepairUtils.assertParentRepairSuccess(DistributedRepairUtils.java:124)
> at
> org.apache.cassandra.distributed.test.RepairTest.testForcedNormalRepairWithOneNodeDown(RepairTest.java:212)
> {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-18432) Test failure: org.apache.cassandra.index.sasi.SASICQLTest#testPagingWithClustering
[
https://issues.apache.org/jira/browse/CASSANDRA-18432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18432:
Summary: Test failure:
org.apache.cassandra.index.sasi.SASICQLTest#testPagingWithClustering (was: Fix
flaky test:
org.apache.cassandra.index.sasi.SASICQLTest#testPagingWithClustering)
> Test failure:
> org.apache.cassandra.index.sasi.SASICQLTest#testPagingWithClustering
> --
>
> Key: CASSANDRA-18432
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18432
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
>
> {noformat}
> junit.framework.AssertionFailedError: expected:<20> but was:<10>
> at
> org.apache.cassandra.index.sasi.SASICQLTest.testPagingWithClustering(SASICQLTest.java:83)
> {noformat}
> https://app.circleci.com/pipelines/github/driftx/cassandra/965/workflows/ca4f7fcf-0022-43e0-804d-8a8b9fbec8ca/jobs/19802
--
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-18635) Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18635:
Summary: Test failure:
org.apache.cassandra.distributed.test.UpgradeSSTablesTest (was: Fix flaky
test: org.apache.cassandra.distributed.test.UpgradeSSTablesTest)
> Test failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest
> ---
>
> Key: CASSANDRA-18635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18635
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1095/workflows/6114e2e3-8dcc-4bb0-b664-ae7d82c3349f/jobs/33405/tests
> {noformat}
> junit.framework.AssertionFailedError: expected:<0> but was:<2>
> at
> org.apache.cassandra.distributed.test.UpgradeSSTablesTest.upgradeSSTablesInterruptsOngoingCompaction(UpgradeSSTablesTest.java:86)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18686) Test failure: test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-18686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18686:
Summary: Test failure: test_move_backwards_and_cleanup (was: Fix flaky
test_move_backwards_and_cleanup)
> Test failure: test_move_backwards_and_cleanup
> -
>
> Key: CASSANDRA-18686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18686
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> {code:java}
> ccmlib.node.ToolError: Subprocess ['nodetool', '-h', 'localhost', '-p',
> '7200', 'cleanup'] exited with non-zero status; exit status: 2; stderr:
> error: Node is involved in cluster membership changes. Not safe to run
> cleanup. -- StackTrace -- java.lang.RuntimeException: Node is involved in
> cluster membership changes. Not safe to run cleanup. at
> org.apache.cassandra.service.StorageService.forceKeyspaceCleanup(StorageService.java:4004)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72) 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:262) at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:814)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:802)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1472)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1310)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1405)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> 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 java.base/java.lang.reflect.Method.invoke(Method.java:568) at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
> at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
> at
> java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) self =
> 0x7f7b4db079b0> @flaky(max_runs=1) @pytest.mark.no_vnodes def
> test_move_backwards_and_cleanup(self): """Test moving a node backwards
> without moving past a neighbor token""" move_token =
[cassandra-website] branch asf-staging updated (fda308b4 -> 2cf719cf)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard fda308b4 generate docs for ba5f9001 new 2cf719cf generate docs for ba5f9001 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (fda308b4) \ N -- N -- N refs/heads/asf-staging (2cf719cf) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4881412 -> 4881412 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18048) Test failure: o.a.c.distributed.test.PaxosRepair2Test.legacyPurgeRepairLoop
[
https://issues.apache.org/jira/browse/CASSANDRA-18048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18048:
Summary: Test failure:
o.a.c.distributed.test.PaxosRepair2Test.legacyPurgeRepairLoop (was: fix flaky
o.a.c.distributed.test.PaxosRepair2Test.legacyPurgeRepairLoop)
> Test failure: o.a.c.distributed.test.PaxosRepair2Test.legacyPurgeRepairLoop
> ---
>
> Key: CASSANDRA-18048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18048
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> This test was introduced by CASSANDRA-18029
> {code:java}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$null$12(PaxosRepair2Test.java:528)
> at
> org.apache.cassandra.service.paxos.PaxosState.updateStateUnsafe(PaxosState.java:557)
> at
> org.apache.cassandra.distributed.test.PaxosRepair2Test.lambda$legacyPurgeRepairLoop$1b03105c$1(PaxosRepair2Test.java:522)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748) {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-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.cass
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18747:
Summary: Test failure: Fix assertion error AssertionError: Unknown keyspace
system_auth\n\tat
org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162) (was: Fix
assertion error AssertionError: Unknown keyspace system_auth\n\tat
org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162))
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1666/testReport/junit/dtest.materialized_views_test/TestMaterializedViews/test_gcgs_validation/]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CASSANDRA-18045) Test failure: org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove
[
https://issues.apache.org/jira/browse/CASSANDRA-18045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18045:
Summary: Test failure:
org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove (was:
Fix org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove)
> Test failure:
> org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove
> -
>
> Key: CASSANDRA-18045
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18045
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Flaky tests on trunk, seen
> [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2129/workflows/1d772092-d5dc-4677-8ba8-23fdca42a221/jobs/16705/tests#failed-test-0]
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2645)
> at
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:3020)
> at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2522)
> at
> org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove(LeaveAndBootstrapTest.java:354)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-18641) Test failure: org.apache.cassandra.net.ConnectionTest.testTimeout
[
https://issues.apache.org/jira/browse/CASSANDRA-18641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18641:
Summary: Test failure: org.apache.cassandra.net.ConnectionTest.testTimeout
(was: Fix flaky org.apache.cassandra.net.ConnectionTest.testTimeout)
> Test failure: org.apache.cassandra.net.ConnectionTest.testTimeout
> -
>
> Key: CASSANDRA-18641
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18641
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2404/workflows/df5b69e6-78c0-41fc-9f37-3191a2578f6f/jobs/28590/tests]
> {code:java}
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a org.apache.cassandra.Util sent count values don't match Expected: <1L> but:
> was <3L> within 5 seconds. at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895) at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at org.apache.cassandra.Util.spinAssertEquals(Util.java:691) at
> org.apache.cassandra.net.ConnectionUtils$OutboundCountChecker.lambda$check$0(ConnectionUtils.java:99)
> at
> org.apache.cassandra.net.ConnectionUtils$OutboundCountChecker.doCheck(ConnectionUtils.java:120)
> at
> org.apache.cassandra.net.ConnectionUtils$OutboundCountChecker.check(ConnectionUtils.java:99)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$testTimeout$28(ConnectionTest.java:538)
> at
> org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:246)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:266)
> at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:244) at
> org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:233) at
> org.apache.cassandra.net.ConnectionTest.testTimeout(ConnectionTest.java:507)
> 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)
> Caused by: java.lang.AssertionError: sent count values don't match Expected:
> <1L> but: was <3L> at
> org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at
> org.apache.cassandra.Util.lambda$spinAssertEquals$0(Util.java:691) at
> org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:222)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:209)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833){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
