[jira] [Created] (CASSANDRA-16702) Latest 3.x Cassandra (3.11.10) fails to start after updating corretto jdk from 8.252 to 8.292

2021-05-28 Thread Alexey Barsov (Jira)
Alexey Barsov created CASSANDRA-16702:
-

 Summary: Latest 3.x Cassandra (3.11.10) fails to start after 
updating corretto jdk from 8.252 to 8.292
 Key: CASSANDRA-16702
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16702
 Project: Cassandra
  Issue Type: Bug
  Components: Dependencies
Reporter: Alexey Barsov


Cassandra fails to start with the following exception 


{code:java}
[2021-05-22 03:19:04,790] [Apache Cassandra Error] 
java.lang.UnsatisfiedLinkError: 
C:\Users\alexey.barsov\AppData\Local\Temp\jna--1630081341\jna2627169091367567840.dll:
 Can't find dependent libraries
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.ClassLoader$NativeLibrary.load(Native Method)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.Runtime.load0(Runtime.java:810)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.System.load(System.java:1088)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:851)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:826)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.sun.jna.Native.(Native.java:140)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
org.apache.cassandra.utils.WindowsTimer.(WindowsTimer.java:35)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:630)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.jetbrains.cassandra.service.CassandraServiceMain.start(CassandraServiceMain.java:92)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:99)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:97)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.lang.Thread.run(Thread.java:748){code}

To Reproduce
 Run Cassandra 3.11.0 on corretto jdk 8.292

Platform information
 OS: Windows 10
Jdk Version: OpenJDK 64-Bit Server VM Corretto-8.292.10.1 (build 25.292-b10, 
mixed mode)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-16702) Latest 3.x Cassandra (3.11.10) fails to start after updating corretto jdk from 8.252 to 8.292

2021-05-28 Thread Alexey Barsov (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353023#comment-17353023
 ] 

Alexey Barsov commented on CASSANDRA-16702:
---

It started working after I had updated jna version to the latest on cassanra 
classpath (from 4.2.2 to 5.8.0).

> Latest 3.x Cassandra (3.11.10) fails to start after updating corretto jdk 
> from 8.252 to 8.292
> -
>
> Key: CASSANDRA-16702
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16702
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies
>Reporter: Alexey Barsov
>Priority: Normal
>
> Cassandra fails to start with the following exception 
> {code:java}
> [2021-05-22 03:19:04,790] [Apache Cassandra Error] 
> java.lang.UnsatisfiedLinkError: 
> C:\Users\alexey.barsov\AppData\Local\Temp\jna--1630081341\jna2627169091367567840.dll:
>  Can't find dependent libraries
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> java.lang.ClassLoader$NativeLibrary.load(Native Method)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> java.lang.Runtime.load0(Runtime.java:810)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> java.lang.System.load(System.java:1088)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:851)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:826)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> com.sun.jna.Native.(Native.java:140)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> org.apache.cassandra.utils.WindowsTimer.(WindowsTimer.java:35)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:630)
>  [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
> com.jetbrains.cassandra.service.CassandraServiceMain.start(CassandraServiceMain.java:92)
>  [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
> com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:99)
>  [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
> com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:97)
>  [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>  [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
> java.lang.Thread.run(Thread.java:748){code}
> To Reproduce
>  Run Cassandra 3.11.0 on corretto jdk 8.292
> Platform information
>  OS: Windows 10
> Jdk Version: OpenJDK 64-Bit Server VM Corretto-8.292.10.1 (build 25.292-b10, 
> mixed mode)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-16702) Latest 3.x Cassandra (3.11.10) fails to start after updating corretto jdk from 8.252 to 8.292

2021-05-28 Thread Alexey Barsov (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Barsov updated CASSANDRA-16702:
--
Description: 
Cassandra fails to start with the following exception
{code:java}
[2021-05-22 03:19:04,790] [Apache Cassandra Error] 
java.lang.UnsatisfiedLinkError: 
C:\Users\alexey.barsov\AppData\Local\Temp\jna--1630081341\jna2627169091367567840.dll:
 Can't find dependent libraries
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.ClassLoader$NativeLibrary.load(Native Method)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.Runtime.load0(Runtime.java:810)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.System.load(System.java:1088)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:851)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:826)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.sun.jna.Native.(Native.java:140)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
org.apache.cassandra.utils.WindowsTimer.(WindowsTimer.java:35)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:630)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.jetbrains.cassandra.service.CassandraServiceMain.start(CassandraServiceMain.java:92)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:99)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:97)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.lang.Thread.run(Thread.java:748){code}
To Reproduce
 Run Cassandra 3.11.0 on corretto jdk 8.292

