[jira] [Created] (CASSANDRA-18862) Fix logging / exception output on mismatched cache and schema version
Stefan Miklosovic created CASSANDRA-18862:
-
Summary: Fix logging / exception output on mismatched cache and
schema version
Key: CASSANDRA-18862
URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
Project: Cassandra
Issue Type: Improvement
Components: Local/Caching
Reporter: Stefan Miklosovic
Sometimes I see this in the logs:
{code}
INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
Reading saved cache:
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
Harmless error reading saved cache
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
java.lang.RuntimeException: Cache schema version
e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
f1884cc9-7d66-3b5f-85e5-4bc0d647c885
at
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
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}
Well if the log says it is harmless, why do we need to log the exception? There
is no reason to print that stacktrace, it is just enough to print the
mismatching versions. It should be also changed from INFO to WARN.
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18862:
--
Description:
Sometimes I see this in the logs:
{code}
INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
Reading saved cache:
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
Harmless error reading saved cache
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
java.lang.RuntimeException: Cache schema version
e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
f1884cc9-7d66-3b5f-85e5-4bc0d647c885
at
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
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}
Well if the log says it is harmless, why do we need to log the exception? There
is no reason to print that stacktrace, it is just enough to print the
mismatching versions. It should be also changed from INFO to WARN, or maybe
better to DEBUG? I mean ... it is harmless, right? Why should I see, by
default, that something harmless has happened?
was:
Sometimes I see this in the logs:
{code}
INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
Reading saved cache:
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
Harmless error reading saved cache
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
java.lang.RuntimeException: Cache schema version
e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
f1884cc9-7d66-3b5f-85e5-4bc0d647c885
at
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
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}
Well if the log says it is harmless, why do we need to log the exception? There
is no reason to print that stacktrace, it is just enough to print the
mismatching versions. It should be also changed from INFO to WARN, or maybe
better to DEBUG? I mean ... it is harmless, right?
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Sometimes I see this in the logs:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.ca
[jira] [Updated] (CASSANDRA-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18862:
--
Description:
Sometimes I see this in the logs:
{code}
INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
Reading saved cache:
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
Harmless error reading saved cache
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
java.lang.RuntimeException: Cache schema version
e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
f1884cc9-7d66-3b5f-85e5-4bc0d647c885
at
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
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}
Well if the log says it is harmless, why do we need to log the exception? There
is no reason to print that stacktrace, it is just enough to print the
mismatching versions. It should be also changed from INFO to WARN, or maybe
better to DEBUG? I mean ... it is harmless, right?
was:
Sometimes I see this in the logs:
{code}
INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
Reading saved cache:
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
Harmless error reading saved cache
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
java.lang.RuntimeException: Cache schema version
e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
f1884cc9-7d66-3b5f-85e5-4bc0d647c885
at
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
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}
Well if the log says it is harmless, why do we need to log the exception? There
is no reason to print that stacktrace, it is just enough to print the
mismatching versions. It should be also changed from INFO to WARN.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Sometimes I see this in the logs:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java
[jira] [Updated] (CASSANDRA-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18862:
--
Description:
Sometimes I see this in the logs and Cassandra just continues to start as
nothing happened:
{code}
INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
Reading saved cache:
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
Harmless error reading saved cache
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
java.lang.RuntimeException: Cache schema version
e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
f1884cc9-7d66-3b5f-85e5-4bc0d647c885
at
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
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}
Well if the log says it is harmless, why do we need to log the exception? There
is no reason to print that stacktrace, it is just enough to print the
mismatching versions. It should be also changed from INFO to WARN, or maybe
better to DEBUG? I mean ... it is harmless, right? Why should I see, by
default, that something harmless has happened?
was:
Sometimes I see this in the logs:
{code}
INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
Reading saved cache:
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
Harmless error reading saved cache
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
java.lang.RuntimeException: Cache schema version
e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
f1884cc9-7d66-3b5f-85e5-4bc0d647c885
at
org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
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}
Well if the log says it is harmless, why do we need to log the exception? There
is no reason to print that stacktrace, it is just enough to print the
mismatching versions. It should be also changed from INFO to WARN, or maybe
better to DEBUG? I mean ... it is harmless, right? Why should I see, by
default, that something harmless has happened?
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.Runti
[jira] [Updated] (CASSANDRA-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18853: Test and Documentation Plan: See PR and tested manually (was: See PR) > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766252#comment-17766252 ] Berenguer Blasi commented on CASSANDRA-18853: - Added trunk PR, I'll merge tomorrow to give some time to reviewers but it's identical > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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&focusedCommentId=17766254#comment-17766254
]
Berenguer Blasi commented on CASSANDRA-18792:
-
The sleep in the dtest needs some comment imo. Otherwise it's going to be too
difficult for the reader to understand.
> 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$C
[jira] [Updated] (CASSANDRA-18854) Gossip never recovers from a single failed echo
[ https://issues.apache.org/jira/browse/CASSANDRA-18854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Zemek updated CASSANDRA-18854: -- Attachment: example_echo.log > Gossip never recovers from a single failed echo > --- > > Key: CASSANDRA-18854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18854 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.17, 4.0.12, 4.1.4, 5.0-alpha2, 5.1 > > Attachments: example_echo.log > > > As discovered on CASSANDRA-18792, if an initial echo request is lost, the > node will never be marked up. This appears to be a regression caused by > CASSANDRA-18543. -- 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-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&focusedCommentId=17766258#comment-17766258
]
Stefan Miklosovic commented on CASSANDRA-18781:
---
We should add this (1)
Currently, there is this in logs in Cassandra node:
{code}
ERROR [Stream-Deserializer-/127.0.1.1:7000-f6f5b035] 2023-09-18 08:55:35,683
StreamSession.java:733 - [Stream #5e1599d0-55f0-11ee-ad9c-ed91de66bda5]
Streaming error occurred on session with peer 127.0.1.1:7000 through
127.0.0.1:43704
org.apache.cassandra.db.guardrails.GuardrailViolatedException: Guardrail
bulk_load_enabled violated: Bulk load of SSTables is not allowed. Bulk loading
of SSTables might potentially destabilize the node.
at org.apache.cassandra.db.guardrails.Guardrail.fail(Guardrail.java:143)
at org.apache.cassandra.db.guardrails.Guardrail.fail(Guardrail.java:124)
at
org.apache.cassandra.db.guardrails.EnableFlag.ensureEnabled(EnableFlag.java:126)
at
org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:75)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
INFO [NonPeriodicTasks:1] 2023-09-18 08:55:35,685 StreamResultFuture.java:201
- [Stream #5e1599d0-55f0-11ee-ad9c-ed91de66bda5] Session with /127.0.1.1:7000
is failed
WARN [NonPeriodicTasks:1] 2023-09-18 08:55:35,690 StreamResultFuture.java:250
- [Stream #5e1599d0-55f0-11ee-ad9c-ed91de66bda5] Stream failed:
Session peer /127.0.1.1:7000 Failed because of an unknown exception
org.apache.cassandra.db.guardrails.GuardrailViolatedException: Guardrail
bulk_load_enabled violated: Bulk load of SSTables is not allowed. Bulk loading
of SSTables might potentially destabilize the node.
org.apache.cassandra.db.guardrails.Guardrail.fail(Guardrail.java:143)
org.apache.cassandra.db.guardrails.Guardrail.fail(Guardrail.java:124)
{code}
That is not very user-friendly. We should not propagate exceptions there. That
is just wrong IMHO.
With my suggestion it looks like this:
{code}
INFO [Messaging-EventLoop-3-3] 2023-09-18 09:24:19,552
InboundConnectionInitiator.java:447 -
/127.0.1.1:7000(/127.0.0.1:57364)->localhost/127.0.0.1:7000-STREAMING-58959818
streaming connection established, version = 12, framing = UNPROTECTED,
encryption = unencrypted
INFO [Stream-Deserializer-/127.0.1.1:7000-58959818] 2023-09-18 09:24:19,571
StreamResultFuture.java:123 - [Stream #619d6430-55f4-11ee-b546-b35448f59a3b
ID#0] Creating new streaming plan for Bulk Load from /127.0.1.1:7000
channel.remote /127.0.0.1:57364 channel.local /127.0.0.1:7000 channel.id
58959818
INFO [Stream-Deserializer-/127.0.1.1:7000-58959818] 2023-09-18 09:24:19,571
StreamResultFuture.java:131 - [Stream #619d6430-55f4-11ee-b546-b35448f59a3b,
ID#0] Received streaming plan for Bulk Load from /127.0.1.1:7000 channel.remote
/127.0.0.1:57364 channel.local /127.0.0.1:7000 channel.id 58959818
ERROR [Stream-Deserializer-/127.0.1.1:7000-58959818] 2023-09-18 09:24:19,574
NoSpamLogger.java:111 - Guardrail bulk_load_enabled violated: Bulk load of
SSTables is not allowed. Bulk loading of SSTables might potentially destabilize
the node.
INFO [Stream-Deserializer-/127.0.1.1:7000-58959818] 2023-09-18 09:24:19,576
StreamDeserializingTask.java:88 - [Stream #619d6430-55f4-11ee-b546-b35448f59a3b
channel: 58959818] Aborting StreamInitMessage: from = /127.0.1.1:7000, planId =
619d6430-55f4-11ee-b546-b35448f59a3b, session index = 0. Bulk loading of
SSTables is disabled.
INFO [Stream-Deserializer-/127.0.1.1:7000-58959818] 2023-09-18 09:24:19,576
StreamSession.java:1323 - [Stream #619d6430-55f4-11ee-b546-b35448f59a3b]
Aborting stream session with peer /127.0.1.1:7000...
INFO [NonPeriodicTasks:1] 2023-09-18 09:24:19,577 StreamResultFuture.java:201
- [Stream #619d6430-55f4-11ee-b546-b35448f59a3b] Session with /127.0.1.1:7000
is aborted
INFO [Stream-Deserializer-/127.0.1.1:7000-58959818] 2023-09-18 09:24:19,577
StreamDeserializingTask.java:88 - [Stream #619d6430-55f4-11ee-b546-b35448f59a3b
channel: 58959818] Aborting Prepare SYN (0 requests, 5 files}. Bulk loading of
SSTables is disabled.
INFO [NonPeriodicTasks:1] 2023-09-18 09:24:19,577 StreamResultFuture.java:255
- [Stream #619d6430-55f4-11ee-b546-b35448f59a3b] Stream aborted
{code}
Client's side suffers same problem but I do not think we have easy solution at
hand at the moment because putting any specific exception message into
SessionFailedMessage would not be deserializable (2). It is also questionable
how that would look like in a cluster with mixed versions.
(1)
https://github.com/instaclustr/cassandra/commit/744937b8804af798ea3da7619259cfca394f3ed0
(2)
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/streaming/messages/SessionFailedMessage.java#L30
> Add
[jira] [Updated] (CASSANDRA-18854) Gossip never recovers from a single failed echo
[ https://issues.apache.org/jira/browse/CASSANDRA-18854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Zemek updated CASSANDRA-18854: -- Attachment: (was: example_echo.log) > Gossip never recovers from a single failed echo > --- > > Key: CASSANDRA-18854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18854 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.17, 4.0.12, 4.1.4, 5.0-alpha2, 5.1 > > > As discovered on CASSANDRA-18792, if an initial echo request is lost, the > node will never be marked up. This appears to be a regression caused by > CASSANDRA-18543. -- 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18853: -- Attachment: image-2023-09-18-10-19-15-531.png > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766263#comment-17766263 ] Stefan Miklosovic commented on CASSANDRA-18853: --- !image-2023-09-18-10-19-15-531.png! Should not we mark it errorneous on the highlighted one as well? > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18853: -- Reviewers: Caleb Rackliffe, Stefan Miklosovic (was: Caleb Rackliffe) > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18854) Gossip never recovers from a single failed echo
[ https://issues.apache.org/jira/browse/CASSANDRA-18854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Zemek updated CASSANDRA-18854: -- Attachment: echo.log > Gossip never recovers from a single failed echo > --- > > Key: CASSANDRA-18854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18854 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.17, 4.0.12, 4.1.4, 5.0-alpha2, 5.1 > > Attachments: echo.log > > > As discovered on CASSANDRA-18792, if an initial echo request is lost, the > node will never be marked up. This appears to be a regression caused by > CASSANDRA-18543. -- 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-18854) Gossip never recovers from a single failed echo
[ https://issues.apache.org/jira/browse/CASSANDRA-18854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766265#comment-17766265 ] Cameron Zemek commented on CASSANDRA-18854: --- [^echo.log] i added some logging and I disable networking between two nodes. And then once I re-enable the network it reconnected. So not sure why it breaking those tests. Having said this pre/post those changes there is not retry logic on failed ECHO messages. Pre these changes (and as soon in the logs where it skipped) multiple ECHO messages are sent out. So that probably why the tests work pre these changes as there more ECHOs. > Gossip never recovers from a single failed echo > --- > > Key: CASSANDRA-18854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18854 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.17, 4.0.12, 4.1.4, 5.0-alpha2, 5.1 > > Attachments: echo.log > > > As discovered on CASSANDRA-18792, if an initial echo request is lost, the > node will never be marked up. This appears to be a regression caused by > CASSANDRA-18543. -- 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766276#comment-17766276 ] Stefan Miklosovic commented on CASSANDRA-18853: --- Thinking about that one more ... unless there is a corresponding checkstyle rule we should not enable that. Because if there is not such rule, we error it in IDE but not in checkstyle and I do not like this discrepancy. > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18862:
--
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 5.x
Assignee: Stefan Miklosovic
Status: Open (was: Triage Needed)
https://github.com/apache/cassandra/pull/2697
This should go to 5.0 and trunk. The PR is for trunk. 5.0 patch is same.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18862:
--
Test and Documentation Plan: CI
Status: Patch Available (was: Open)
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18863) Some tests are depending on each other
Stefan Miklosovic created CASSANDRA-18863:
-
Summary: Some tests are depending on each other
Key: CASSANDRA-18863
URL: https://issues.apache.org/jira/browse/CASSANDRA-18863
Project: Cassandra
Issue Type: Improvement
Components: Test/unit
Reporter: Stefan Miklosovic
I noticed this first when dealing with (1)
Simple bash gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done./org/apache/cassandra/db/ColumnFamilyStoreTest.java
import org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.compaction.CompactionsTest;
./org/apache/cassandra/fql/FullQueryLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/index/sai/cql/InetAddressTypeEquivalencyTest.java import
org.apache.cassandra.index.sai.cql.types.InetTest;
./org/apache/cassandra/io/compress/CompressedSequentialWriterTest.java import
org.apache.cassandra.io.util.SequentialWriterTest;
./org/apache/cassandra/io/sstable/LegacySSTableTest.java import
org.apache.cassandra.db.SinglePartitionSliceCommandTest;
./org/apache/cassandra/audit/BinAuditLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/cql3/validation/operations/CompactStorageSplit1Test.java
import org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest; {code}
If one goes one by one, there are some cases when one test is trully depending
on another. I do not think this is a good practice at all. Each test should be
self-contained or at least all common parts which are reused should be
extracted to some helper classes. As it is done right now, if one changes the
implementation of some helper methods in on test, it might fail others. If it
is extracted, it is more probable that a developer would check where that
method is used additionally to the place a developer is focused on. Right now
if a developer changes a method in a test that method is specified in, she does
not have a clue that it might be used somewhere else.
--
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-18863) Some tests are depending on each other
[
https://issues.apache.org/jira/browse/CASSANDRA-18863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18863:
--
Description:
I noticed this first when dealing with (1)
Simple bash gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done./org/apache/cassandra/db/ColumnFamilyStoreTest.java
import org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.compaction.CompactionsTest;
./org/apache/cassandra/fql/FullQueryLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/index/sai/cql/InetAddressTypeEquivalencyTest.java import
org.apache.cassandra.index.sai.cql.types.InetTest;
./org/apache/cassandra/io/compress/CompressedSequentialWriterTest.java import
org.apache.cassandra.io.util.SequentialWriterTest;
./org/apache/cassandra/io/sstable/LegacySSTableTest.java import
org.apache.cassandra.db.SinglePartitionSliceCommandTest;
./org/apache/cassandra/audit/BinAuditLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/cql3/validation/operations/CompactStorageSplit1Test.java
import org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest; {code}
If one goes one by one, there are some cases when one test is trully depending
on another. I do not think this is a good practice at all. Each test should be
self-contained or at least all common parts which are reused should be
extracted to some helper classes. As it is done right now, if one changes the
implementation of some helper methods in on test, it might fail others. If it
is extracted, it is more probable that a developer would check where that
method is used additionally to the place a developer is focused on. Right now
if a developer changes a method in a test that method is specified in, she does
not have a clue that it might be used somewhere else.
(1)
https://issues.apache.org/jira/browse/CASSANDRA-18824?focusedCommentId=17763155&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17763155
was:
I noticed this first when dealing with (1)
Simple bash gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done./org/apache/cassandra/db/ColumnFamilyStoreTest.java
import org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.compaction.CompactionsTest;
./org/apache/cassandra/fql/FullQueryLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/index/sai/cql/InetAddressTypeEquivalencyTest.java import
org.apache.cassandra.index.sai.cql.types.InetTest;
./org/apache/cassandra/io/compress/CompressedSequentialWriterTest.java import
org.apache.cassandr
[jira] [Updated] (CASSANDRA-18863) Some tests are depending on each other
[
https://issues.apache.org/jira/browse/CASSANDRA-18863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18863:
--
Description:
I noticed this first when dealing with (1)
Simple bash gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi;
donedone./org/apache/cassandra/db/ColumnFamilyStoreTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.compaction.CompactionsTest;
./org/apache/cassandra/fql/FullQueryLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/index/sai/cql/InetAddressTypeEquivalencyTest.java import
org.apache.cassandra.index.sai.cql.types.InetTest;
./org/apache/cassandra/io/compress/CompressedSequentialWriterTest.java import
org.apache.cassandra.io.util.SequentialWriterTest;
./org/apache/cassandra/io/sstable/LegacySSTableTest.java import
org.apache.cassandra.db.SinglePartitionSliceCommandTest;
./org/apache/cassandra/audit/BinAuditLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/cql3/validation/operations/CompactStorageSplit1Test.java
import org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest; {code}
If one goes one by one, there are some cases when one test is trully depending
on another. I do not think this is a good practice at all. Each test should be
self-contained or at least all common parts which are reused should be
extracted to some helper classes. As it is done right now, if one changes the
implementation of some helper methods in on test, it might fail others. If it
is extracted, it is more probable that a developer would check where that
method is used additionally to the place a developer is focused on. Right now
if a developer changes a method in a test that method is specified in, she does
not have a clue that it might be used somewhere else.
(1)
https://issues.apache.org/jira/browse/CASSANDRA-18824?focusedCommentId=17763155&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17763155
was:
I noticed this first when dealing with (1)
Simple bash gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done./org/apache/cassandra/db/ColumnFamilyStoreTest.java
import org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.compaction.CompactionsTest;
./org/apache/cassandra/fql/FullQueryLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/index/sai/cql/InetAddressTypeEquivalencyTest.java import
org.apache.cassandra.index.sai.cql.types.InetTest;
./org/apache/cassandra/io/compress/CompressedSequentialWriterTest.java import
org.apache.cas
[jira] [Updated] (CASSANDRA-18863) Some tests are depending on each other
[
https://issues.apache.org/jira/browse/CASSANDRA-18863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18863:
--
Description:
I noticed this first when dealing with (1)
Simple bash gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done
./org/apache/cassandra/db/ColumnFamilyStoreTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.compaction.CompactionsTest;
./org/apache/cassandra/fql/FullQueryLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/index/sai/cql/InetAddressTypeEquivalencyTest.java import
org.apache.cassandra.index.sai.cql.types.InetTest;
./org/apache/cassandra/io/compress/CompressedSequentialWriterTest.java import
org.apache.cassandra.io.util.SequentialWriterTest;
./org/apache/cassandra/io/sstable/LegacySSTableTest.java import
org.apache.cassandra.db.SinglePartitionSliceCommandTest;
./org/apache/cassandra/audit/BinAuditLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/cql3/validation/operations/CompactStorageSplit1Test.java
import org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest; {code}
If one goes one by one, there are some cases when one test is trully depending
on another. I do not think this is a good practice at all. Each test should be
self-contained or at least all common parts which are reused should be
extracted to some helper classes. As it is done right now, if one changes the
implementation of some helper methods in on test, it might fail others. If it
is extracted, it is more probable that a developer would check where that
method is used additionally to the place a developer is focused on. Right now
if a developer changes a method in a test that method is specified in, she does
not have a clue that it might be used somewhere else.
(1)
https://issues.apache.org/jira/browse/CASSANDRA-18824?focusedCommentId=17763155&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17763155
was:
I noticed this first when dealing with (1)
Simple bash gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi;
donedone./org/apache/cassandra/db/ColumnFamilyStoreTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.compaction.CompactionsTest;
./org/apache/cassandra/fql/FullQueryLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/index/sai/cql/InetAddressTypeEquivalencyTest.java import
org.apache.cassandra.index.sai.cql.types.InetTest;
./org/apache/cassandra/io/compress/CompressedSequentialWriterTest.java import
org.apache.ca
[jira] [Updated] (CASSANDRA-18863) Some tests are depending on each other
[
https://issues.apache.org/jira/browse/CASSANDRA-18863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18863:
--
Description:
I noticed this first when dealing with (1)
Simple bash for unit tests gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done
./org/apache/cassandra/db/ColumnFamilyStoreTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.compaction.CompactionsTest;
./org/apache/cassandra/fql/FullQueryLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/index/sai/cql/InetAddressTypeEquivalencyTest.java import
org.apache.cassandra.index.sai.cql.types.InetTest;
./org/apache/cassandra/io/compress/CompressedSequentialWriterTest.java import
org.apache.cassandra.io.util.SequentialWriterTest;
./org/apache/cassandra/io/sstable/LegacySSTableTest.java import
org.apache.cassandra.db.SinglePartitionSliceCommandTest;
./org/apache/cassandra/audit/BinAuditLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/cql3/validation/operations/CompactStorageSplit1Test.java
import org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest; {code}
in-jvm-dtests:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done
./org/apache/cassandra/distributed/test/ring/BootstrapTest.java import
org.apache.cassandra.distributed.test.DecommissionTest; {code}
If one goes one by one, there are some cases when one test is trully depending
on another. I do not think this is a good practice at all. Each test should be
self-contained or at least all common parts which are reused should be
extracted to some helper classes. As it is done right now, if one changes the
implementation of some helper methods in on test, it might fail others. If it
is extracted, it is more probable that a developer would check where that
method is used additionally to the place a developer is focused on. Right now
if a developer changes a method in a test that method is specified in, she does
not have a clue that it might be used somewhere else.
(1)
https://issues.apache.org/jira/browse/CASSANDRA-18824?focusedCommentId=17763155&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17763155
was:
I noticed this first when dealing with (1)
Simple bash gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done
./org/apache/cassandra/db/ColumnFamilyStoreTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.
[jira] [Updated] (CASSANDRA-18863) Some tests are depending on each other
[
https://issues.apache.org/jira/browse/CASSANDRA-18863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18863:
--
Description:
I noticed this first when dealing with (1)
Simple bash for unit tests gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done
./org/apache/cassandra/db/ColumnFamilyStoreTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apache.cassandra.db.compaction.CompactionsTest;
./org/apache/cassandra/fql/FullQueryLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/index/sai/cql/InetAddressTypeEquivalencyTest.java import
org.apache.cassandra.index.sai.cql.types.InetTest;
./org/apache/cassandra/io/compress/CompressedSequentialWriterTest.java import
org.apache.cassandra.io.util.SequentialWriterTest;
./org/apache/cassandra/io/sstable/LegacySSTableTest.java import
org.apache.cassandra.db.SinglePartitionSliceCommandTest;
./org/apache/cassandra/audit/BinAuditLoggerTest.java import
org.apache.cassandra.utils.binlog.BinLogTest;
./org/apache/cassandra/cql3/validation/operations/CompactStorageSplit1Test.java
import org.apache.cassandra.cql3.validation.entities.SecondaryIndexTest; {code}
in-jvm-dtests:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done
./org/apache/cassandra/distributed/test/ring/BootstrapTest.java import
org.apache.cassandra.distributed.test.DecommissionTest; {code}
If one goes one by one, there are some cases when one test is truly depending
on another. I do not think this is a good practice at all. Each test should be
self-contained or at least all common parts which are reused should be
extracted to some helper classes. As it is done right now, if one changes the
implementation of some helper methods in one test, it might fail others. If it
is extracted, it is more probable that a developer would check where that
method is used additionally to the place a developer is focused on. Right now
if a developer changes a method in a test that method is specified in, she does
not have a clue that it might be used somewhere else.
(1)
https://issues.apache.org/jira/browse/CASSANDRA-18824?focusedCommentId=17763155&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17763155
was:
I noticed this first when dealing with (1)
Simple bash for unit tests gives:
{code:java}
for i in $(find . -type f -name '*Test.java'); do imports=$(grep 'import
org.apache.*Test;' $i | grep -v 'Abstract'); if [ x"$imports" != "x" ]; then
echo $i $imports; fi; done
./org/apache/cassandra/db/ColumnFamilyStoreTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/db/compaction/CompactionsCQLTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/db/compaction/PartialCompactionsTest.java import
org.apache.cassandra.db.DirectoriesTest;
./org/apache/cassandra/locator/ReconnectableSnitchHelperTest.java import
org.apache.cassandra.net.MessagingServiceTest;
./org/apache/cassandra/tools/nodetool/ScrubToolTest.java import
org.apache.cassandra.io.sstable.ScrubTest;
./org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java import
org.apache.cassandra.io.sstable.LegacySSTableTest;
./org/apache/cassandra/tools/StandaloneVerifierTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/tools/StandaloneVerifierOnSSTablesTest.java import
org.apache.cassandra.io.sstable.VerifyTest;
./org/apache/cassandra/repair/asymmetric/DifferenceHolderTest.java import
org.apache.cassandra.utils.MerkleTreesTest;
./org/apache/cassandra/repair/ValidatorTest.java import
org.apach
[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&focusedCommentId=17766325#comment-17766325 ] Brandon Williams commented on CASSANDRA-18844: -- bq. if somebody has openjdk-21 installed already, it would evaluate it as a valid runtime but it is not. As Jackson pointed out this has been a theoretical problem for a long time. But in practice, this never happens so we don't need to worry about it. > 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] [Updated] (CASSANDRA-18737) Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest (testLoadingIncompleteSSTable-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18737:
--
Reviewers: Branimir Lambov (was: Branimir Lambov, Jacek Lewandowski)
> Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest
> (testLoadingIncompleteSSTable-.jdk17)
> -
>
> Key: CASSANDRA-18737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18737
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.RuntimeException: Failed to list files in
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:77)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:626)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:103)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:202)
> at
> org.apache.cassandra.io.sstable.SSTableLoaderTest.testLoadingIncompleteSSTable(SSTableLoaderTest.java:213)
> 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: org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5/nc-17-big
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:373)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$0(SSTableLoader.java:152)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$2(LogAwareFileLister.java:99)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178)
> at
> java.base/java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:3287)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:101)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:73)
> Caused by: java.lang.NullPointerException
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:903)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.buildSummaryAndBloomFilter(BigSSTableReaderLoadingBuilder.java:193)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.openComponents(BigSSTableReaderLoadingBuilder.java:116)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.openComponents(BigSSTableReaderLoadingBuilder.java:58)
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:92)
> {noformat}
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1174/workflows/263f1e22-e4d0-48b8-b3e2-496edb30a068/jobs/41924/tests
--
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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766357#comment-17766357 ] Maxim Muzafarov commented on CASSANDRA-18853: - +1 tested locally, imported the configuration from scratch and checked unused imports. [~smiklosovic] the checkstyle for unused imports is enabled, did you mean something else? https://github.com/apache/cassandra/blob/trunk/.build/checkstyle.xml#L173 > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18864) CIDR permission cache probably does not work
Jacek Lewandowski created CASSANDRA-18864:
-
Summary: CIDR permission cache probably does not work
Key: CASSANDRA-18864
URL: https://issues.apache.org/jira/browse/CASSANDRA-18864
Project: Cassandra
Issue Type: Bug
Reporter: Jacek Lewandowski
CIDR permission cache code:
{code:java}
/**
* Invalidate a role from CIDR permissions cache
* @param roleName role for which to invalidate the cache
* @return boolean returns true if given role found in the cache and
invalidated, otherwise returns false
*/
public boolean invalidateCidrPermissions(String roleName)
{
if (cache.getIfPresent(roleName) == null)
return false;
invalidate(RoleResource.role(roleName));
return true;
}
{code}
passes {{String}} role name to the cache and if it returns {{null}} it just
returns {{false}}. It will always return {{null}} because cache expects objects
of type {{RoleResource}}.
--
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-18864) CIDR permission cache probably does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-18864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18864:
--
Bug Category: Parent values: Correctness(12982)Level 1 values:
Consistency(12989)
Complexity: Low Hanging Fruit
Discovered By: Code Inspection
Severity: Normal
Since Version: 5.0-alpha1
> CIDR permission cache probably does not work
>
>
> Key: CASSANDRA-18864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18864
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> CIDR permission cache code:
> {code:java}
> /**
> * Invalidate a role from CIDR permissions cache
> * @param roleName role for which to invalidate the cache
> * @return boolean returns true if given role found in the cache and
> invalidated, otherwise returns false
> */
> public boolean invalidateCidrPermissions(String roleName)
> {
> if (cache.getIfPresent(roleName) == null)
> return false;
> invalidate(RoleResource.role(roleName));
> return true;
> }
> {code}
> passes {{String}} role name to the cache and if it returns {{null}} it just
> returns {{false}}. It will always return {{null}} because cache expects
> objects of type {{RoleResource}}.
--
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-18864) CIDR permission cache probably does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-18864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766366#comment-17766366
]
Ekaterina Dimitrova commented on CASSANDRA-18864:
-
CASSANDRA-18805 - the issue was caught there during the upgrade of caffeine
cache. There is a fix about to be committed soon, together with improved
testing.
Closing as duplicate
> CIDR permission cache probably does not work
>
>
> Key: CASSANDRA-18864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18864
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> CIDR permission cache code:
> {code:java}
> /**
> * Invalidate a role from CIDR permissions cache
> * @param roleName role for which to invalidate the cache
> * @return boolean returns true if given role found in the cache and
> invalidated, otherwise returns false
> */
> public boolean invalidateCidrPermissions(String roleName)
> {
> if (cache.getIfPresent(roleName) == null)
> return false;
> invalidate(RoleResource.role(roleName));
> return true;
> }
> {code}
> passes {{String}} role name to the cache and if it returns {{null}} it just
> returns {{false}}. It will always return {{null}} because cache expects
> objects of type {{RoleResource}}.
--
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-18864) CIDR permission cache probably does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-18864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18864:
Resolution: Duplicate
Status: Resolved (was: Triage Needed)
> CIDR permission cache probably does not work
>
>
> Key: CASSANDRA-18864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18864
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jacek Lewandowski
>Priority: Normal
>
> CIDR permission cache code:
> {code:java}
> /**
> * Invalidate a role from CIDR permissions cache
> * @param roleName role for which to invalidate the cache
> * @return boolean returns true if given role found in the cache and
> invalidated, otherwise returns false
> */
> public boolean invalidateCidrPermissions(String roleName)
> {
> if (cache.getIfPresent(roleName) == null)
> return false;
> invalidate(RoleResource.role(roleName));
> return true;
> }
> {code}
> passes {{String}} role name to the cache and if it returns {{null}} it just
> returns {{false}}. It will always return {{null}} because cache expects
> objects of type {{RoleResource}}.
--
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-18854) Gossip never recovers from a single failed echo
[ https://issues.apache.org/jira/browse/CASSANDRA-18854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766372#comment-17766372 ] Brandon Williams commented on CASSANDRA-18854: -- bq. does the change to `waitToSettle` need to be reverted here? Given that this regression could have easily been missed or dismissed as simply being environmental noise causing ~1% timeouts, the safest thing to do is revert the entire commit in case there have been more hard to spot bugs introduced. > Gossip never recovers from a single failed echo > --- > > Key: CASSANDRA-18854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18854 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.17, 4.0.12, 4.1.4, 5.0-alpha2, 5.1 > > Attachments: echo.log > > > As discovered on CASSANDRA-18792, if an initial echo request is lost, the > node will never be marked up. This appears to be a regression caused by > CASSANDRA-18543. -- 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&focusedCommentId=17766374#comment-17766374
]
Brandon Williams commented on CASSANDRA-18792:
--
Agreed, I will add that on commit if the rest is good.
> 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
> jav
[jira] [Commented] (CASSANDRA-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766376#comment-17766376
]
Brandon Williams commented on CASSANDRA-18862:
--
bq. INFO to WARN, or maybe better to DEBUG? I mean ... it is harmless, right?
Heh, do you want to upgrade the log priority or downgrade it? That said I
think it's fine at INFO, though I agree with removing the stacktrace. It's
harmless but if it's happening all the time or if there is a cause I don't
understand, as an operator I'd still like to be aware it happened since it's
not a regularly occurring event.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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&focusedCommentId=17766377#comment-17766377 ] Brandon Williams commented on CASSANDRA-18844: -- bq. Cassandra on Debian is forced to run with openjdk Do we even need to reference openjdk directly? Can we just do 'javaXX-runtime'? > 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766378#comment-17766378 ] Stefan Miklosovic commented on CASSANDRA-18853: --- Yes. The case I want to explore is imports which are not necessary to import because they are in same package. E.g. I have a package a.b.c and there is a class D and E. If we use D in E, since it is in same package, we do not need to import D. The question is if we want to mark such import as unnecessary hence erroneous. Why do we need to import it when it is already available without doing so? > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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&focusedCommentId=17766383#comment-17766383 ] Maxim Muzafarov commented on CASSANDRA-14667: - Tested on latest changes tests that were previously failed. https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/355/workflows/f4ff68a6-daf4-43ec-b12f-7b25f6582e5a/jobs/26762 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/355/workflows/f4ff68a6-daf4-43ec-b12f-7b25f6582e5a/jobs/26758 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/355/workflows/f4ff68a6-daf4-43ec-b12f-7b25f6582e5a/jobs/26759 I have no technical arguments for choosing one option over the other. For me, it will be better to fix the transitive dependency resolver process when an error occurs than to exclude dependencies in advance. However, since we already have such an example of exclusion in the source code we can include a similar one for these changes. [~smiklosovic] are you OK with it taking into account the last comments or do you still think the exclusion is a blocker for the patch itself? > 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] [Commented] (CASSANDRA-18813) Simplify the bind marker and Term logic
[
https://issues.apache.org/jira/browse/CASSANDRA-18813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766385#comment-17766385
]
Ekaterina Dimitrova commented on CASSANDRA-18813:
-
The correct CI links are these, confirmed with [~blerer]:
[Java11|https://app.circleci.com/pipelines/github/blerer/cassandra/359/workflows/8a5c3201-3b8e-4c45-b953-f06860ed925e]
*org.apache.cassandra.distributed.test.FailingRepairTest-.jdk11* - I did not
find a ticket for this one, but I've seen something similar. Let's loop it on
the current trunk and open another ticket when it confirms it is unrelated to
what we do here.
*testDropListAndAddListWithSameName-.jdk11* - CASSANDRA-18360
I would also recommend running the upgrade tests before committing.
I am still reviewing it, though.
> Simplify the bind marker and Term logic
> ---
>
> Key: CASSANDRA-18813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18813
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The current logic around {{Term}} and {{Terms}} classes is confusing
> specially with {{MultiItemTerminal}} and {{MultiColumnRaw}} that are used to
> handle different use cases that could be handled simply with the {{Term}}
> interface.
> On top of that IN marker add to the confusion because the are represented as
> single Term where in practice they are a set of terms. Representing them as a
> {{Terms}} could simplify the way we handle IN restrictions.
> The goal of this ticket is:
> * to refactor the {{Term}} and {{Terms}} interfaces to simplify the logic
> * Represents IN bind marker as {{Terms}} instead of having 2 different
> representations (a list of terms and a single {{MultiItemTerminal}}.
> * Simplify the {{AbstractMarker}} hierachy
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766390#comment-17766390
]
Stefan Miklosovic commented on CASSANDRA-18862:
---
I dont know :D I would probably downgrade it. If it is harmless it has nothing
to do with INFO.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766390#comment-17766390
]
Stefan Miklosovic edited comment on CASSANDRA-18862 at 9/18/23 1:55 PM:
I dont know :D I would probably downgrade it to DEBUG. If it is harmless it has
nothing to do with INFO.
was (Author: smiklosovic):
I dont know :D I would probably downgrade it. If it is harmless it has nothing
to do with INFO.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766390#comment-17766390
]
Stefan Miklosovic edited comment on CASSANDRA-18862 at 9/18/23 1:56 PM:
I dont know :D I would probably downgrade it to DEBUG. If it is harmless it has
nothing to do with INFO.
If it stays on INFO, what is the action I could take? Probably just nothing ...
or remove the dir with saved_caches and start again?
was (Author: smiklosovic):
I dont know :D I would probably downgrade it to DEBUG. If it is harmless it has
nothing to do with INFO.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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&focusedCommentId=17766393#comment-17766393
]
Stefan Miklosovic commented on CASSANDRA-18844:
---
We can not do that because javaXX-runtime is so called "virtual package". If
you do "apt install java17-runtime" it errors:
{code:java}
$ docker run -it -u root debian:bookworm
root@78bc1b3cc96d:/# apt update
Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
Get:2 http://deb.debian.org/debian bookworm-updates InRelease [52.1 kB]
Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0
kB]
Get:4 http://deb.debian.org/debian bookworm/main amd64 Packages [8906 kB]
Get:5 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [6432 B]
Get:6 http://deb.debian.org/debian-security bookworm-security/main amd64
Packages [62.1 kB]
Fetched 9226 kB in 1s (12.1 MB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@78bc1b3cc96d:/# apt install java17-runtime
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package java17-runtime is a virtual package provided by:
openjdk-17-jre 17.0.8+7-1~deb12u1
default-jre 2:1.17-74
You should explicitly select one to install.E: Package 'java17-runtime' has no
installation candidate
root@78bc1b3cc96d:/#
{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&focusedCommentId=17766393#comment-17766393
]
Stefan Miklosovic edited comment on CASSANDRA-18844 at 9/18/23 2:03 PM:
We can not do that because javaXX-runtime is so called "virtual package". If
you do "apt install java17-runtime" it errors:
{code:java}
$ docker run -it -u root debian:bookworm
root@78bc1b3cc96d:/# apt update
Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
Get:2 http://deb.debian.org/debian bookworm-updates InRelease [52.1 kB]
Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0
kB]
Get:4 http://deb.debian.org/debian bookworm/main amd64 Packages [8906 kB]
Get:5 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [6432 B]
Get:6 http://deb.debian.org/debian-security bookworm-security/main amd64
Packages [62.1 kB]
Fetched 9226 kB in 1s (12.1 MB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@78bc1b3cc96d:/# apt install java17-runtime
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package java17-runtime is a virtual package provided by:
openjdk-17-jre 17.0.8+7-1~deb12u1
default-jre 2:1.17-74
You should explicitly select one to install.E: Package 'java17-runtime' has no
installation candidate
root@78bc1b3cc96d:/#
{code}
In other words, we can not install them. But the packages which are installable
can provide / satisfy them.
was (Author: smiklosovic):
We can not do that because javaXX-runtime is so called "virtual package". If
you do "apt install java17-runtime" it errors:
{code:java}
$ docker run -it -u root debian:bookworm
root@78bc1b3cc96d:/# apt update
Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
Get:2 http://deb.debian.org/debian bookworm-updates InRelease [52.1 kB]
Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0
kB]
Get:4 http://deb.debian.org/debian bookworm/main amd64 Packages [8906 kB]
Get:5 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [6432 B]
Get:6 http://deb.debian.org/debian-security bookworm-security/main amd64
Packages [62.1 kB]
Fetched 9226 kB in 1s (12.1 MB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@78bc1b3cc96d:/# apt install java17-runtime
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package java17-runtime is a virtual package provided by:
openjdk-17-jre 17.0.8+7-1~deb12u1
default-jre 2:1.17-74
You should explicitly select one to install.E: Package 'java17-runtime' has no
installation candidate
root@78bc1b3cc96d:/#
{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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766394#comment-17766394
]
Brandon Williams commented on CASSANDRA-18862:
--
If it's happening regularly it could be a sign of a greater problem - it may be
getting corrupted.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18856) Test failure: rebuild_test.TestRebuild.test_resumable_rebuild
[
https://issues.apache.org/jira/browse/CASSANDRA-18856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-18856:
Assignee: Brandon Williams
> Test failure: rebuild_test.TestRebuild.test_resumable_rebuild
> -
>
> Key: CASSANDRA-18856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18856
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> https://app.circleci.com/pipelines/github/driftx/cassandra/1294/workflows/04464235-3bcf-433e-ae81-206aa2c9c874/jobs/54042/tests
> {quote}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node3] 'ERROR
> [Stream-Deserializer-/127.0.0.2:7000-d94b6b54] 2023-09-15 16:04:30,685
> CassandraEntireSSTableStreamReader.java:146 - [Stream
> 8d7c61b0-53e1-11ee-a721-a91a3065a930] Error while reading sstable from stream
> for table = ks.cf\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:139)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.write(SSTableZeroCopyWriter.java:218)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.writeComponent(SSTableZeroCopyWriter.java:207)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:124)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:87)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:50)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)\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:833)', [node3] 'ERROR
> [Stream-Deserializer-/127.0.0.2:7000-6f7e3946] 2023-09-15 16:04:30,687
> CassandraEntireSSTableStreamReader.java:146 - [Stream
> 8d7c61b0-53e1-11ee-a721-a91a3065a930] Error while reading sstable from stream
> for table = ks.cf\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:139)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.write(SSTableZeroCopyWriter.java:218)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.writeComponent(SSTableZeroCopyWriter.java:207)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:124)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:87)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:50)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)\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:833)']"
> {quote}
> This is probably similar to CASSANDRA-18815
--
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&focusedCommentId=17766393#comment-17766393
]
Stefan Miklosovic edited comment on CASSANDRA-18844 at 9/18/23 2:05 PM:
We can not do that because javaXX-runtime is so called "virtual package". If
you do "apt install java17-runtime" it errors:
{code:java}
$ docker run -it -u root debian:bookworm
root@78bc1b3cc96d:/# apt update
Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
Get:2 http://deb.debian.org/debian bookworm-updates InRelease [52.1 kB]
Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0
kB]
Get:4 http://deb.debian.org/debian bookworm/main amd64 Packages [8906 kB]
Get:5 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [6432 B]
Get:6 http://deb.debian.org/debian-security bookworm-security/main amd64
Packages [62.1 kB]
Fetched 9226 kB in 1s (12.1 MB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@78bc1b3cc96d:/# apt install java17-runtime
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package java17-runtime is a virtual package provided by:
openjdk-17-jre 17.0.8+7-1~deb12u1
default-jre 2:1.17-74
You should explicitly select one to install.E: Package 'java17-runtime' has no
installation candidate
root@78bc1b3cc96d:/#
{code}
In other words, we can not install them. But the packages which are installable
can provide / satisfy them.
If we used it, we would basically require users to install some Java on their
own. The benefit of the suggested change is that if there is no Java
installation at all on the machine, it will install openjdk17/11 automatically
along with Cassandra itself.
was (Author: smiklosovic):
We can not do that because javaXX-runtime is so called "virtual package". If
you do "apt install java17-runtime" it errors:
{code:java}
$ docker run -it -u root debian:bookworm
root@78bc1b3cc96d:/# apt update
Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
Get:2 http://deb.debian.org/debian bookworm-updates InRelease [52.1 kB]
Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0
kB]
Get:4 http://deb.debian.org/debian bookworm/main amd64 Packages [8906 kB]
Get:5 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [6432 B]
Get:6 http://deb.debian.org/debian-security bookworm-security/main amd64
Packages [62.1 kB]
Fetched 9226 kB in 1s (12.1 MB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@78bc1b3cc96d:/# apt install java17-runtime
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package java17-runtime is a virtual package provided by:
openjdk-17-jre 17.0.8+7-1~deb12u1
default-jre 2:1.17-74
You should explicitly select one to install.E: Package 'java17-runtime' has no
installation candidate
root@78bc1b3cc96d:/#
{code}
In other words, we can not install them. But the packages which are installable
can provide / satisfy them.
> 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&focusedCommentId=17766396#comment-17766396 ] Brandon Williams commented on CASSANDRA-18844: -- In that case I agree with your previous suggestions for 11 and 17, and we can ignore 21. > 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766399#comment-17766399 ] Berenguer Blasi commented on CASSANDRA-18853: - I'd suggest you open a new ticket if you want to explore that, how to tie it with checkstyle etc. > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766404#comment-17766404
]
Stefan Miklosovic commented on CASSANDRA-18862:
---
I will keep an eye on this. I can not reproduce it easily.
OK so we can keep it on INFO. Do you need the builds for this?
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766407#comment-17766407
]
Brandon Williams commented on CASSANDRA-18862:
--
Nah, I think it's fine without building.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766406#comment-17766406 ] Stefan Miklosovic commented on CASSANDRA-18853: --- OK. +1 then. > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766408#comment-17766408
]
Brandon Williams commented on CASSANDRA-18862:
--
bq. I can not reproduce it easily.
Just manually corrupt your cache.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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&focusedCommentId=17766413#comment-17766413
]
Berenguer Blasi commented on CASSANDRA-18792:
-
Th rest LGTM
> 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
> java.rmi/sun.rmi.transport.tcp.TCPTransport$Con
[jira] [Commented] (CASSANDRA-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766418#comment-17766418
]
Stefan Miklosovic commented on CASSANDRA-18862:
---
There are no files in saved_cache directory when I run Cassandra from IDEA,
after I create keyspace, table, put there some data, selecting some entries by
key ... I was looking for a way how to "flush" a key cache locally but there is
only some periodic saving by the means of key_cache_save_period or respective
nodetool setcachekeystosave method. Nothing produced any file in saved_caches
though.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766418#comment-17766418
]
Stefan Miklosovic edited comment on CASSANDRA-18862 at 9/18/23 2:48 PM:
There are no files in saved_cache directory when I run Cassandra from IDEA,
after I create keyspace, table, put there some data, selecting some entries by
key ... I was looking for a way how to "flush" a key cache locally but there is
only some periodic saving by the means of key_cache_save_period or respective
nodetool setcachekeystosave method. Nothing produced any file in saved_caches
though.
I think it might happen when there is a cache file saved, I stopped a node,
remove everything from "data" dir (all tables) and I start that node again. On
startup, it would generate a different schema id from the one in saved_caches.
was (Author: smiklosovic):
There are no files in saved_cache directory when I run Cassandra from IDEA,
after I create keyspace, table, put there some data, selecting some entries by
key ... I was looking for a way how to "flush" a key cache locally but there is
only some periodic saving by the means of key_cache_save_period or respective
nodetool setcachekeystosave method. Nothing produced any file in saved_caches
though.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766424#comment-17766424
]
Stefan Miklosovic commented on CASSANDRA-18862:
---
Ah yes, that was exactly the case in my example. To get the files, I just
lowered key_cache_save_period to 10s and did few selects. After deletion of
everything in data dir for tables starting the node again, it will log it.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766424#comment-17766424
]
Stefan Miklosovic edited comment on CASSANDRA-18862 at 9/18/23 2:56 PM:
Ah yes, that was exactly the case in my example. To get the files, I just
lowered key_cache_save_period to 10s and did few selects. After the deletion of
everything in data dir for tables and starting the node again, it will log it.
was (Author: smiklosovic):
Ah yes, that was exactly the case in my example. To get the files, I just
lowered key_cache_save_period to 10s and did few selects. After deletion of
everything in data dir for tables starting the node again, it will log it.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: tiny sleep for streaming session to finish on remote also clean up print statements
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 39a6c79b tiny sleep for streaming session to finish on remote also
clean up print statements
39a6c79b is described below
commit 39a6c79bbd9e20435db8114c20d64f20942bd4f3
Author: Brandon Williams
AuthorDate: Tue Sep 12 10:16:27 2023 -0500
tiny sleep for streaming session to finish on remote
also clean up print statements
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18792
---
transient_replication_ring_test.py | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/transient_replication_ring_test.py
b/transient_replication_ring_test.py
index 47e68e01..e3cac64e 100644
--- a/transient_replication_ring_test.py
+++ b/transient_replication_ring_test.py
@@ -1,5 +1,6 @@
import logging
import types
+import time
from cassandra import ConsistencyLevel
from cassandra.query import SimpleStatement
@@ -19,7 +20,8 @@ from tools.misc import new_node
since = pytest.mark.since
-logging.getLogger('cassandra').setLevel(logging.CRITICAL)
+logger = logging.getLogger(__name__)
+
NODELOCAL = 11
@@ -40,6 +42,7 @@ def repair_nodes(nodes):
def cleanup_nodes(nodes):
for node in nodes:
+logger.debug("cleaning up %s" % node)
node.nodetool('cleanup')
@@ -77,8 +80,8 @@ class TestTransientReplicationRing(Tester):
if node is None:
node = list(range(1000))
for idx, session, expect, node in zip(range(0, 1000), sessions,
expected, node):
-print("Checking idx " + str(idx))
-print(str([row for row in
session.execute(self.select_statement())]))
+logger.debug("Checking idx " + str(idx))
+logger.debug(str([row for row in
session.execute(self.select_statement())]))
if cleanup:
node.nodetool('cleanup')
assert_all(session,
@@ -114,8 +117,8 @@ class TestTransientReplicationRing(Tester):
'commitlog_sync_period_in_ms': 500,
'enable_transient_replication': True,
'partitioner':
'org.apache.cassandra.dht.OrderPreservingPartitioner'})
-print("CLUSTER INSTALL DIR: ")
-print(self.cluster.get_install_dir())
+logger.debug("CLUSTER INSTALL DIR: ")
+logger.debug(self.cluster.get_install_dir())
self.cluster.populate(3, tokens=self.tokens, debug=True,
install_byteman=True)
# self.cluster.populate(3, debug=True, install_byteman=True)
self.cluster.start(jvm_args=['-Dcassandra.enable_nodelocal_queries=true'],
@@ -124,7 +127,7 @@ class TestTransientReplicationRing(Tester):
# enable shared memory
for node in self.cluster.nodelist():
patch_start(node)
-print(node.logfilename())
+logger.debug(node.logfilename())
self.nodes = self.cluster.nodelist()
self.node1, self.node2, self.node3 = self.nodes
@@ -136,7 +139,7 @@ class TestTransientReplicationRing(Tester):
replication_params = ', '.join("'%s': '%s'" % (k, v) for k, v in
replication_params.items())
session.execute("CREATE KEYSPACE %s WITH REPLICATION={%s}" %
(self.keyspace, replication_params))
-print("CREATE KEYSPACE %s WITH REPLICATION={%s}" % (self.keyspace,
replication_params))
+logger.debug("CREATE KEYSPACE %s WITH REPLICATION={%s}" %
(self.keyspace, replication_params))
session.execute(
"CREATE TABLE %s.%s (pk varchar, ck int, value int, PRIMARY KEY
(pk, ck)) WITH speculative_retry = 'NEVER' AND additional_write_policy =
'NEVER' AND read_repair = 'NONE'" % (
self.keyspace, self.table))
@@ -240,7 +243,7 @@ class TestTransientReplicationRing(Tester):
nodes = [self.node1, self.node2, self.node3, node4]
for i in range(0, 40, 2):
-print("Inserting " + str(i))
+logger.debug("Inserting " + str(i))
self.insert_row(i, i, i, main_session)
# Make sure at least a little data is repaired
@@ -251,7 +254,7 @@ class TestTransientReplicationRing(Tester):
nodes[1].stop(wait_other_notice=True)
for i in range(1, 40, 2):
-print("Inserting " + str(i))
+logger.debug("Inserting " + str(i))
self.insert_row(i, i, i, main_session)
nodes[1].start(wait_for_binary_proto=True)
@@ -264,7 +267,9 @@ class TestTransientReplicationRing(Tester):
self.check_expected(sessions, expected)
self.check_replication(sessions, exactly=2)
-nodes[0].nodetool('move %s' % move_token)
+nodes[0].move(move_token)
[jira] [Assigned] (CASSANDRA-18836) Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe reassigned CASSANDRA-18836: --- Assignee: Maxim Muzafarov > 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 >Assignee: Maxim Muzafarov >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-18792:
-
Reviewers: Berenguer Blasi, Brandon Williams
Status: Review In Progress (was: Patch Available)
> 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
> java.rmi/
[jira] [Updated] (CASSANDRA-18836) Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18836: Change Category: Performance Complexity: Normal Fix Version/s: 5.0-alpha2 5.x Reviewers: Caleb Rackliffe Status: Open (was: Triage Needed) > 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 >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0-alpha2, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > 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] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-18792:
-
Status: Ready to Commit (was: Review In Progress)
> 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
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler
[jira] [Updated] (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:all-tabpanel
]
Brandon Williams updated CASSANDRA-18792:
-
Fix Version/s: 5.0-alpha2
5.1
(was: 5.x)
(was: 5.0.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/39a6c79bbd9e20435db8114c20d64f20942bd4f3
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed w/comment added, thanks!
> 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-alpha2, 5.1
>
>
> 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
[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
]
Brandon Williams updated CASSANDRA-18686:
-
Resolution: Fixed
Status: Resolved (was: Open)
With CASSANDRA-18854 and CASSANDRA-18792 closed, this ticket is resolved.
> 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 backw
[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
]
Brandon Williams updated CASSANDRA-18686:
-
Fix Version/s: 5.0-alpha2
5.1
(was: 5.x)
(was: 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
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha2, 5.1
>
>
> {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
>
[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 ] Brandon Williams updated CASSANDRA-16061: - Resolution: Fixed Status: Resolved (was: Open) With CASSANDRA-18854 and CASSANDRA-18792 closed, this ticket is resolved. > 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 >Assignee: Brandon Williams >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] [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 ] Brandon Williams updated CASSANDRA-16061: - Fix Version/s: 4.1.4 5.0-alpha2 5.1 (was: 5.x) (was: 4.1.x) (was: 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 >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.1.4, 5.0-alpha2, 5.1 > > > 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] [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&focusedCommentId=17766445#comment-17766445
]
Ekaterina Dimitrova commented on CASSANDRA-18686:
-
Should we add also 4.1 to the list of fix versions?
> 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-alpha2, 5.1
>
>
> {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
> withou
[jira] (CASSANDRA-18686) Test failure: test_move_backwards_and_cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-18686 ]
Ekaterina Dimitrova deleted comment on CASSANDRA-18686:
-
was (Author: e.dimitrova):
Should we add also 4.1 to the list of fix versions?
> 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-alpha2, 5.1
>
>
> {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_m
[jira] [Updated] (CASSANDRA-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18862:
--
Reviewers: Brandon Williams
Status: Review In Progress (was: Patch Available)
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18862:
--
Status: Ready to Commit (was: Review In Progress)
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18856) Test failure: rebuild_test.TestRebuild.test_resumable_rebuild
[
https://issues.apache.org/jira/browse/CASSANDRA-18856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766446#comment-17766446
]
Brandon Williams commented on CASSANDRA-18856:
--
Well in trying to check this
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1300/workflows/3b6b788e-0c2a-41f0-b822-c3317d2b29b8/jobs/54483/parallel-runs/24]
I discovered another message that needs to be ignored:
{quote}
ERROR [Streaming-EventLoop-4-2] 2023-09-18 14:49:24,132
StreamingMultiplexedChannel.java:267 - [Stream
#8e709340-5632-11ee-92a6-358fab39721d channel: ff69a9e4] failed to send a
stream message/data to peer /127.0.0.2:7000: msg = Session
Failed\nio.netty.channel.StacklessClosedChannelException: null\n\tat
io.netty.channel.AbstractChannel$AbstractUnsafe.write(Object,
ChannelPromise)(Unknown Source)
{quote}
which I have added.
||Branch||CI||
|[5.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18856-5.0]|[dtest
repeat|https://app.circleci.com/pipelines/github/driftx/cassandra/1300/workflows/b1896feb-7fa1-4f6a-8c24-2cd6533f66d6/jobs/54485]|
> Test failure: rebuild_test.TestRebuild.test_resumable_rebuild
> -
>
> Key: CASSANDRA-18856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18856
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> https://app.circleci.com/pipelines/github/driftx/cassandra/1294/workflows/04464235-3bcf-433e-ae81-206aa2c9c874/jobs/54042/tests
> {quote}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node3] 'ERROR
> [Stream-Deserializer-/127.0.0.2:7000-d94b6b54] 2023-09-15 16:04:30,685
> CassandraEntireSSTableStreamReader.java:146 - [Stream
> 8d7c61b0-53e1-11ee-a721-a91a3065a930] Error while reading sstable from stream
> for table = ks.cf\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:139)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.write(SSTableZeroCopyWriter.java:218)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.writeComponent(SSTableZeroCopyWriter.java:207)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:124)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:87)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:50)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)\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:833)', [node3] 'ERROR
> [Stream-Deserializer-/127.0.0.2:7000-6f7e3946] 2023-09-15 16:04:30,687
> CassandraEntireSSTableStreamReader.java:146 - [Stream
> 8d7c61b0-53e1-11ee-a721-a91a3065a930] Error while reading sstable from stream
> for table = ks.cf\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:139)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.write(SSTableZeroCopyWriter.java:218)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.writeComponent(SSTableZeroCopyWriter.java:207)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:124)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:87)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:50)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)\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.Thre
[jira] [Commented] (CASSANDRA-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766454#comment-17766454
]
Stefan Miklosovic commented on CASSANDRA-18862:
---
I did similar treatment to the log message in one catch block above:
https://github.com/apache/cassandra/pull/2700/files
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766456#comment-17766456
]
Brandon Williams commented on CASSANDRA-18862:
--
For the warn we should probably keep the stack, in case you actually want to
know where/how it's corrupted.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766457#comment-17766457
]
Stefan Miklosovic commented on CASSANDRA-18862:
---
Well, it logs it like this:
{code:java}
Non-fatal checksum error reading saved cache
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/data/saved_caches/KeyCache-g.db:
java.io.IOException: Corrupted file: integrity check (CRC32) failed for
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/data/saved_caches/KeyCache-g.crc:
-272646867 != -198358289 {code}
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766459#comment-17766459
]
Brandon Williams commented on CASSANDRA-18862:
--
Well that's not very helpful, +1 as it is then.
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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-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&focusedCommentId=17766466#comment-17766466 ] Runtian Liu commented on CASSANDRA-18781: - Yeah, sure, the change looks good to me. > 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] [Commented] (CASSANDRA-18856) Test failure: rebuild_test.TestRebuild.test_resumable_rebuild
[
https://issues.apache.org/jira/browse/CASSANDRA-18856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766469#comment-17766469
]
Brandon Williams commented on CASSANDRA-18856:
--
{quote}
Unexpected error found in node logs (see stdout for full details). Errors:
[[node3] 'ERROR [NonPeriodicTasks:1] 2023-09-18 15:49:58,416
LogTransaction.java:257 - Unable to delete
/tmp/dtest-5tbo6nua/test/node3/data0/ks/cf-e757d8d0563a11eea845d1494a012160/nc-2-big-Statistics.db.tmp
as it does not exist, see debug log file for stack trace']
{quote}
Interesting, there's more than I thought to this. I'll keep digging.
> Test failure: rebuild_test.TestRebuild.test_resumable_rebuild
> -
>
> Key: CASSANDRA-18856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18856
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> https://app.circleci.com/pipelines/github/driftx/cassandra/1294/workflows/04464235-3bcf-433e-ae81-206aa2c9c874/jobs/54042/tests
> {quote}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node3] 'ERROR
> [Stream-Deserializer-/127.0.0.2:7000-d94b6b54] 2023-09-15 16:04:30,685
> CassandraEntireSSTableStreamReader.java:146 - [Stream
> 8d7c61b0-53e1-11ee-a721-a91a3065a930] Error while reading sstable from stream
> for table = ks.cf\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:139)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.write(SSTableZeroCopyWriter.java:218)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.writeComponent(SSTableZeroCopyWriter.java:207)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:124)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:87)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:50)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)\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:833)', [node3] 'ERROR
> [Stream-Deserializer-/127.0.0.2:7000-6f7e3946] 2023-09-15 16:04:30,687
> CassandraEntireSSTableStreamReader.java:146 - [Stream
> 8d7c61b0-53e1-11ee-a721-a91a3065a930] Error while reading sstable from stream
> for table = ks.cf\njava.nio.channels.ClosedChannelException: null\n\tat
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:119)\n\tat
>
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:139)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.write(SSTableZeroCopyWriter.java:218)\n\tat
>
> org.apache.cassandra.io.sstable.SSTableZeroCopyWriter.writeComponent(SSTableZeroCopyWriter.java:207)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:124)\n\tat
>
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:87)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:50)\n\tat
>
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)\n\tat
>
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)\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:833)']"
> {quote}
> This is probably similar to CASSANDRA-18815
--
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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766481#comment-17766481 ] Maxim Muzafarov commented on CASSANDRA-18853: - [~smiklosovic] thanks for the clarification. I think you are talking about RedundantImportCheck. I think we can add it as well, I'll create an issue for that. https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/tools/checkstyle/checks/imports/RedundantImportCheck.html > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766481#comment-17766481 ] Maxim Muzafarov edited comment on CASSANDRA-18853 at 9/18/23 5:16 PM: -- [~smiklosovic] thanks for the clarification. I think you are talking about RedundantImportCheck. I think we can add it as well, I'll create an issue for that. https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/tools/checkstyle/checks/imports/RedundantImportCheck.html edit. I meant another issue would be good for that :-) was (Author: mmuzaf): [~smiklosovic] thanks for the clarification. I think you are talking about RedundantImportCheck. I think we can add it as well, I'll create an issue for that. https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/tools/checkstyle/checks/imports/RedundantImportCheck.html > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- 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-18853) IDEA to mark unused imports as error
[ https://issues.apache.org/jira/browse/CASSANDRA-18853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766520#comment-17766520 ] Stefan Miklosovic commented on CASSANDRA-18853: --- OK, I have more thoughts on that, lets create that ticket and keep this one focused on the original improvement. > IDEA to mark unused imports as error > > > Key: CASSANDRA-18853 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18853 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: image-2023-09-18-10-19-15-531.png > > > During dev it's quite easy to miss unused imports which will fail CI. That is > very annoying, slows dev down and CI expensive. It's easy to avoid by making > Idea mark them as errors -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[GitHub] [cassandra-analytics] frankgh commented on a diff in pull request #14: CASSANDRA-18759: Use in-jvm dtest framework from Sidecar for testing
frankgh commented on code in PR #14:
URL:
https://github.com/apache/cassandra-analytics/pull/14#discussion_r1329118359
##
build.gradle:
##
@@ -108,6 +121,12 @@ rat {
// resource files for test
excludes.add("**/test**/resources/**")
+ // resources
Review Comment:
we should exclude `**/dependencies/**`
--
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
[cassandra] branch trunk updated (3ebd09262b -> c2a4caa730)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 3ebd09262b Merge branch 'cassandra-5.0' into trunk add ba255f4fc7 Do not log stacktrace on mismatched cache and schema version and checksum error in AutoSavingCache new c2a4caa730 Merge branch 'cassandra-5.0' into trunk 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: CHANGES.txt | 2 ++ src/java/org/apache/cassandra/cache/AutoSavingCache.java | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-5.0' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit c2a4caa7301928fa2338b9c77437d41fa7c347fa Merge: 3ebd09262b ba255f4fc7 Author: Stefan Miklosovic AuthorDate: Mon Sep 18 21:23:18 2023 +0200 Merge branch 'cassandra-5.0' into trunk CHANGES.txt | 2 ++ src/java/org/apache/cassandra/cache/AutoSavingCache.java | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --cc CHANGES.txt index ba24ef078e,0f9d089477..f9fdb07388 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,6 -1,6 +1,8 @@@ -5.0-alpha2 +5.1 + * Clean up obsolete functions and simplify cql_version handling in cqlsh (CASSANDRA-18787) +Merged from 5.0: + * Do not log stacktrace on mismatched cache and schema version and checksum error in AutoSavingCache (CASSANDRA-18862) + * Remove wrong assertion in SSTableLoader (CASSANDRA-18840) * Fix accessing java.nio.Bits.TOTAL_CAPACITY in Java17 (CASSANDRA-18848) * Remove metrics-reporter-config dependency (CASSANDRA-18743) * Fix SAI's SegmentMetadata min and max primary keys (CASSANDRA-18734) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-5.0 updated (871e42cf97 -> ba255f4fc7)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 871e42cf97 Merge branch 'cassandra-4.1' into cassandra-5.0 add ba255f4fc7 Do not log stacktrace on mismatched cache and schema version and checksum error in AutoSavingCache No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/cache/AutoSavingCache.java | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18862) Fix logging / exception output on mismatched cache and schema version
[
https://issues.apache.org/jira/browse/CASSANDRA-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18862:
--
Fix Version/s: 5.0
5.1
(was: 5.x)
Source Control Link:
https://github.com/apache/cassandra/commit/ba255f4fc7d2326b770d0e19efe187e9fb65e303
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix logging / exception output on mismatched cache and schema version
> -
>
> Key: CASSANDRA-18862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18862
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Caching
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0, 5.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes I see this in the logs and Cassandra just continues to start as
> nothing happened:
> {code}
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,395 AutoSavingCache.java:214 -
> Reading saved cache:
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.crc,
>
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.metadata
> INFO [loadSavedCache:1] 2023-09-18 08:53:05,403 AutoSavingCache.java:277 -
> Harmless error reading saved cache
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/data/saved_caches/KeyCache-g.db
> java.lang.RuntimeException: Cache schema version
> e40b993e-88c0-314c-8a5e-c76871f0a144 does not match current schema version
> f1884cc9-7d66-3b5f-85e5-4bc0d647c885
> at
> org.apache.cassandra.cache.AutoSavingCache.loadSaved(AutoSavingCache.java:228)
> 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}
> Well if the log says it is harmless, why do we need to log the exception?
> There is no reason to print that stacktrace, it is just enough to print the
> mismatching versions. It should be also changed from INFO to WARN, or maybe
> better to DEBUG? I mean ... it is harmless, right? Why should I see, by
> default, that something harmless has happened?
--
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&focusedCommentId=17766383#comment-17766383 ] Maxim Muzafarov edited comment on CASSANDRA-14667 at 9/18/23 7:42 PM: -- With the latest changes, tests that previously failed now pass. https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/355/workflows/f4ff68a6-daf4-43ec-b12f-7b25f6582e5a/jobs/26762 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/355/workflows/f4ff68a6-daf4-43ec-b12f-7b25f6582e5a/jobs/26758 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/355/workflows/f4ff68a6-daf4-43ec-b12f-7b25f6582e5a/jobs/26759 I have no technical arguments for choosing one option over the other. For me, it will be better to fix the transitive dependency resolver process when an error occurs than to exclude dependencies in advance. However, since we already have such an example of exclusion in the source code we can include a similar one for these changes. [~smiklosovic] are you OK with it taking into account the last comments or do you still think the exclusion is a blocker for the patch itself? was (Author: mmuzaf): Tested on latest changes tests that were previously failed. https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/355/workflows/f4ff68a6-daf4-43ec-b12f-7b25f6582e5a/jobs/26762 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/355/workflows/f4ff68a6-daf4-43ec-b12f-7b25f6582e5a/jobs/26758 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/355/workflows/f4ff68a6-daf4-43ec-b12f-7b25f6582e5a/jobs/26759 I have no technical arguments for choosing one option over the other. For me, it will be better to fix the transitive dependency resolver process when an error occurs than to exclude dependencies in advance. However, since we already have such an example of exclusion in the source code we can include a similar one for these changes. [~smiklosovic] are you OK with it taking into account the last comments or do you still think the exclusion is a blocker for the patch itself? > 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] [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&focusedCommentId=17766571#comment-17766571 ] Stefan Miklosovic commented on CASSANDRA-14667: --- Sure let's exclude that, better be safe than sorry. My comments were written with a proper Maven resolver in mind. I have not expected we do not have the same thing here. It would be still worth to investigate where it diverges concretely from Maven on some examples but that is not the goal of this ticket. It would be great to have a clear understanding how the resolver we use behaves in various scenarios. > 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-18865: Description: Currently, the unnecessary imports are enabled by the code style and are not displayed by the IDE with the configuration stored in the project root. See the screenshot below. The RedundantImportCheck in not enabled by the checkstyle. It seems the following needs to be done: - enable this check in the IDE configuration for all supported IDEs; - enable check in the checkstyle plugin; - update the documentation; was: Currently, the unnecessary imports are enabled by the code style and are not displayed by the IDE with the configuration stored in the project root. See the screenshot below. The RedundantImportCheck in not enabled by the checkstyle. It seems the following needs to be done: - enable this check in the IDE configuration for all supported IDEs; - enable check in the checkstyle plugin; - update the documentation; > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck in not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-18865: Attachment: image-2023-09-18-10-19-15-531.png > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck in not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
Maxim Muzafarov created CASSANDRA-18865: --- Summary: Enable unnecessary import from the same package check (RedundantImportCheck) Key: CASSANDRA-18865 URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 Project: Cassandra Issue Type: Task Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Attachments: image-2023-09-18-10-19-15-531.png Currently, the unnecessary imports are enabled by the code style and are not displayed by the IDE with the configuration stored in the project root. See the screenshot below. The RedundantImportCheck in not enabled by the checkstyle. It seems the following needs to be done: - enable this check in the IDE configuration for all supported IDEs; - enable check in the checkstyle plugin; - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-18865: Description: Currently, the unnecessary imports are enabled by the code style and are not displayed by the IDE with the configuration stored in the project root. See the screenshot below. The RedundantImportCheck is not enabled by the checkstyle. It seems the following needs to be done: - enable this check in the IDE configuration for all supported IDEs; - enable check in the checkstyle plugin; - update the documentation; was: Currently, the unnecessary imports are enabled by the code style and are not displayed by the IDE with the configuration stored in the project root. See the screenshot below. The RedundantImportCheck in not enabled by the checkstyle. It seems the following needs to be done: - enable this check in the IDE configuration for all supported IDEs; - enable check in the checkstyle plugin; - update the documentation; > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck is not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766574#comment-17766574 ] Maxim Muzafarov commented on CASSANDRA-18865: - [~smiklosovic] I have loaclly checked the checkstyle by adding to the rule set, and I have also run the inspection rule over all the sources and it seems to me that we have no violations of these rules neither checkstyle nor inspection rule failed. It looks like it can be easily enabled without affecting ongoing work on CEPs. Do you have any comments on this? I haven't checked the NetBeans and Eclipse IDE configurations for this. > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck is not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766579#comment-17766579 ] Stefan Miklosovic commented on CASSANDRA-18865: --- This is very interesting. I was expecting there will be a lot of violations. Does that rule indeed works? :) Hard to believe ... Besides that, I am wondering if we really want to do this. The only argument against that is that somebody can easily "grep" where a class is used across the whole project just grepping imports but since IDEs are doing this automatically I do not think we need to "support" this (and it would be even very precise as there might be already cases when it is not imported and that class is used in another one anyway, without any import, because it is in the same package). That is all being said if we actually had cases like that over the code-base but you say we do not which makes that argument somehow void. > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck is not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766579#comment-17766579 ] Stefan Miklosovic edited comment on CASSANDRA-18865 at 9/18/23 8:44 PM: This is very interesting. I was expecting there will be a lot of violations. Does that rule indeed works? :) Hard to believe ... Besides that, I am wondering if we really want to do this. The only argument against that is that somebody can easily "grep" where a class is used across the whole project just grepping imports but since IDEs are doing this automatically I do not think we need to "support" this (and it would not be even very precise as there might be already cases when it is not imported and that class is used in another one anyway, without any import, because it is in the same package). That is all being said if we actually had cases like that over the code-base but you say we do not which makes that argument somehow void. was (Author: smiklosovic): This is very interesting. I was expecting there will be a lot of violations. Does that rule indeed works? :) Hard to believe ... Besides that, I am wondering if we really want to do this. The only argument against that is that somebody can easily "grep" where a class is used across the whole project just grepping imports but since IDEs are doing this automatically I do not think we need to "support" this (and it would be even very precise as there might be already cases when it is not imported and that class is used in another one anyway, without any import, because it is in the same package). That is all being said if we actually had cases like that over the code-base but you say we do not which makes that argument somehow void. > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck is not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766580#comment-17766580 ] Stefan Miklosovic commented on CASSANDRA-18865: --- Well it seems that rule is already enabled ... wow. I do not remeber that. https://github.com/apache/cassandra/blob/trunk/.build/checkstyle.xml#L172 > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck is not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766580#comment-17766580 ] Stefan Miklosovic edited comment on CASSANDRA-18865 at 9/18/23 8:47 PM: Well it seems that rule is already enabled ... wow. I do not remeber that. https://github.com/apache/cassandra/blob/trunk/.build/checkstyle.xml#L172 So this ticket should just cover the change for idea files so it is marked as an error, right? was (Author: smiklosovic): Well it seems that rule is already enabled ... wow. I do not remeber that. https://github.com/apache/cassandra/blob/trunk/.build/checkstyle.xml#L172 > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck is not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766581#comment-17766581 ] Maxim Muzafarov commented on CASSANDRA-18865: - yeah, but at least we can add it to the checkstyle as it is free of change for us. > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck is not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766584#comment-17766584 ] Maxim Muzafarov commented on CASSANDRA-18865: - [~smiklosovic] Ooops, I definitely need more sleep :-) it was added by you here: CASSANDRA-17876 Well, then we just need to update the IDE configurations, right? > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck is not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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-18865) Enable unnecessary import from the same package check (RedundantImportCheck)
[ https://issues.apache.org/jira/browse/CASSANDRA-18865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17766584#comment-17766584 ] Maxim Muzafarov edited comment on CASSANDRA-18865 at 9/18/23 8:58 PM: -- [~smiklosovic] Ooops, I definitely need more sleep :-) it was added by you here: CASSANDRA-17876 Well, then let's just update the IDE configurations. was (Author: mmuzaf): [~smiklosovic] Ooops, I definitely need more sleep :-) it was added by you here: CASSANDRA-17876 Well, then we just need to update the IDE configurations, right? > Enable unnecessary import from the same package check (RedundantImportCheck) > > > Key: CASSANDRA-18865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18865 > Project: Cassandra > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Attachments: image-2023-09-18-10-19-15-531.png > > > Currently, the unnecessary imports are enabled by the code style and are not > displayed by the IDE with the configuration stored in the project root. See > the screenshot below. The RedundantImportCheck is not enabled by the > checkstyle. > It seems the following needs to be done: > - enable this check in the IDE configuration for all supported IDEs; > - enable check in the checkstyle plugin; > - update the documentation; -- 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