Platform information
 OS: Windows 10
 Jdk Version: OpenJDK 64-Bit Server VM Corretto-8.292.10.1 (build 25.292-b10, 
mixed mode)

 

Note: related issue in corretto jdk 8 issue tracker: 
https://github.com/corretto/corretto-8/issues/308

  was:
Cassandra fails to start with the following exception 


{code:java}
[2021-05-22 03:19:04,790] [Apache Cassandra Error] 
java.lang.UnsatisfiedLinkError: 
C:\Users\alexey.barsov\AppData\Local\Temp\jna--1630081341\jna2627169091367567840.dll:
 Can't find dependent libraries
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.ClassLoader$NativeLibrary.load(Native Method)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.Runtime.load0(Runtime.java:810)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
java.lang.System.load(System.java:1088)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:851)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:826)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.sun.jna.Native.(Native.java:140)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
org.apache.cassandra.utils.WindowsTimer.(WindowsTimer.java:35)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:630)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at 
com.jetbrains.cassandra.service.CassandraServiceMain.start(CassandraServiceMain.java:92)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:99)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:97)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 [2021-05-22 03:19:04,791] [Apache Cassandra E

[jira] [Created] (CASSANDRA-16703) Exception thrown by custom QueryHandler constructor is ignored

2021-05-28 Thread Francisco Bento (Jira)
Francisco Bento created CASSANDRA-16703:
---

 Summary: Exception thrown by custom QueryHandler constructor is 
ignored
 Key: CASSANDRA-16703
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16703
 Project: Cassandra
  Issue Type: Bug
  Components: Local/Startup and Shutdown
Reporter: Francisco Bento


When a exception is thrown during the instantiation of the 
_cassandra.custom_query_handler_class,_ depending on the exception thrown 
cassandra will simply log an info message and proceed with the bootstraping 
with the standard _QueryHandler_ as a fallback measure: 
[https://github.com/apache/cassandra/blob/cassandra-3.11.10/src/java/org/apache/cassandra/service/ClientState.java#L107|https://github.com/apache/cassandra/blob/3b553d8e13dbdbe59119de9c917d9aacc440741e/src/java/org/apache/cassandra/service/ClientState.java#L104]

The end-user will never know if the custom _QueryHandler_ is actually 
registered or not, unless he notices the info message on the logs.

Ideally, the message should be logged as error and JVM should stop as it cannot 
proceed according with the user expected configuration.

*Scenario*:

In our scenario, we have a custom _QueryHandler_ that receives specific 
configuration, and we throw a _ConfigurationException_ at instantiation time in 
case of any invalid config value. It is expected that cassandra stop the 
bootstraping instead of skipping the QH.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Created] (CASSANDRA-16704) Fix imports; run tests with packaged dependencies

2021-05-28 Thread Angelo Polo (Jira)
Angelo Polo created CASSANDRA-16704:
---

 Summary: Fix imports; run tests with packaged dependencies
 Key: CASSANDRA-16704
 URL: https://issues.apache.org/jira/browse/CASSANDRA-16704
 Project: Cassandra
  Issue Type: Bug
  Components: Build, Test/burn, Test/unit
Reporter: Angelo Polo
Assignee: Angelo Polo
 Attachments: test-with-runtime-deps.patch

Tests are currently run with a classpath containing _all_ downloaded jars. The 
tests would be more reflective of the behavior of a runtime environment if the 
test classpath only contained jars that are bundled with the binary release, 
together with explicit test dependencies. Ideally we'd use the build/lib/ jars 
for the classpath since that's what gets packaged, but since these aren't 
available at test compile time and should be identical to lib/ anyway, I've 
used the later.

Doing so exposed a couple of references in src/java to 
"org.apache.commons.lang", which is not available at runtime (should be 
"org.apache.commons.lang*3*").

Attached patch modifies the test classpath, fixes various imports in both test/ 
and src/ classes, and makes some simple substitutions in the tests such as 
using AbstractMap.SimpleEntry in place of 
org.apache.commons.collections.keyvalue.AbstractMapEntry.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-15669) LeveledCompactionStrategy compact last level throw an ArrayIndexOutOfBoundsException

2021-05-28 Thread Yifan Cai (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-15669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353467#comment-17353467
 ] 

Yifan Cai commented on CASSANDRA-15669:
---

I am working on committing. 
[~azotcsit], can you also provide a patch for the 3.11 branch? We merge from 
bottom up. So in this case, it is from 3.11 to trunk. But my preference is to 
have patches for each branch, which works better with my committing script :D

> LeveledCompactionStrategy compact last level throw an 
> ArrayIndexOutOfBoundsException
> 
>
> Key: CASSANDRA-15669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15669
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Compaction/LCS
>Reporter: sunhaihong
>Assignee: Alexey Zotov
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Attachments: cfs_compaction_info.png, error_info.png
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Cassandra will throw an ArrayIndexOutOfBoundsException when compact last 
> level.
> My test is as follows:
>  # Create a table with LeveledCompactionStrategy and its params are 
> 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', 
> 'min_threshold': '4', 'sstable_size_in_mb': '2'(fanout_size and 
> sstable_size_in_mb are too small just to make it easier to reproduce the 
> problem);
>  # Insert data into the table by stress;
>  # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 
> sstables(this level score bigger than 1.001)
> ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 
> - Exception in thread Thread[CompactionExecutor:4,1,main]
>  java.lang.ArrayIndexOutOfBoundsException: 9
>  at 
> org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814)
>  at 
> org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746)
>  at 
> org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398)
>  at 
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131)
>  at 
> org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109)
>  at 
> org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:66)
>  at 
> org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:214)
>  at 
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:289)
>  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>  at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
>  at java.util.concurrent.FutureTask.run(FutureTask.java)
>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>  at java.lang.Thread.run(Thread.java:748)
> I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all 
> happened.
> once it triggers, level1- leveln compaction no longer works, level0 is still 
> valid
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-16692) Unable to replace node with stale schema

2021-05-28 Thread Matt Lehman (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353483#comment-17353483
 ] 

Matt Lehman commented on CASSANDRA-16692:
-

Per Sumanth: the patch is confirmed working on 3.0.

> Unable to replace node with stale schema
> 
>
> Key: CASSANDRA-16692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16692
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Matt Lehman
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
>  
> After CASSANDRA-15158 operators are no longer permitted to replace a 
> terminated node with a stale schema. That is, launching a node to replace 
> NodeA in the following scenario:
> {code:java}
> NodeA (terminated): schema=V0
> All others (alive): schema=V1{code}
> yields:
> {code:java}
> ERROR [main] 2021-04-30 19:10:23,410 CassandraDaemon.java:822 - Exception 
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions 
> within the timeout
> at 
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:887)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:937)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:746)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:654)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374) 
> [nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616)
>  [nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809) 
> [nf-cassandra-3.0.24.1.jar:3.0.24.1]{code}
> This can be reproduced like so:
>  # Shut down C* on one node in a 3.0.24 cluster
>  # Create a new keyspace and table from one of the other nodes
>  # Terminate and replace the node on which C* was shut down.
> Waiting for agreement of the nodes not being replaced seems prudent as not 
> doing so could induce data loss, the node being replaced should be exempted 
> from this check.
> Reference CASSANDRA-16577 for more context.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Commented] (CASSANDRA-16669) Password obfuscation for DCL audit log statements

2021-05-28 Thread Sumanth Pasupuleti (Jira)


[ 
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353577#comment-17353577
 ] 

Sumanth Pasupuleti commented on CASSANDRA-16669:


Here is the first version of the patch 
https://github.com/apache/cassandra/pull/1028.

This follows a rather less complicated approach of obfuscating anything that 
follows "password" token in the DCL query, inspired from what the [PostgreSQL 
Audit Extension 
(pgAudit)|https://github.com/pgaudit/pgaudit/blob/master/pgaudit.c#L489-L535] 
does. 

> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
>  Labels: audit, security
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information 
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL 
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
>  and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] ) 
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in 
> audit log files is either by 
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
>  DCL statements from auditing or by excluding the user who is creating these 
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate 
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
>  ROLE new_role;
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
>  ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
>  ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't 
> exist
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
>  ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage: 
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
>  ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit 
> log documentation until we close this JIRA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk

2021-05-28 Thread bdeggleston
This is an automated email from the ASF dual-hosted git repository.

bdeggleston pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit c29bdeed883ab6b840876ec70ee0bc0a432ac2fe
Merge: 3b553d8 80ea99d
Author: Blake Eggleston 
AuthorDate: Fri May 28 16:28:49 2021 -0700

Merge branch 'cassandra-4.0' into trunk

 CHANGES.txt|   1 +
 .../cassandra/schema/MigrationCoordinator.java |  62 ++-
 .../apache/cassandra/service/StorageService.java   |   6 +-
 .../distributed/test/MigrationCoordinatorTest.java | 121 +
 .../cassandra/schema/MigrationCoordinatorTest.java |  34 +++---
 5 files changed, 202 insertions(+), 22 deletions(-)

diff --cc CHANGES.txt
index f7927e5,528d129..6652ad0
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -18,6 -16,7 +18,7 @@@ Merged from 3.11
   * Nodetool garbagecollect should retain SSTableLevel for LCS 
(CASSANDRA-16634)
   * Ignore stale acks received in the shadow round (CASSANDRA-16588)
  Merged from 3.0:
 - * Don't wait on schema versions from replacement target when replacing a 
node (CASSANDRA-16692)
++ * Don't wait on schema versions from replacement target when replacing a node
   * StandaloneVerifier does not fail when unable to verify SSTables, it only 
fails if Corruption is thrown (CASSANDRA-16683)
   * Fix bloom filter false ratio calculation by including true negatives 
(CASSANDRA-15834)
   * Prevent loss of commit log data when moving sstables between nodes 
(CASSANDRA-16619)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra] branch trunk updated (3b553d8 -> c29bdee)

2021-05-28 Thread bdeggleston
This is an automated email from the ASF dual-hosted git repository.

bdeggleston pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from 3b553d8  Merge branch 'cassandra-4.0' into trunk
 add 5f09226  Don't wait on schema versions from replacement target when 
replacing a node
 add 85358be  Merge branch 'cassandra-3.0' into cassandra-3.11
 add 80ea99d  Merge branch 'cassandra-3.11' into cassandra-4.0
 new c29bdee  Merge branch 'cassandra-4.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|   1 +
 .../cassandra/schema/MigrationCoordinator.java |  62 ++-
 .../apache/cassandra/service/StorageService.java   |   6 +-
 .../distributed/test/MigrationCoordinatorTest.java | 121 +
 .../cassandra/schema/MigrationCoordinatorTest.java |  34 +++---
 5 files changed, 202 insertions(+), 22 deletions(-)
 create mode 100644 
test/distributed/org/apache/cassandra/distributed/test/MigrationCoordinatorTest.java

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra] branch cassandra-3.11 updated (7694cc5 -> 85358be)

2021-05-28 Thread bdeggleston
This is an automated email from the ASF dual-hosted git repository.

bdeggleston pushed a change to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from 7694cc5  Merge branch 'cassandra-3.0' into cassandra-3.11
 add 5f09226  Don't wait on schema versions from replacement target when 
replacing a node
 add 85358be  Merge branch 'cassandra-3.0' into cassandra-3.11

No new revisions were added by this update.

Summary of changes:
 CHANGES.txt|   1 +
 .../cassandra/service/MigrationCoordinator.java|  61 ++-
 .../apache/cassandra/service/StorageService.java   |   6 +-
 .../distributed/test/MigrationCoordinatorTest.java | 122 +
 .../service/MigrationCoordinatorTest.java  |   2 +-
 5 files changed, 188 insertions(+), 4 deletions(-)
 create mode 100644 
test/distributed/org/apache/cassandra/distributed/test/MigrationCoordinatorTest.java

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra] branch cassandra-4.0 updated (0d3ead9 -> 80ea99d)

2021-05-28 Thread bdeggleston
This is an automated email from the ASF dual-hosted git repository.

bdeggleston pushed a change to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from 0d3ead9  Merge branch 'cassandra-3.11' into cassandra-4.0
 add 5f09226  Don't wait on schema versions from replacement target when 
replacing a node
 add 85358be  Merge branch 'cassandra-3.0' into cassandra-3.11
 add 80ea99d  Merge branch 'cassandra-3.11' into cassandra-4.0

No new revisions were added by this update.

Summary of changes:
 CHANGES.txt|   1 +
 .../cassandra/schema/MigrationCoordinator.java |  62 ++-
 .../apache/cassandra/service/StorageService.java   |   6 +-
 .../distributed/test/MigrationCoordinatorTest.java | 121 +
 .../cassandra/schema/MigrationCoordinatorTest.java |  34 +++---
 5 files changed, 202 insertions(+), 22 deletions(-)
 create mode 100644 
test/distributed/org/apache/cassandra/distributed/test/MigrationCoordinatorTest.java

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[cassandra] branch cassandra-3.0 updated (269bc5c -> 5f09226)

2021-05-28 Thread bdeggleston
This is an automated email from the ASF dual-hosted git repository.

bdeggleston pushed a change to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from 269bc5c  Add CircleCI jobs to repeat upgrade tests n times
 add 5f09226  Don't wait on schema versions from replacement target when 
replacing a node

No new revisions were added by this update.

Summary of changes:
 CHANGES.txt|   1 +
 .../cassandra/service/MigrationCoordinator.java|  61 ++-
 .../apache/cassandra/service/StorageService.java   |   6 +-
 .../distributed/test/MigrationCoordinatorTest.java | 122 +
 .../service/MigrationCoordinatorTest.java  |   2 +-
 5 files changed, 188 insertions(+), 4 deletions(-)
 create mode 100644 
test/distributed/org/apache/cassandra/distributed/test/MigrationCoordinatorTest.java

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-16692) Unable to replace node with stale schema

2021-05-28 Thread Blake Eggleston (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Eggleston updated CASSANDRA-16692:

Status: Ready to Commit  (was: Review In Progress)

> Unable to replace node with stale schema
> 
>
> Key: CASSANDRA-16692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16692
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Matt Lehman
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
>  
> After CASSANDRA-15158 operators are no longer permitted to replace a 
> terminated node with a stale schema. That is, launching a node to replace 
> NodeA in the following scenario:
> {code:java}
> NodeA (terminated): schema=V0
> All others (alive): schema=V1{code}
> yields:
> {code:java}
> ERROR [main] 2021-04-30 19:10:23,410 CassandraDaemon.java:822 - Exception 
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions 
> within the timeout
> at 
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:887)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:937)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:746)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:654)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374) 
> [nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616)
>  [nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809) 
> [nf-cassandra-3.0.24.1.jar:3.0.24.1]{code}
> This can be reproduced like so:
>  # Shut down C* on one node in a 3.0.24 cluster
>  # Create a new keyspace and table from one of the other nodes
>  # Terminate and replace the node on which C* was shut down.
> Waiting for agreement of the nodes not being replaced seems prudent as not 
> doing so could induce data loss, the node being replaced should be exempted 
> from this check.
> Reference CASSANDRA-16577 for more context.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-16692) Unable to replace node with stale schema

2021-05-28 Thread Blake Eggleston (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Eggleston updated CASSANDRA-16692:

Reviewers: Brandon Williams, Blake Eggleston  (was: Blake Eggleston, 
Brandon Williams)
   Brandon Williams, Blake Eggleston  (was: Brandon Williams)
   Status: Review In Progress  (was: Patch Available)

> Unable to replace node with stale schema
> 
>
> Key: CASSANDRA-16692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16692
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Matt Lehman
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
>  
> After CASSANDRA-15158 operators are no longer permitted to replace a 
> terminated node with a stale schema. That is, launching a node to replace 
> NodeA in the following scenario:
> {code:java}
> NodeA (terminated): schema=V0
> All others (alive): schema=V1{code}
> yields:
> {code:java}
> ERROR [main] 2021-04-30 19:10:23,410 CassandraDaemon.java:822 - Exception 
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions 
> within the timeout
> at 
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:887)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:937)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:746)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:654)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374) 
> [nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616)
>  [nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809) 
> [nf-cassandra-3.0.24.1.jar:3.0.24.1]{code}
> This can be reproduced like so:
>  # Shut down C* on one node in a 3.0.24 cluster
>  # Create a new keyspace and table from one of the other nodes
>  # Terminate and replace the node on which C* was shut down.
> Waiting for agreement of the nodes not being replaced seems prudent as not 
> doing so could induce data loss, the node being replaced should be exempted 
> from this check.
> Reference CASSANDRA-16577 for more context.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-16692) Unable to replace node with stale schema

2021-05-28 Thread Blake Eggleston (Jira)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-16692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Eggleston updated CASSANDRA-16692:

  Since Version: 3.0.23
Source Control Link: 
https://github.com/apache/cassandra/commit/5f09226a0d56f6d2d5e60f83465f9f17beed0572
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

committed, thanks!

> Unable to replace node with stale schema
> 
>
> Key: CASSANDRA-16692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16692
> Project: Cassandra
>  Issue Type: Bug
>  Components: Cluster/Schema
>Reporter: Matt Lehman
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
>  
> After CASSANDRA-15158 operators are no longer permitted to replace a 
> terminated node with a stale schema. That is, launching a node to replace 
> NodeA in the following scenario:
> {code:java}
> NodeA (terminated): schema=V0
> All others (alive): schema=V1{code}
> yields:
> {code:java}
> ERROR [main] 2021-04-30 19:10:23,410 CassandraDaemon.java:822 - Exception 
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions 
> within the timeout
> at 
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:887)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:937)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:746)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:654)
>  ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374) 
> [nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616)
>  [nf-cassandra-3.0.24.1.jar:3.0.24.1]
> at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809) 
> [nf-cassandra-3.0.24.1.jar:3.0.24.1]{code}
> This can be reproduced like so:
>  # Shut down C* on one node in a 3.0.24 cluster
>  # Create a new keyspace and table from one of the other nodes
>  # Terminate and replace the node on which C* was shut down.
> Waiting for agreement of the nodes not being replaced seems prudent as not 
> doing so could induce data loss, the node being replaced should be exempted 
> from this check.
> Reference CASSANDRA-16577 for more context.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org