[cassandra-website] branch asf-staging updated (29a55abe -> 5499c15c)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 29a55abe generate docs for 17718e18 new 5499c15c generate docs for 17718e18 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (29a55abe) \ N -- N -- N refs/heads/asf-staging (5499c15c) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (2e077123 -> 29a55abe)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 2e077123 generate docs for 17718e18 new 29a55abe generate docs for 17718e18 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (2e077123) \ N -- N -- N refs/heads/asf-staging (29a55abe) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17663) Ensure FileStreamTask cannot compromise shared channel proxy for system table when interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542243#comment-17542243
]
Caleb Rackliffe edited comment on CASSANDRA-17663 at 5/26/22 2:58 AM:
--
Given CASSANDRA-17648 already exists, I'd like to defer 3.x work on this issue
there. {{RepairErrorsTest}}, for example, does not yet exist in 3.x, and I'd
like to move it over in its entirety.
was (Author: maedhroz):
Given CASSANDRA-17648 already exists, I'd like to defer 3.x work on this issue
there. `RepairErrorsTest`, for example, does not yet exist in 3.x, and I'd like
to move it over in its entirety.
> Ensure FileStreamTask cannot compromise shared channel proxy for system table
> when interrupted
> --
>
> Key: CASSANDRA-17663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This is very similar to what we fixed in CASSANDRA-17466 , just in a
> different part of the repair/streaming machine.
> {{NettyStreamingMessageSender}} is responsible for dispatching
> {{FileStreamTask}} on an executor it manages to stream files to its peers.
> When the sender is closed for any reason, like perhaps a peer blowing up
> while deserializing the stream, the executor it manages is shut down w/
> interruption (i.e. {{shutdownNow()}}). This is problematic if we happen to
> have not gotten very far along in {{FileStreamTask#run()}}. If we're just
> about to call {{getOrCreateChannel()}}, which reads from the {{peers_v2}}
> system table, the {{ChannelProxy}} read will throw a
> {{ClosedByInterruptedException}} and the proxy will be useless. The twist is
> that, since CASSANDRA-15666, this exception has essentially been swallowed by
> {{FileStreamTask}}'s exception handling. So we don't see a
> {{ClosedByInterruptedException}} in the logs, but we do have things like this
> pop up when anything else tries to hit the peers table:
> {noformat}
> ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.cassandra.io.FSReadError:
> java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> {noformat}
> ...and...
> {noformat}
> ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[CompactionExecutor:12,1,main]
> org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt
[jira] [Comment Edited] (CASSANDRA-17663) Ensure FileStreamTask cannot compromise shared channel proxy for system table when interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542255#comment-17542255
]
Caleb Rackliffe edited comment on CASSANDRA-17663 at 5/26/22 2:57 AM:
--
The 4.1 and trunk patches are going to be a bit different, but in the mean
time, here's 4.0...
[4.0 patch|https://github.com/apache/cassandra/pull/1647]
[4.0
CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17663-4.0&filter=all]
UPDATE: Tests look reasonable. There are a couple normal/unrelated failures.
was (Author: maedhroz):
The 4.1 and trunk patches are going to be a bit different, but in the mean
time, here's 4.0...
[4.0 patch|https://github.com/apache/cassandra/pull/1647]
[4.0
CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17663-4.0&filter=all]
> Ensure FileStreamTask cannot compromise shared channel proxy for system table
> when interrupted
> --
>
> Key: CASSANDRA-17663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This is very similar to what we fixed in CASSANDRA-17466 , just in a
> different part of the repair/streaming machine.
> {{NettyStreamingMessageSender}} is responsible for dispatching
> {{FileStreamTask}} on an executor it manages to stream files to its peers.
> When the sender is closed for any reason, like perhaps a peer blowing up
> while deserializing the stream, the executor it manages is shut down w/
> interruption (i.e. {{shutdownNow()}}). This is problematic if we happen to
> have not gotten very far along in {{FileStreamTask#run()}}. If we're just
> about to call {{getOrCreateChannel()}}, which reads from the {{peers_v2}}
> system table, the {{ChannelProxy}} read will throw a
> {{ClosedByInterruptedException}} and the proxy will be useless. The twist is
> that, since CASSANDRA-15666, this exception has essentially been swallowed by
> {{FileStreamTask}}'s exception handling. So we don't see a
> {{ClosedByInterruptedException}} in the logs, but we do have things like this
> pop up when anything else tries to hit the peers table:
> {noformat}
> ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.cassandra.io.FSReadError:
> java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> {noformat}
> ...and...
> {noformat}
> ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[CompactionExecutor:12,1,main]
> org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk
[jira] [Updated] (CASSANDRA-17663) Ensure FileStreamTask cannot compromise shared channel proxy for system table when interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17663:
-
Fix Version/s: 4.1-beta
(was: 4.1-alpha)
> Ensure FileStreamTask cannot compromise shared channel proxy for system table
> when interrupted
> --
>
> Key: CASSANDRA-17663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-beta
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is very similar to what we fixed in CASSANDRA-17466 , just in a
> different part of the repair/streaming machine.
> {{NettyStreamingMessageSender}} is responsible for dispatching
> {{FileStreamTask}} on an executor it manages to stream files to its peers.
> When the sender is closed for any reason, like perhaps a peer blowing up
> while deserializing the stream, the executor it manages is shut down w/
> interruption (i.e. {{shutdownNow()}}). This is problematic if we happen to
> have not gotten very far along in {{FileStreamTask#run()}}. If we're just
> about to call {{getOrCreateChannel()}}, which reads from the {{peers_v2}}
> system table, the {{ChannelProxy}} read will throw a
> {{ClosedByInterruptedException}} and the proxy will be useless. The twist is
> that, since CASSANDRA-15666, this exception has essentially been swallowed by
> {{FileStreamTask}}'s exception handling. So we don't see a
> {{ClosedByInterruptedException}} in the logs, but we do have things like this
> pop up when anything else tries to hit the peers table:
> {noformat}
> ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.cassandra.io.FSReadError:
> java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> {noformat}
> ...and...
> {noformat}
> ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[CompactionExecutor:12,1,main]
> org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.seekToCurrentRangeStart(BigTableScanner.java:196)
>
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.access$400(BigTableScanner.java:52)
>
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$
[jira] [Commented] (CASSANDRA-17213) CompactStorageUpgradeTest.compactStorageUpgradeTest fails w/OOM
[ https://issues.apache.org/jira/browse/CASSANDRA-17213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542276#comment-17542276 ] Caleb Rackliffe commented on CASSANDRA-17213: - Hit a timeout in this test here: https://app.circleci.com/pipelines/github/maedhroz/cassandra/411/workflows/3f77508a-548a-4a17-a086-474afd9653f4/jobs/3151/tests#failed-test-0 > CompactStorageUpgradeTest.compactStorageUpgradeTest fails w/OOM > --- > > Key: CASSANDRA-17213 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17213 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Josh McKenzie >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x > > > [https://ci-cassandra.apache.org/job/Cassandra-trunk/882/testReport/org.apache.cassandra.distributed.upgrade/CompactStorageUpgradeTest/compactStorageUpgradeTest/] > h3. Error Message > GC overhead limit exceeded > h3. Stacktrace > java.lang.OutOfMemoryError: GC overhead limit exceeded at > sun.net.www.ParseUtil.encodePath(ParseUtil.java:105) at > sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:969) at > sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:1056) at > sun.misc.URLClassPath.getResource(URLClassPath.java:249) at > java.net.URLClassLoader$1.run(URLClassLoader.java:366) at > java.net.URLClassLoader$1.run(URLClassLoader.java:363) at > java.security.AccessController.doPrivileged(Native Method) at > java.net.URLClassLoader.findClass(URLClassLoader.java:362) at > org.apache.cassandra.distributed.shared.InstanceClassLoader.findClass(InstanceClassLoader.java:140) > at > org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClassInternal(InstanceClassLoader.java:123) > at > org.apache.cassandra.distributed.shared.InstanceClassLoader.loadClass(InstanceClassLoader.java:109) > at > org.codehaus.jackson.map.introspect.BasicClassIntrospector.(BasicClassIntrospector.java:62) > at org.codehaus.jackson.map.ObjectMapper.(ObjectMapper.java:188) at > org.apache.cassandra.utils.FBUtilities.(FBUtilities.java:74) at > org.apache.cassandra.distributed.impl.Instance.(Instance.java:144) at > org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper$$Lambda$21599/1714755496.apply(Unknown > Source) at > org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.newInstance(AbstractCluster.java:247) > at > org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.(AbstractCluster.java:226) > at > org.apache.cassandra.distributed.UpgradeableCluster.newInstanceWrapper(UpgradeableCluster.java:46) > at > org.apache.cassandra.distributed.UpgradeableCluster.newInstanceWrapper(UpgradeableCluster.java:36) > at > org.apache.cassandra.distributed.impl.AbstractCluster.newInstanceWrapperInternal(AbstractCluster.java:515) > at > org.apache.cassandra.distributed.impl.AbstractCluster.(AbstractCluster.java:470) > at > org.apache.cassandra.distributed.UpgradeableCluster.(UpgradeableCluster.java:40) > at > org.apache.cassandra.distributed.UpgradeableCluster.(UpgradeableCluster.java:36) > at > org.apache.cassandra.distributed.UpgradeableCluster$Builder.lambda$new$0(UpgradeableCluster.java:86) > at > org.apache.cassandra.distributed.UpgradeableCluster$Builder$$Lambda$73/1631826609.newCluster(Unknown > Source) at > org.apache.cassandra.distributed.shared.AbstractBuilder.createWithoutStarting(AbstractBuilder.java:158) > at > org.apache.cassandra.distributed.shared.AbstractBuilder.start(AbstractBuilder.java:140) > at > org.apache.cassandra.distributed.UpgradeableCluster.create(UpgradeableCluster.java:73) > at > org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:223) > at > org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageUpgradeTest(CompactStorageUpgradeTest.java:159) > h3. Standard Output > out of memory on output stream > > Appears consistent -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17139) readWriteDuringBootstrapTest - org.apache.cassandra.distributed.test.ring.BootstrapTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542275#comment-17542275 ] Caleb Rackliffe commented on CASSANDRA-17139: - Just hit this in https://app.circleci.com/pipelines/github/maedhroz/cassandra/411/workflows/1f8878fd-f02a-4c29-9616-5627ea94d486/jobs/3127/tests#failed-test-0 > readWriteDuringBootstrapTest - > org.apache.cassandra.distributed.test.ring.BootstrapTest > --- > > Key: CASSANDRA-17139 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17139 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 4.0.x > > > The test was seen failing in both > [CircleCI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1188/workflows/06afaf5b-6951-4b3d-8fbf-6ef2aef04e52/jobs/7025] > and > [Jenkins|https://jenkins-cm4.apache.org/job/Cassandra-4.0/267/testReport/junit/org.apache.cassandra.distributed.test.ring/BootstrapTest/readWriteDuringBootstrapTest/] > lately. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17663) Ensure FileStreamTask cannot compromise shared channel proxy for system table when interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17663:
Test and Documentation Plan: new in-JVM dtest
Status: Patch Available (was: In Progress)
The 4.1 and trunk patches are going to be a bit different, but in the mean
time, here's 4.0...
[4.0 patch|https://github.com/apache/cassandra/pull/1647]
[4.0
CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17663-4.0&filter=all]
> Ensure FileStreamTask cannot compromise shared channel proxy for system table
> when interrupted
> --
>
> Key: CASSANDRA-17663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is very similar to what we fixed in CASSANDRA-17466 , just in a
> different part of the repair/streaming machine.
> {{NettyStreamingMessageSender}} is responsible for dispatching
> {{FileStreamTask}} on an executor it manages to stream files to its peers.
> When the sender is closed for any reason, like perhaps a peer blowing up
> while deserializing the stream, the executor it manages is shut down w/
> interruption (i.e. {{shutdownNow()}}). This is problematic if we happen to
> have not gotten very far along in {{FileStreamTask#run()}}. If we're just
> about to call {{getOrCreateChannel()}}, which reads from the {{peers_v2}}
> system table, the {{ChannelProxy}} read will throw a
> {{ClosedByInterruptedException}} and the proxy will be useless. The twist is
> that, since CASSANDRA-15666, this exception has essentially been swallowed by
> {{FileStreamTask}}'s exception handling. So we don't see a
> {{ClosedByInterruptedException}} in the logs, but we do have things like this
> pop up when anything else tries to hit the peers table:
> {noformat}
> ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.cassandra.io.FSReadError:
> java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> {noformat}
> ...and...
> {noformat}
> ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[CompactionExecutor:12,1,main]
> org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
[jira] [Updated] (CASSANDRA-17663) Ensure FileStreamTask cannot compromise shared channel proxy for system table when interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17663:
Summary: Ensure FileStreamTask cannot compromise shared channel proxy for
system table when interrupted (was: Ensure that NettyStreamingMessageSender is
not vulnerable to triggering disk failure policy when file streaming tasks are
interrupted)
> Ensure FileStreamTask cannot compromise shared channel proxy for system table
> when interrupted
> --
>
> Key: CASSANDRA-17663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-alpha
>
>
> This is very similar to what we fixed in CASSANDRA-17466 , just in a
> different part of the repair/streaming machine.
> {{NettyStreamingMessageSender}} is responsible for dispatching
> {{FileStreamTask}} on an executor it manages to stream files to its peers.
> When the sender is closed for any reason, like perhaps a peer blowing up
> while deserializing the stream, the executor it manages is shut down w/
> interruption (i.e. {{shutdownNow()}}). This is problematic if we happen to
> have not gotten very far along in {{FileStreamTask#run()}}. If we're just
> about to call {{getOrCreateChannel()}}, which reads from the {{peers_v2}}
> system table, the {{ChannelProxy}} read will throw a
> {{ClosedByInterruptedException}} and the proxy will be useless. The twist is
> that, since CASSANDRA-15666, this exception has essentially been swallowed by
> {{FileStreamTask}}'s exception handling. So we don't see a
> {{ClosedByInterruptedException}} in the logs, but we do have things like this
> pop up when anything else tries to hit the peers table:
> {noformat}
> ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.cassandra.io.FSReadError:
> java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> {noformat}
> ...and...
> {noformat}
> ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[CompactionExecutor:12,1,main]
> org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.seekToCurrentRangeStart(BigTableScanner.java:196)
>
> at
> org.apache.cassandra.io.sstable.format.big.
[jira] [Commented] (CASSANDRA-17577) Add cqlsh SHOW REPLICAS by token command
[
https://issues.apache.org/jira/browse/CASSANDRA-17577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542252#comment-17542252
]
Stefan Miklosovic commented on CASSANDRA-17577:
---
I am fine with "endpoints" idea. I can do that alias in nodetool and we can
drop replicas eventually in the next release.
> Add cqlsh SHOW REPLICAS by token command
>
>
> Key: CASSANDRA-17577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17577
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> It is often useful to know when a query fails or a query is slow which nodes
> the query was routed too. For clusters with vnodes, determining this is not
> simple and requires an admin tool like 'nodetool getendpoints;.
> But, the Cassandra driver has cluster metadata which identifies which nodes
> are the replicas for a given token range. It should be straightforward to
> support this in CQLSH.
> Example with python driver:
> {quote}from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> import cassandra.metadata
> from cassandra.metadata import Murmur3Token
>
> auth_provider = PlainTextAuthProvider(username='cassandra',
> password='cassandra')
> cluster = Cluster(['127.0.0.1'], auth_provider=auth_provider)
> session = cluster.connect('tests')
> cluster.metadata.token_map.get_replicas('tests',Murmur3Token(100))
> {color:#4c9aff}>>>
> cluster.metadata.token_map.get_replicas('tests',Murmur3Token(100)){color}
> {color:#4c9aff}[]{color}
>
> {quote}
> Users shouldn't require access to an admin tool like nodetool to access the
> cluster metadata. This is especially true for Cassandra-as-a-service
> offerings like AWS keyspaces or Instaclustr's managed service.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14715) Read repairs can result in bogus timeout errors to the client
[
https://issues.apache.org/jira/browse/CASSANDRA-14715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542250#comment-17542250
]
Stefan Miklosovic commented on CASSANDRA-14715:
---
[~brandon.williams] Not really, honestly, I forgot this one completely. I can
take a look, indeed, sometimes next week.
> Read repairs can result in bogus timeout errors to the client
> -
>
> Key: CASSANDRA-14715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14715
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Low
>
> In RepairMergeListener:close() it does the following:
>
> {code:java}
> try
> {
> FBUtilities.waitOnFutures(repairResults,
> DatabaseDescriptor.getWriteRpcTimeout());
> }
> catch (TimeoutException ex)
> {
> // We got all responses, but timed out while repairing
> int blockFor = consistency.blockFor(keyspace);
> if (Tracing.isTracing())
> Tracing.trace("Timed out while read-repairing after receiving all {}
> data and digest responses", blockFor);
> else
> logger.debug("Timeout while read-repairing after receiving all {}
> data and digest responses", blockFor);
> throw new ReadTimeoutException(consistency, blockFor-1, blockFor, true);
> }
> {code}
> This propagates up and gets sent to the client and we have customers get
> confused cause they see timeouts for CL ALL requiring ALL replicas even
> though they have read_repair_chance = 0 and using a LOCAL_* CL.
> At minimum I suggest instead of using the consistency level of DataResolver
> (which is always ALL with read repairs) for the timeout it instead use
> repairResults.size(). That is blockFor = repairResults.size() . But saying it
> received _blockFor - 1_ is bogus still. Fixing that would require more
> changes. I was thinking maybe like so:
>
> {code:java}
> public static void waitOnFutures(List results, long ms,
> MutableInt counter) throws TimeoutException
> {
> for (AsyncOneResponse result : results)
> {
> result.get(ms, TimeUnit.MILLISECONDS);
> counter.increment();
> }
> }
> {code}
>
>
>
> Likewise in SinglePartitionReadLifecycle:maybeAwaitFullDataRead() it says
> _blockFor - 1_ for how many were received, which is also bogus.
>
> Steps used to reproduce was modify RepairMergeListener:close() to always
> throw timeout exception. With schema:
> {noformat}
> CREATE KEYSPACE weather WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': '3', 'dc2': '3'} AND durable_writes = true;
> CREATE TABLE weather.city (
> cityid int PRIMARY KEY,
> name text
> ) WITH bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.0
> AND read_repair_chance = 0.0
> AND speculative_retry = 'NONE';
> {noformat}
> Then using the following steps:
> # ccm node1 cqlsh
> # INSERT INTO weather.city(cityid, name) VALUES (1, 'Canberra');
> # exit;
> # ccm node1 flush
> # ccm node1 stop
> # rm -rf
> ~/.ccm/test_repair/node1/data0/weather/city-ff2fade0b18d11e8b1cd097acbab1e3d/mc-1-big-*
> # remove the sstable with the insert
> # ccm node1 start
> # ccm node1 cqlsh
> # CONSISTENCY LOCAL_QUORUM;
> # select * from weather.city where cityid = 1;
> You get result of:
> {noformat}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 5
> responses." info={'received_responses': 5, 'required_responses': 6,
> 'consistency': 'ALL'}{noformat}
> But was expecting:
> {noformat}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 1
> responses." info={'received_responses': 1, 'required_responses': 2,
> 'consistency': 'LOCAL_QUORUM'}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17663) Ensure that NettyStreamingMessageSender is not vulnerable to triggering disk failure policy when file streaming tasks are interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542243#comment-17542243
]
Caleb Rackliffe commented on CASSANDRA-17663:
-
Given CASSANDRA-17648 already exists, I'd like to defer 3.x work on this issue
there. `RepairErrorsTest`, for example, does not yet exist in 3.x, and I'd like
to move it over in its entirety.
> Ensure that NettyStreamingMessageSender is not vulnerable to triggering disk
> failure policy when file streaming tasks are interrupted
> -
>
> Key: CASSANDRA-17663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-alpha
>
>
> This is very similar to what we fixed in CASSANDRA-17466 , just in a
> different part of the repair/streaming machine.
> {{NettyStreamingMessageSender}} is responsible for dispatching
> {{FileStreamTask}} on an executor it manages to stream files to its peers.
> When the sender is closed for any reason, like perhaps a peer blowing up
> while deserializing the stream, the executor it manages is shut down w/
> interruption (i.e. {{shutdownNow()}}). This is problematic if we happen to
> have not gotten very far along in {{FileStreamTask#run()}}. If we're just
> about to call {{getOrCreateChannel()}}, which reads from the {{peers_v2}}
> system table, the {{ChannelProxy}} read will throw a
> {{ClosedByInterruptedException}} and the proxy will be useless. The twist is
> that, since CASSANDRA-15666, this exception has essentially been swallowed by
> {{FileStreamTask}}'s exception handling. So we don't see a
> {{ClosedByInterruptedException}} in the logs, but we do have things like this
> pop up when anything else tries to hit the peers table:
> {noformat}
> ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.cassandra.io.FSReadError:
> java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> {noformat}
> ...and...
> {noformat}
> ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[CompactionExecutor:12,1,main]
> org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.seekToCurrentRangeStart(BigTableScan
[jira] [Comment Edited] (CASSANDRA-17648) Backport CASSANDRA-17466 and CASSANDRA-17663 to 3.0 and 3.11
[ https://issues.apache.org/jira/browse/CASSANDRA-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542241#comment-17542241 ] Caleb Rackliffe edited comment on CASSANDRA-17648 at 5/25/22 9:16 PM: -- Given the large amount of conceptual overlap, I'd like to defer work on CASSANDRA-17663 for 3.x to this ticket as well. was (Author: maedhroz): Given that large amount of conceptual overlap, I'd like to defer work on CASSANDRA-17663 for 3.x to this ticket. > Backport CASSANDRA-17466 and CASSANDRA-17663 to 3.0 and 3.11 > > > Key: CASSANDRA-17648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17648 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: David Capwell >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > CASSANDRA-17466 was fixed in 4.0+ but not 3.x. This bug would close SSTables > leaving the cluster in a bad state and needing to be restarted in order to > recover -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17656) jvm-dtest upgrade tests run all supported pairs of upgrades between from/to but does not actually test all patches from/to
[
https://issues.apache.org/jira/browse/CASSANDRA-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542242#comment-17542242
]
David Capwell commented on CASSANDRA-17656:
---
waiting on [~mck] to confirm he is cool with this before committing.
> jvm-dtest upgrade tests run all supported pairs of upgrades between from/to
> but does not actually test all patches from/to
> --
>
> Key: CASSANDRA-17656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17656
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The current upgrade from/to logic is based off a list filter on from/to
> pairs, and runs the test multiple times for each pair; this does not actually
> validate that the different paths upgrade cleanly.
> Instead, we need to test each supported path; example 3.0 -> 4.2
> {code}
> 3.0.28 -> [4.2]
> 3.0.28 -> [3.11.14, 4.2]
> 3.0.28 -> [4.1-alpha1, 4.2]
> 3.0.28 -> [4.0.5, 4.2]
> 3.0.28 -> [3.11.14, 4.1-alpha1, 4.2]
> 3.0.28 -> [3.11.14, 4.0.5, 4.2]
> 3.0.28 -> [4.0.5, 4.1-alpha1, 4.2]
> 3.0.28 -> [3.11.14, 4.0.5, 4.1-alpha1, 4.2]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-17648) Backport CASSANDRA-17466 and CASSANDRA-17663 to 3.0 and 3.11
[ https://issues.apache.org/jira/browse/CASSANDRA-17648 ] Caleb Rackliffe deleted comment on CASSANDRA-17648: - was (Author: maedhroz): Given the large amount of conceptual overlap, I'd like to also defer 3.x work on CASSANDRA-17663 to this ticket. > Backport CASSANDRA-17466 and CASSANDRA-17663 to 3.0 and 3.11 > > > Key: CASSANDRA-17648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17648 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: David Capwell >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > CASSANDRA-17466 was fixed in 4.0+ but not 3.x. This bug would close SSTables > leaving the cluster in a bad state and needing to be restarted in order to > recover -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17648) Backport CASSANDRA-17466 and CASSANDRA-17663 to 3.0 and 3.11
[ https://issues.apache.org/jira/browse/CASSANDRA-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17648: Summary: Backport CASSANDRA-17466 and CASSANDRA-17663 to 3.0 and 3.11 (was: Backport CASSANDRA-17466 to 3.0 and 3.11) > Backport CASSANDRA-17466 and CASSANDRA-17663 to 3.0 and 3.11 > > > Key: CASSANDRA-17648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17648 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: David Capwell >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > CASSANDRA-17466 was fixed in 4.0+ but not 3.x. This bug would close SSTables > leaving the cluster in a bad state and needing to be restarted in order to > recover -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17648) Backport CASSANDRA-17466 to 3.0 and 3.11
[ https://issues.apache.org/jira/browse/CASSANDRA-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542241#comment-17542241 ] Caleb Rackliffe commented on CASSANDRA-17648: - Given that large amount of conceptual overlap, I'd like to defer work on CASSANDRA-17663 for 3.x to this ticket. > Backport CASSANDRA-17466 to 3.0 and 3.11 > > > Key: CASSANDRA-17648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17648 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: David Capwell >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > CASSANDRA-17466 was fixed in 4.0+ but not 3.x. This bug would close SSTables > leaving the cluster in a bad state and needing to be restarted in order to > recover -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17648) Backport CASSANDRA-17466 to 3.0 and 3.11
[ https://issues.apache.org/jira/browse/CASSANDRA-17648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542240#comment-17542240 ] Caleb Rackliffe commented on CASSANDRA-17648: - Given the large amount of conceptual overlap, I'd like to also defer 3.x work on CASSANDRA-17663 to this ticket. > Backport CASSANDRA-17466 to 3.0 and 3.11 > > > Key: CASSANDRA-17648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17648 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: David Capwell >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > CASSANDRA-17466 was fixed in 4.0+ but not 3.x. This bug would close SSTables > leaving the cluster in a bad state and needing to be restarted in order to > recover -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17660) jvm-dtest upgrade failures due to 3.x Ping not allowing serialize
[
https://issues.apache.org/jira/browse/CASSANDRA-17660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17660:
--
Fix Version/s: 3.0.28
3.11.14
(was: 4.1.x)
Since Version: 4.0
Source Control Link:
https://github.com/apache/cassandra/commit/c374183c094a49b1f847abfe5ca3fefc210a70dc
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> jvm-dtest upgrade failures due to 3.x Ping not allowing serialize
> -
>
> Key: CASSANDRA-17660
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17660
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.28, 3.11.14
>
>
> trunk jvm upgrade tests periodically fail due to the ping message not being
> able to be serialized on 3.x branches. We need support for jvm-dtest even if
> we ignore the messages.
> {code}
> Suppressed: java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.net.PingMessage$PingMessageSerializer.serialize(PingMessage.java:45)
> at
> org.apache.cassandra.net.PingMessage$PingMessageSerializer.serialize(PingMessage.java:41)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:362)
> at
> org.apache.cassandra.distributed.impl.Instance$1.allowIncomingMessage(Instance.java:302)
> at
> org.apache.cassandra.net.MessagingService.receive(MessagingService.java:866)
> at
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:224)
> at
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:193)
> at
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:96)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (00250199c0 -> a849dbb458)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 00250199c0 Merge branch 'cassandra-4.0' into cassandra-4.1 new fb8bf30c6d jvm-dtest upgrade failures due to 3.x Ping not allowing serialize new 76648a6534 Merge branch 'cassandra-3.0' into cassandra-3.11 new 68406f07e4 Merge branch 'cassandra-3.11' into cassandra-4.0 new a849dbb458 Merge branch 'cassandra-4.0' into cassandra-4.1 The 4 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (e9edf16c7f -> dcf3d58c4b)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from e9edf16c7f Update changes for 17470 new fb8bf30c6d jvm-dtest upgrade failures due to 3.x Ping not allowing serialize new 76648a6534 Merge branch 'cassandra-3.0' into cassandra-3.11 new 68406f07e4 Merge branch 'cassandra-3.11' into cassandra-4.0 new a849dbb458 Merge branch 'cassandra-4.0' into cassandra-4.1 new dcf3d58c4b Merge branch 'cassandra-4.1' into trunk The 5 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: - 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 (0e1d068d92 -> 76648a6534)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 0e1d068d92 Merge branch 'cassandra-3.0' into cassandra-3.11 new fb8bf30c6d jvm-dtest upgrade failures due to 3.x Ping not allowing serialize new 76648a6534 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: src/java/org/apache/cassandra/net/PingMessage.java | 18 +- 1 file changed, 13 insertions(+), 5 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-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit dcf3d58c4b22b8b69e8505b170829172ea3c4f5c Merge: e9edf16c7f a849dbb458 Author: David Capwell AuthorDate: Wed May 25 14:06:27 2022 -0700 Merge branch 'cassandra-4.1' into trunk - 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 cassandra-4.1
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit a849dbb458debf9a2d98ef5a08387917bffe6c36 Merge: 00250199c0 68406f07e4 Author: David Capwell AuthorDate: Wed May 25 14:03:30 2022 -0700 Merge branch 'cassandra-4.0' into cassandra-4.1 - 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-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 68406f07e424bb8f84fd11ba19d37513c1840a91 Merge: 7ea24711cc 76648a6534 Author: David Capwell AuthorDate: Wed May 25 14:01:41 2022 -0700 Merge branch 'cassandra-3.11' into cassandra-4.0 - 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-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 76648a6534845765e5f79db5d7a9f60ec347c98b Merge: 0e1d068d92 fb8bf30c6d Author: David Capwell AuthorDate: Wed May 25 14:00:18 2022 -0700 Merge branch 'cassandra-3.0' into cassandra-3.11 src/java/org/apache/cassandra/net/PingMessage.java | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) - 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 (7ea24711cc -> 68406f07e4)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 7ea24711cc silence benign SslClosedEngineException new fb8bf30c6d jvm-dtest upgrade failures due to 3.x Ping not allowing serialize new 76648a6534 Merge branch 'cassandra-3.0' into cassandra-3.11 new 68406f07e4 Merge branch 'cassandra-3.11' into cassandra-4.0 The 3 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: - 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: jvm-dtest upgrade failures due to 3.x Ping not allowing serialize
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new fb8bf30c6d jvm-dtest upgrade failures due to 3.x Ping not allowing
serialize
fb8bf30c6d is described below
commit fb8bf30c6d1b6f893a77a74b9e8b4223e5497dd4
Author: David Capwell
AuthorDate: Wed May 25 11:39:41 2022 -0700
jvm-dtest upgrade failures due to 3.x Ping not allowing serialize
patch by David Capwell; reviewed by Jon Meredith for CASSANDRA-17660
---
src/java/org/apache/cassandra/net/PingMessage.java | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/src/java/org/apache/cassandra/net/PingMessage.java
b/src/java/org/apache/cassandra/net/PingMessage.java
index 8eaf23ed93..d3a4322a30 100644
--- a/src/java/org/apache/cassandra/net/PingMessage.java
+++ b/src/java/org/apache/cassandra/net/PingMessage.java
@@ -38,20 +38,28 @@ public class PingMessage
{
public static IVersionedSerializer serializer = new
PingMessageSerializer();
+private final int connectionType;
+
+public PingMessage(int connectionType)
+{
+this.connectionType = connectionType;
+}
+
public static class PingMessageSerializer implements
IVersionedSerializer
{
-public void serialize(PingMessage t, DataOutputPlus out, int version)
+@Override
+public void serialize(PingMessage t, DataOutputPlus out, int version)
throws IOException
{
-throw new UnsupportedOperationException();
+out.writeByte(t.connectionType);
}
+@Override
public PingMessage deserialize(DataInputPlus in, int version) throws
IOException
{
-// throw away the one byte of the payload
-in.readByte();
-return new PingMessage();
+return new PingMessage(in.readByte());
}
+@Override
public long serializedSize(PingMessage t, int version)
{
return 1;
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14715) Read repairs can result in bogus timeout errors to the client
[
https://issues.apache.org/jira/browse/CASSANDRA-14715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542215#comment-17542215
]
Brandon Williams commented on CASSANDRA-14715:
--
[~stefan.miklosovic] is this still on your radar?
> Read repairs can result in bogus timeout errors to the client
> -
>
> Key: CASSANDRA-14715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14715
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Low
>
> In RepairMergeListener:close() it does the following:
>
> {code:java}
> try
> {
> FBUtilities.waitOnFutures(repairResults,
> DatabaseDescriptor.getWriteRpcTimeout());
> }
> catch (TimeoutException ex)
> {
> // We got all responses, but timed out while repairing
> int blockFor = consistency.blockFor(keyspace);
> if (Tracing.isTracing())
> Tracing.trace("Timed out while read-repairing after receiving all {}
> data and digest responses", blockFor);
> else
> logger.debug("Timeout while read-repairing after receiving all {}
> data and digest responses", blockFor);
> throw new ReadTimeoutException(consistency, blockFor-1, blockFor, true);
> }
> {code}
> This propagates up and gets sent to the client and we have customers get
> confused cause they see timeouts for CL ALL requiring ALL replicas even
> though they have read_repair_chance = 0 and using a LOCAL_* CL.
> At minimum I suggest instead of using the consistency level of DataResolver
> (which is always ALL with read repairs) for the timeout it instead use
> repairResults.size(). That is blockFor = repairResults.size() . But saying it
> received _blockFor - 1_ is bogus still. Fixing that would require more
> changes. I was thinking maybe like so:
>
> {code:java}
> public static void waitOnFutures(List results, long ms,
> MutableInt counter) throws TimeoutException
> {
> for (AsyncOneResponse result : results)
> {
> result.get(ms, TimeUnit.MILLISECONDS);
> counter.increment();
> }
> }
> {code}
>
>
>
> Likewise in SinglePartitionReadLifecycle:maybeAwaitFullDataRead() it says
> _blockFor - 1_ for how many were received, which is also bogus.
>
> Steps used to reproduce was modify RepairMergeListener:close() to always
> throw timeout exception. With schema:
> {noformat}
> CREATE KEYSPACE weather WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': '3', 'dc2': '3'} AND durable_writes = true;
> CREATE TABLE weather.city (
> cityid int PRIMARY KEY,
> name text
> ) WITH bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.0
> AND read_repair_chance = 0.0
> AND speculative_retry = 'NONE';
> {noformat}
> Then using the following steps:
> # ccm node1 cqlsh
> # INSERT INTO weather.city(cityid, name) VALUES (1, 'Canberra');
> # exit;
> # ccm node1 flush
> # ccm node1 stop
> # rm -rf
> ~/.ccm/test_repair/node1/data0/weather/city-ff2fade0b18d11e8b1cd097acbab1e3d/mc-1-big-*
> # remove the sstable with the insert
> # ccm node1 start
> # ccm node1 cqlsh
> # CONSISTENCY LOCAL_QUORUM;
> # select * from weather.city where cityid = 1;
> You get result of:
> {noformat}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 5
> responses." info={'received_responses': 5, 'required_responses': 6,
> 'consistency': 'ALL'}{noformat}
> But was expecting:
> {noformat}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 1
> responses." info={'received_responses': 1, 'required_responses': 2,
> 'consistency': 'LOCAL_QUORUM'}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14715) Read repairs can result in bogus timeout errors to the client
[
https://issues.apache.org/jira/browse/CASSANDRA-14715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542210#comment-17542210
]
Jai Bheemsen Rao Dhanwada commented on CASSANDRA-14715:
---
Any plans to fix this in the upcoming versions or atleast 4.0.x version? the
error message is quite mis-leading.
> Read repairs can result in bogus timeout errors to the client
> -
>
> Key: CASSANDRA-14715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14715
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Low
>
> In RepairMergeListener:close() it does the following:
>
> {code:java}
> try
> {
> FBUtilities.waitOnFutures(repairResults,
> DatabaseDescriptor.getWriteRpcTimeout());
> }
> catch (TimeoutException ex)
> {
> // We got all responses, but timed out while repairing
> int blockFor = consistency.blockFor(keyspace);
> if (Tracing.isTracing())
> Tracing.trace("Timed out while read-repairing after receiving all {}
> data and digest responses", blockFor);
> else
> logger.debug("Timeout while read-repairing after receiving all {}
> data and digest responses", blockFor);
> throw new ReadTimeoutException(consistency, blockFor-1, blockFor, true);
> }
> {code}
> This propagates up and gets sent to the client and we have customers get
> confused cause they see timeouts for CL ALL requiring ALL replicas even
> though they have read_repair_chance = 0 and using a LOCAL_* CL.
> At minimum I suggest instead of using the consistency level of DataResolver
> (which is always ALL with read repairs) for the timeout it instead use
> repairResults.size(). That is blockFor = repairResults.size() . But saying it
> received _blockFor - 1_ is bogus still. Fixing that would require more
> changes. I was thinking maybe like so:
>
> {code:java}
> public static void waitOnFutures(List results, long ms,
> MutableInt counter) throws TimeoutException
> {
> for (AsyncOneResponse result : results)
> {
> result.get(ms, TimeUnit.MILLISECONDS);
> counter.increment();
> }
> }
> {code}
>
>
>
> Likewise in SinglePartitionReadLifecycle:maybeAwaitFullDataRead() it says
> _blockFor - 1_ for how many were received, which is also bogus.
>
> Steps used to reproduce was modify RepairMergeListener:close() to always
> throw timeout exception. With schema:
> {noformat}
> CREATE KEYSPACE weather WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': '3', 'dc2': '3'} AND durable_writes = true;
> CREATE TABLE weather.city (
> cityid int PRIMARY KEY,
> name text
> ) WITH bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.0
> AND read_repair_chance = 0.0
> AND speculative_retry = 'NONE';
> {noformat}
> Then using the following steps:
> # ccm node1 cqlsh
> # INSERT INTO weather.city(cityid, name) VALUES (1, 'Canberra');
> # exit;
> # ccm node1 flush
> # ccm node1 stop
> # rm -rf
> ~/.ccm/test_repair/node1/data0/weather/city-ff2fade0b18d11e8b1cd097acbab1e3d/mc-1-big-*
> # remove the sstable with the insert
> # ccm node1 start
> # ccm node1 cqlsh
> # CONSISTENCY LOCAL_QUORUM;
> # select * from weather.city where cityid = 1;
> You get result of:
> {noformat}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 5
> responses." info={'received_responses': 5, 'required_responses': 6,
> 'consistency': 'ALL'}{noformat}
> But was expecting:
> {noformat}
> ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting
> for replica nodes' responses] message="Operation timed out - received only 1
> responses." info={'received_responses': 1, 'required_responses': 2,
> 'consistency': 'LOCAL_QUORUM'}{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17661) Adding support to perform certificate based internode authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-17661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17661: - Change Category: Operability Complexity: Normal Component/s: Messaging/Internode Fix Version/s: 4.x Status: Open (was: Triage Needed) > Adding support to perform certificate based internode authentication > > > Key: CASSANDRA-17661 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17661 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > > Changes are to be made in IInternodeAuthenticator interface to support > certificate based authentication and to add a new pipeline in > InboundConnectionInitiator should be added to perform certificate based > authentication for internode communications. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17660) jvm-dtest upgrade failures due to 3.x Ping not allowing serialize
[
https://issues.apache.org/jira/browse/CASSANDRA-17660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542198#comment-17542198
]
David Capwell commented on CASSANDRA-17660:
---
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|cassandra-3.0|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17660-cassandra-3.0-63BB7235-B29B-4A6D-889C-00208CD02BB9]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17660-cassandra-3.0-63BB7235-B29B-4A6D-889C-00208CD02BB9]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1735/]|
|cassandra-3.11|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17660-cassandra-3.11-63BB7235-B29B-4A6D-889C-00208CD02BB9]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17660-cassandra-3.11-63BB7235-B29B-4A6D-889C-00208CD02BB9]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1736/]|
> jvm-dtest upgrade failures due to 3.x Ping not allowing serialize
> -
>
> Key: CASSANDRA-17660
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17660
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
>
> trunk jvm upgrade tests periodically fail due to the ping message not being
> able to be serialized on 3.x branches. We need support for jvm-dtest even if
> we ignore the messages.
> {code}
> Suppressed: java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.net.PingMessage$PingMessageSerializer.serialize(PingMessage.java:45)
> at
> org.apache.cassandra.net.PingMessage$PingMessageSerializer.serialize(PingMessage.java:41)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:362)
> at
> org.apache.cassandra.distributed.impl.Instance$1.allowIncomingMessage(Instance.java:302)
> at
> org.apache.cassandra.net.MessagingService.receive(MessagingService.java:866)
> at
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:224)
> at
> org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:193)
> at
> org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:96)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17656) jvm-dtest upgrade tests run all supported pairs of upgrades between from/to but does not actually test all patches from/to
[
https://issues.apache.org/jira/browse/CASSANDRA-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542189#comment-17542189
]
Jon Meredith commented on CASSANDRA-17656:
--
+1
> jvm-dtest upgrade tests run all supported pairs of upgrades between from/to
> but does not actually test all patches from/to
> --
>
> Key: CASSANDRA-17656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17656
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The current upgrade from/to logic is based off a list filter on from/to
> pairs, and runs the test multiple times for each pair; this does not actually
> validate that the different paths upgrade cleanly.
> Instead, we need to test each supported path; example 3.0 -> 4.2
> {code}
> 3.0.28 -> [4.2]
> 3.0.28 -> [3.11.14, 4.2]
> 3.0.28 -> [4.1-alpha1, 4.2]
> 3.0.28 -> [4.0.5, 4.2]
> 3.0.28 -> [3.11.14, 4.1-alpha1, 4.2]
> 3.0.28 -> [3.11.14, 4.0.5, 4.2]
> 3.0.28 -> [4.0.5, 4.1-alpha1, 4.2]
> 3.0.28 -> [3.11.14, 4.0.5, 4.1-alpha1, 4.2]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17647) Add guardrail to disallow usage of SimpleStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-17647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542179#comment-17542179 ] Brandon Williams edited comment on CASSANDRA-17647 at 5/25/22 6:23 PM: --- Should we disable SimpleSnitch with this too since it's only useful with SimpleStrategy? was (Author: brandon.williams): Should we disable SimpleSnitch with this too since it's only useful with SimpleStrategy?? > Add guardrail to disallow usage of SimpleStrategy > - > > Key: CASSANDRA-17647 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17647 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > It would be useful for operators to be able to disallow the usage of > SImpleStrategy accidentally by their users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17647) Add guardrail to disallow usage of SimpleStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-17647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542179#comment-17542179 ] Brandon Williams commented on CASSANDRA-17647: -- Should we disable SimpleSnitch with this too since it's only useful with SimpleStrategy?? > Add guardrail to disallow usage of SimpleStrategy > - > > Key: CASSANDRA-17647 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17647 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > It would be useful for operators to be able to disallow the usage of > SImpleStrategy accidentally by their users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17647) Add guardrail to disallow usage of SimpleStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-17647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17647: -- Reviewers: Aleksey Yeschenko > Add guardrail to disallow usage of SimpleStrategy > - > > Key: CASSANDRA-17647 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17647 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > It would be useful for operators to be able to disallow the usage of > SImpleStrategy accidentally by their users. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17663) Ensure that NettyStreamingMessageSender is not vulnerable to triggering disk failure policy when file streaming tasks are interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17663:
Bug Category: Parent values: Availability(12983)Level 1 values: Process
Crash(12992)
Complexity: Normal
Component/s: Consistency/Repair
Consistency/Streaming
Discovered By: User Report
Fix Version/s: 4.0.x
4.1-alpha
Reviewers: Jon Meredith, Marcus Eriksson
Severity: Critical
Status: Open (was: Triage Needed)
> Ensure that NettyStreamingMessageSender is not vulnerable to triggering disk
> failure policy when file streaming tasks are interrupted
> -
>
> Key: CASSANDRA-17663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.1-alpha
>
>
> This is very similar to what we fixed in CASSANDRA-17466 , just in a
> different part of the repair/streaming machine.
> {{NettyStreamingMessageSender}} is responsible for dispatching
> {{FileStreamTask}} on an executor it manages to stream files to its peers.
> When the sender is closed for any reason, like perhaps a peer blowing up
> while deserializing the stream, the executor it manages is shut down w/
> interruption (i.e. {{shutdownNow()}}). This is problematic if we happen to
> have not gotten very far along in {{FileStreamTask#run()}}. If we're just
> about to call {{getOrCreateChannel()}}, which reads from the {{peers_v2}}
> system table, the {{ChannelProxy}} read will throw a
> {{ClosedByInterruptedException}} and the proxy will be useless. The twist is
> that, since CASSANDRA-15666, this exception has essentially been swallowed by
> {{FileStreamTask}}'s exception handling. So we don't see a
> {{ClosedByInterruptedException}} in the logs, but we do have things like this
> pop up when anything else tries to hit the peers table:
> {noformat}
> ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[AntiEntropyStage:1,5,main]
> java.lang.RuntimeException: FSReadError in
> .../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.cassandra.io.FSReadError:
> java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
>
> at
> org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
> {noformat}
> ...and...
> {noformat}
> ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
> org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
> Thread[CompactionExecutor:12,1,main]
> org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
> at
> org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
>
> at
> org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
>
> at
> org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
>
> at
> org.apache.cassandra.io.util.RandomAccessRead
[jira] [Updated] (CASSANDRA-17663) Ensure that NettyStreamingMessageSender is not vulnerable to triggering disk failure policy when file streaming tasks are interrupted
[
https://issues.apache.org/jira/browse/CASSANDRA-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17663:
Description:
This is very similar to what we fixed in CASSANDRA-17466 , just in a different
part of the repair/streaming machine.
{{NettyStreamingMessageSender}} is responsible for dispatching
{{FileStreamTask}} on an executor it manages to stream files to its peers. When
the sender is closed for any reason, like perhaps a peer blowing up while
deserializing the stream, the executor it manages is shut down w/ interruption
(i.e. {{shutdownNow()}}). This is problematic if we happen to have not gotten
very far along in {{FileStreamTask#run()}}. If we're just about to call
{{getOrCreateChannel()}}, which reads from the {{peers_v2}} system table, the
{{ChannelProxy}} read will throw a {{ClosedByInterruptedException}} and the
proxy will be useless. The twist is that, since CASSANDRA-15666, this exception
has essentially been swallowed by {{FileStreamTask}}'s exception handling. So
we don't see a {{ClosedByInterruptedException}} in the logs, but we do have
things like this pop up when anything else tries to hit the peers table:
{noformat}
ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
Thread[AntiEntropyStage:1,5,main]
java.lang.RuntimeException: FSReadError in
.../data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
at
org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-all-4.1.58.Final.jar:4.1.58.Final]
at java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.cassandra.io.FSReadError:
java.nio.channels.ClosedChannelException
at
org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
at
org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
at
org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
at
org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
at
org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
at
org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
{noformat}
...and...
{noformat}
ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
Thread[CompactionExecutor:12,1,main]
org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
at
org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
at
org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
at
org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
at
org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
at
org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner.seekToCurrentRangeStart(BigTableScanner.java:196)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner.access$400(BigTableScanner.java:52)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:305)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:282)
at
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:46)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:261)
{noformat}
...which obviously get us into trouble w/ the disk failure policy.
The fix proposed here is just to get the peers table read out of the thread
that can be interrupted. Specifically, {{NettyStreamingMessageSender}}
materializes a {{connectTo}} address at stream task creation time. This seemed
a better option than making shutdown non-interrupting, since that would mean
changing how the actual file streaming responds to shutdown.
was:
This is very si
[jira] [Created] (CASSANDRA-17663) Ensure that NettyStreamingMessageSender is not vulnerable to triggering disk failure policy when file streaming tasks are interrupted
Caleb Rackliffe created CASSANDRA-17663:
---
Summary: Ensure that NettyStreamingMessageSender is not vulnerable
to triggering disk failure policy when file streaming tasks are interrupted
Key: CASSANDRA-17663
URL: https://issues.apache.org/jira/browse/CASSANDRA-17663
Project: Cassandra
Issue Type: Bug
Reporter: Caleb Rackliffe
Assignee: Caleb Rackliffe
This is very similar to what we fixed in CASSANDRA-17466 , just in a different
part of the repair/streaming machine.
{{NettyStreamingMessageSender}} is responsible for dispatching
{{FileStreamTask}} on an executor it manages to stream files to its peers. When
the sender is closed for any reason, like perhaps a peer blowing up while
deserializing the stream, the executor it manages is shut down w/ interruption
(i.e. {{shutdownNow()}}). This is problematic if we happen to have not gotten
very far along in {{FileStreamTask#run()}}. If we're just about to call
{{getOrCreateChannel()}}, which reads from the {{peers_v2}} system table, the
{{ChannelProxy}} read will throw a {{ClosedByInterruptedException}} and the
proxy will be useless. The twist is that, since CASSANDRA-15666, this exception
has essentially been swallowed by {{FileStreamTask}}'s exception handling. So
we don't see a {{ClosedByInterruptedException}} in the logs, but we do have
things like this pop up when anything else tries to hit the peers table:
{noformat}
ERROR 2022-05-19T21:49:23,218 [AntiEntropyStage:1]
org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
Thread[AntiEntropyStage:1,5,main]
java.lang.RuntimeException: FSReadError in
/cassandra/d3/data/system/peers_v2-c4325fbb8e5e3bafbd070f9250ed818e/system-peers_v2-nb-101-big-Data.db
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
at
org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-all-4.1.58.Final.jar:4.1.58.Final]
at java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.cassandra.io.FSReadError:
java.nio.channels.ClosedChannelException
at
org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
at
org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
at
org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
at
org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
at
org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
at
org.apache.cassandra.io.util.FileHandle.createReader(FileHandle.java:151)
{noformat}
...and...
{noformat}
ERROR 2022-05-19T22:06:20,175 [CompactionExecutor:12]
org.apache.cassandra.service.CassandraDaemon:601 - Exception in thread
Thread[CompactionExecutor:12,1,main]
org.apache.cassandra.io.FSReadError: java.nio.channels.ClosedChannelException
at
org.apache.cassandra.io.util.ChannelProxy.read(ChannelProxy.java:143)
at
org.apache.cassandra.io.util.CompressedChunkReader$Standard.readChunk(CompressedChunkReader.java:115)
at
org.apache.cassandra.io.util.BufferManagingRebufferer.rebuffer(BufferManagingRebufferer.java:79)
at
org.apache.cassandra.io.util.RandomAccessReader.reBufferAt(RandomAccessReader.java:68)
at
org.apache.cassandra.io.util.RandomAccessReader.seek(RandomAccessReader.java:210)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner.seekToCurrentRangeStart(BigTableScanner.java:196)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner.access$400(BigTableScanner.java:52)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:305)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:282)
at
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:46)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:261)
{noformat}
...which obviously get us into trouble w/ the disk failure policy.
The fix proposed here is just to get the peers table read out of the thread
that can be interrupted. Specifically, {{Nett
[jira] [Commented] (CASSANDRA-17659) Mention some undocumented behaviors of native protocol v5
[ https://issues.apache.org/jira/browse/CASSANDRA-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542108#comment-17542108 ] Andrea Leopardi commented on CASSANDRA-17659: - [~samt] absolutely no objections, the changes look great to me. (y) Thank you! > Mention some undocumented behaviors of native protocol v5 > - > > Key: CASSANDRA-17659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17659 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Andrea Leopardi >Assignee: Andrea Leopardi >Priority: Normal > Fix For: 4.x > > Attachments: 17659-trunk.txt > > > [Patch as a GitHub PR to my own > fork|https://github.com/whatyouhide/cassandra/pull/1] > Some things in the native protocol v5 are undocumented: > * Integers in the outer framing format are little endian > * There is no mention of the parameters used to tweak the CRC24 algorithm > * No mention of the fact that if the uncompressed payload length in Section > 2.2 is 0, then the "compressed payload" should not be decompressed -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (83c6ef87 -> 2e077123)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit 83c6ef87 generate docs for 17718e18 new 2e077123 generate docs for 17718e18 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (83c6ef87) \ N -- N -- N refs/heads/asf-staging (2e077123) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17662) Link to dtests is incorrect on the website
[ https://issues.apache.org/jira/browse/CASSANDRA-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17662: - Summary: Link to dtests is incorrect on the website (was: Link to dtests in incorrect on the website) > Link to dtests is incorrect on the website > -- > > Key: CASSANDRA-17662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17662 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Brandon Williams >Priority: Normal > > This page: https://cassandra.apache.org/_/development/ci.html > links to https://github.com/riptano/cassandra-dtest but should link > https://github.com/apache/cassandra-dtest -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17662) Link to dtests in incorrect on the website
[ https://issues.apache.org/jira/browse/CASSANDRA-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17662: - Bug Category: Parent values: Documentation(13562) Complexity: Low Hanging Fruit Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Link to dtests in incorrect on the website > -- > > Key: CASSANDRA-17662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17662 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Brandon Williams >Priority: Normal > > This page: https://cassandra.apache.org/_/development/ci.html > links to https://github.com/riptano/cassandra-dtest but should link > https://github.com/apache/cassandra-dtest -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17662) Link to dtests in incorrect on the website
Brandon Williams created CASSANDRA-17662: Summary: Link to dtests in incorrect on the website Key: CASSANDRA-17662 URL: https://issues.apache.org/jira/browse/CASSANDRA-17662 Project: Cassandra Issue Type: Bug Components: Legacy/Documentation and Website Reporter: Brandon Williams This page: https://cassandra.apache.org/_/development/ci.html links to https://github.com/riptano/cassandra-dtest but should link https://github.com/apache/cassandra-dtest -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15511:
---
Test and Documentation Plan: The changes are covered by exisitng unit tests
(was: AtomicBTreePartitionUpdateBench included. Some unit tests to come.)
Status: Patch Available (was: In Progress)
The PR for the 4.0 branch can be found
[here|https://github.com/apache/cassandra/pull/1646] and the CI results can be
found
[here|https://app.circleci.com/pipelines/github/blerer/cassandra/300/workflows/6950b3c5-168b-43c4-a9d8-a16bdcace345]
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17659) Mention some undocumented behaviors of native protocol v5
[ https://issues.apache.org/jira/browse/CASSANDRA-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542087#comment-17542087 ] Sam Tunnicliffe commented on CASSANDRA-17659: - Thanks for the patch [~whatyouhide] , that's a definite improvement. I fixed a typo and tweaked a couple of sentences [here|https://github.com/beobal/cassandra/commit/50667f4c48ac263827bea188d1da36bbe4dfd199], if you have no objections I'll commit that shortly (this will go to 4.0, 4.1 & trunk). > Mention some undocumented behaviors of native protocol v5 > - > > Key: CASSANDRA-17659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17659 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Andrea Leopardi >Assignee: Andrea Leopardi >Priority: Normal > Fix For: 4.x > > Attachments: 17659-trunk.txt > > > [Patch as a GitHub PR to my own > fork|https://github.com/whatyouhide/cassandra/pull/1] > Some things in the native protocol v5 are undocumented: > * Integers in the outer framing format are little endian > * There is no mention of the parameters used to tweak the CRC24 algorithm > * No mention of the fact that if the uncompressed payload length in Section > 2.2 is 0, then the "compressed payload" should not be decompressed -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17071) Relax schema synchronization when opening a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542085#comment-17542085
]
Andres de la Peña commented on CASSANDRA-17071:
---
This patch seems to make \{{KeyspaceMetricsTest.testMetricsCleanupOnDrop}}, as
reported by CASSANDRA-17658. That test verifies that the metrics of a keyspace
are dropped after dropping the keyspace. However, in some runs the metrics are
still there after dropping. The test used to pass right before committing this
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1611/workflows/e2fe5f89-2ec9-4897-8f9a-07f467a874be]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1611/workflows/59e81b6c-4506-400e-8370-77125536c87a])
and it started to be flaky right after
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1610/workflows/9ba746fc-574b-4e81-8f9a-0af278b9277d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1610/workflows/2eb057c6-ef97-4682-a32c-d1fa1bc2cb2d]).
> Relax schema synchronization when opening a keyspace
>
>
> Key: CASSANDRA-17071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17071
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> In short, there are two purposes of this change:
> # Move the code around to the more appropriate places (for example, CFS
> specific code for dropping table was moved from SM class to CFS class)
> # Relax the synchronization when adding/removing keyspace instances in SM -
> instead of synchronizing the whole collection of keyspace instances, we only
> synchronize the related item (the original idea authored by [~blambov]).
> The current implementation works because a certain order of opening keyspaces
> is assumed. If a keyspace is already initialized, it is just returned without
> sync and sync is done only to initialize the keyspace. When synchronization
> is extended to the whole method, the system finds itself in a deadlock. This
> means that some keyspace is tried to be opened during initiazation. Currently
> it works fine because the keyspace which is not initialized yet is never
> tried to be opened asynchronously while initializing some other keyspace in a
> different thread. Hence the conclusion about fragility of the current
> solution.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17659) Mention some undocumented behaviors of native protocol v5
[ https://issues.apache.org/jira/browse/CASSANDRA-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-17659: Test and Documentation Plan: Doc only fix Status: Patch Available (was: In Progress) > Mention some undocumented behaviors of native protocol v5 > - > > Key: CASSANDRA-17659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17659 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Andrea Leopardi >Assignee: Andrea Leopardi >Priority: Normal > Fix For: 4.x > > Attachments: 17659-trunk.txt > > > [Patch as a GitHub PR to my own > fork|https://github.com/whatyouhide/cassandra/pull/1] > Some things in the native protocol v5 are undocumented: > * Integers in the outer framing format are little endian > * There is no mention of the parameters used to tweak the CRC24 algorithm > * No mention of the fact that if the uncompressed payload length in Section > 2.2 is 0, then the "compressed payload" should not be decompressed -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17659) Mention some undocumented behaviors of native protocol v5
[ https://issues.apache.org/jira/browse/CASSANDRA-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-17659: Reviewers: Sam Tunnicliffe Status: Review In Progress (was: Patch Available) > Mention some undocumented behaviors of native protocol v5 > - > > Key: CASSANDRA-17659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17659 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Andrea Leopardi >Assignee: Andrea Leopardi >Priority: Normal > Fix For: 4.x > > Attachments: 17659-trunk.txt > > > [Patch as a GitHub PR to my own > fork|https://github.com/whatyouhide/cassandra/pull/1] > Some things in the native protocol v5 are undocumented: > * Integers in the outer framing format are little endian > * There is no mention of the parameters used to tweak the CRC24 algorithm > * No mention of the fact that if the uncompressed payload length in Section > 2.2 is 0, then the "compressed payload" should not be decompressed -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17618) Fix flaky org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17618:
Assignee: Brandon Williams
> Fix flaky
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest
> --
>
> Key: CASSANDRA-17618
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17618
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta
>
>
> The test is flaky on 4.1:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1604/workflows/243a20a5-eda2-4c28-95e8-ab6c4f85a891/jobs/10911
> {code:java}
> junit.framework.AssertionFailedError: expected:<0> but was:<1>
> at
> org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest.lambda$testConnectionsAreRejectedWithInvalidConfig$81c80a4a$1(InternodeEncryptionEnforcementTest.java:91)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17658) Test Failures: org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
[
https://issues.apache.org/jira/browse/CASSANDRA-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542083#comment-17542083
]
Andres de la Peña commented on CASSANDRA-17658:
---
The test checks that deleting a keyspace also deletes its metrics. I suspect
that this failure is hitting a race introduced by CASSANDRA-17071, maybe around
{{{}Schema#maybeRemoveKeyspaceInstance{}}}. Indeed, the test used to pass right
before that commit
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1611/workflows/e2fe5f89-2ec9-4897-8f9a-07f467a874be]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1611/workflows/59e81b6c-4506-400e-8370-77125536c87a])
and it started to be flaky right after that commit
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1610/workflows/9ba746fc-574b-4e81-8f9a-0af278b9277d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1610/workflows/2eb057c6-ef97-4682-a32c-d1fa1bc2cb2d]).
CC [~jlewandowski] [~blambov] [~ifesdjeen]
> Test Failures:
> org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop
>
>
> Key: CASSANDRA-17658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17658
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> The test
> {{org.apache.cassandra.metrics.KeyspaceMetricsTest.testMetricsCleanupOnDrop}}
> seems to be flaky on CircleCI, although I haven't seen it failing on Jenkins.
> It was first detected during CASSANDRA-17509, on [this
> run|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/211/workflows/2cbb5465-a970-440b-a502-06e380ce6851/jobs/1977/tests]:
> {code}
> junit.framework.AssertionFailedError:
> org.apache.cassandra.metrics.keyspace.AdditionalWrites.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesLiveDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesOffHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AllMemtablesOnHeapDataSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.AntiCompactionTime.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BloomFilterDiskSpaceUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BloomFilterOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.BytesValidated.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasCommitLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasCommitTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasPrepareLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasPrepareTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasProposeLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CasProposeTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ClientTombstoneAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ClientTombstoneWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.ColUpdateTimeDeltaHistogram.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CompressionMetadataOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSizeAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.CoordinatorReadSizeWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IdealCLWriteLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IdealCLWriteTotalLatency.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.IndexSummaryOffHeapMemoryUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LiveDiskSpaceUsed.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LiveScannedHistogram.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LocalReadSize.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LocalReadSizeAborts.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.LocalReadSizeWarnings.keyspacemetricstest_metrics_cleanup,org.apache.cassandra.metrics.keyspace.MemtableColumnsCount.keyspacemetricstest_metrics_c
[jira] [Commented] (CASSANDRA-17577) Add cqlsh SHOW REPLICAS by token command
[
https://issues.apache.org/jira/browse/CASSANDRA-17577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542082#comment-17542082
]
Brandon Williams commented on CASSANDRA-17577:
--
Thinking about this a bit more, what we could do is similar to what we've done
previously with terminology corrections, and alias 'nodetool getreplicas' as
'nodetool getendpoints' in the same release to begin a transition there.
> Add cqlsh SHOW REPLICAS by token command
>
>
> Key: CASSANDRA-17577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17577
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> It is often useful to know when a query fails or a query is slow which nodes
> the query was routed too. For clusters with vnodes, determining this is not
> simple and requires an admin tool like 'nodetool getendpoints;.
> But, the Cassandra driver has cluster metadata which identifies which nodes
> are the replicas for a given token range. It should be straightforward to
> support this in CQLSH.
> Example with python driver:
> {quote}from cassandra.cluster import Cluster
> from cassandra.auth import PlainTextAuthProvider
> import cassandra.metadata
> from cassandra.metadata import Murmur3Token
>
> auth_provider = PlainTextAuthProvider(username='cassandra',
> password='cassandra')
> cluster = Cluster(['127.0.0.1'], auth_provider=auth_provider)
> session = cluster.connect('tests')
> cluster.metadata.token_map.get_replicas('tests',Murmur3Token(100))
> {color:#4c9aff}>>>
> cluster.metadata.token_map.get_replicas('tests',Murmur3Token(100)){color}
> {color:#4c9aff}[]{color}
>
> {quote}
> Users shouldn't require access to an admin tool like nodetool to access the
> cluster metadata. This is especially true for Cassandra-as-a-service
> offerings like AWS keyspaces or Instaclustr's managed service.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14401) Attempted serializing to buffer exceeded maximum of 65535 bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-14401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542057#comment-17542057
]
Doug Whitfield commented on CASSANDRA-14401:
Has anyone seen this in anything after 3.11.4? I think we are seeing this in
3.11.5.
> Attempted serializing to buffer exceeded maximum of 65535 bytes
>
>
> Key: CASSANDRA-14401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14401
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Artem Rokhin
>Priority: Normal
> Labels: remove-reopen
>
> Cassandra version: 3.11.2
> 3 nodes cluster
> The following exception appears on all 3 nodes and after awhile cluster
> becomes unreposnsive
>
> {code}
> java.lang.AssertionError: Attempted serializing to buffer exceeded maximum of
> 65535 bytes: 67661
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithShortLength(ByteBufferUtil.java:309)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.db.filter.RowFilter$Expression$Serializer.serialize(RowFilter.java:547)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.db.filter.RowFilter$Serializer.serialize(RowFilter.java:1143)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.db.ReadCommand$Serializer.serialize(ReadCommand.java:726)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.db.ReadCommand$Serializer.serialize(ReadCommand.java:683)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.io.ForwardingVersionedSerializer.serialize(ForwardingVersionedSerializer.java:45)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at org.apache.cassandra.net.MessageOut.serialize(MessageOut.java:120)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.net.OutboundTcpConnection.writeInternal(OutboundTcpConnection.java:385)
> [apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.net.OutboundTcpConnection.writeConnected(OutboundTcpConnection.java:337)
> [apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.net.OutboundTcpConnection.run(OutboundTcpConnection.java:263)
> [apache-cassandra-3.11.2.jar:3.11.2]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17232) org.apache.cassandra.db.commitlog.GroupCommitLogTest tests failing on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-17232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542003#comment-17542003
]
Andres de la Peña commented on CASSANDRA-17232:
---
I think 4.0 is not affected for this bug, nor for the ones reported on
CASSANDRA-17469. In fact, 4.0 without the patch survives 1000 iterations
without hitting those failures
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1604/workflows/ee963ae1-9517-497a-9e8c-82ebf52dab67]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1604/workflows/de382ce3-d0cb-4fcf-afba-ef3fb5d108a3]).
However, if we apply the patch to 4.1 it still hits failures
([j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1603/workflows/9410e5e6-7328-4da7-b23b-85138f19c39d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1603/workflows/b9ea90a8-42c0-4012-8338-ca76b88ec40a]).
Note that the flakiness indicated by CASSANDRA-17469 is quite low and the
default 100 iterations are not enough to hit the failures.
> org.apache.cassandra.db.commitlog.GroupCommitLogTest tests failing on trunk
> ---
>
> Key: CASSANDRA-17232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17232
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x, 4.x
>
>
> I saw
> [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1344/testReport/junit/org.apache.cassandra.db.commitlog/GroupCommitLogTest/replayWithDiscard_3_/]
> and
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/881/testReport/junit/org.apache.cassandra.db.commitlog/GroupCommitLogTest/replayWithDiscard_3__compression_3/]
> the same assertion failure:
>
> {code:java}
> org.apache.cassandra.db.commitlog.GroupCommitLogTest.replayWithDiscard[3]
> Error Message
> expected:<204> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<204> but was:<0> at
> org.apache.cassandra.db.commitlog.CommitLogTest.replayWithDiscard(CommitLogTest.java:883)
> {code}
>
> Then I find that there are many other tests from GroupCommitLogTest failing
> with No such file found.
> Example:
> https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1344/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17470) Default directory permissions for /var/lib/cassandra could be more restrictive
[
https://issues.apache.org/jira/browse/CASSANDRA-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17470:
-
Fix Version/s: 4.2
(was: 4.x)
Source Control Link:
https://github.com/apache/cassandra/commit/39d372539f224eb1eaa3b6209610142abe74712c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks.
> Default directory permissions for /var/lib/cassandra could be more restrictive
> --
>
> Key: CASSANDRA-17470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17470
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Sebastian Schulze
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.2
>
>
> I noticed that the default permissions for /var/lib/cassandra and everything
> below seem to be "world readable", e.g. "{{{}drwxr-xr-x 6 cassandra
> cassandra{}}}".
> It might depend on the distribution / package used, but I can at least
> confirm this for the official Cassandra Debian packages as well as the Docker
> containers. Out of curiosity I compared it to Postgres and MySQL to see which
> defaults they would opt for and they are
> {{drwxr-x--- 2 mysql mysql 4.0K Mar 22 10:00 mysql}}
> and respectively
> {{drwx-- 19 postgres postgres 4.0K Mar 22 10:01 data}}
> which is way more appropriate in my option. ([Here is a Gist with the script
> to compare
> them|https://gist.github.com/bascht/31fa749d4121b9898902d5d557a01f82])
> If there is no particular reason behind this, I would suggest that the
> default packages should have stricter ulimits that restricts access to the
> data directory to the cassandra user & group.
> (See also this [mailing list
> thread|https://lists.apache.org/thread/gyoqb4xnq4ry0c726f0ntz83rvn0w5kx])
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 03/03: Update changes for 17470
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit e9edf16c7f49cf81a26339470465d46964acb869 Author: Brandon Williams AuthorDate: Wed May 25 06:21:15 2022 -0500 Update changes for 17470 --- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGES.txt b/CHANGES.txt index 0f64ce2612..c38906747d 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.2 + * Change default directory permission to 750 in packaging (CASSANDRA-17470) * Adding support for TLS client authentication for internode communication (CASSANDRA-17513) * Add new CQL function maxWritetime (CASSANDRA-17425) * Add guardrail for ALTER TABLE ADD / DROP / REMOVE column operations (CASSANDRA-17495) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 02/03: set perms on data/logs to 750 in debian packaging
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 39d372539f224eb1eaa3b6209610142abe74712c Author: Brandon Williams AuthorDate: Wed Mar 30 14:35:18 2022 -0500 set perms on data/logs to 750 in debian packaging Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17470 --- debian/cassandra.postinst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/cassandra.postinst b/debian/cassandra.postinst index 752ff1f6bb..95882e3ae2 100644 --- a/debian/cassandra.postinst +++ b/debian/cassandra.postinst @@ -37,6 +37,8 @@ case "$1" in if [ -z "$2" ]; then chown -R cassandra: /var/lib/cassandra chown -R cassandra: /var/log/cassandra +chmod 750 /var/lib/cassandra/ +chmod 750 /var/log/cassandra/ fi if ! sysctl -p /etc/sysctl.d/cassandra.conf; then echo >&2 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/03: set perms on data/logs to 750 in redhat packaging
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 80d94245be9806f1e8ae0ab3c6d4d4d6898383f8
Author: Brandon Williams
AuthorDate: Thu Mar 31 09:33:59 2022 -0500
set perms on data/logs to 750 in redhat packaging
Patch by brandonwilliams; reivewed by bereng for CASSANDRA-17470
---
redhat/cassandra.spec | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/redhat/cassandra.spec b/redhat/cassandra.spec
index a3abaa6ece..8c04fdb4cf 100644
--- a/redhat/cassandra.spec
+++ b/redhat/cassandra.spec
@@ -161,9 +161,9 @@ exit 0
%{_sysconfdir}/security/limits.d/%{username}.conf
/usr/share/%{username}*
%config(noreplace) /%{_sysconfdir}/%{username}
-%attr(755,%{username},%{username}) %config(noreplace) /var/lib/%{username}/*
-%attr(755,%{username},%{username}) /var/log/%{username}*
-%attr(755,%{username},%{username}) /var/run/%{username}*
+%attr(750,%{username},%{username}) %config(noreplace) /var/lib/%{username}/*
+%attr(750,%{username},%{username}) /var/log/%{username}*
+%attr(750,%{username},%{username}) /var/run/%{username}*
%{python_sitelib}/cqlshlib/
%{python_sitelib}/cassandra_pylib*.egg-info
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (ed3901823a -> e9edf16c7f)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from ed3901823a Adding support for TLS client authentication for internode communication new 80d94245be set perms on data/logs to 750 in redhat packaging new 39d372539f set perms on data/logs to 750 in debian packaging new e9edf16c7f Update changes for 17470 The 3 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 + debian/cassandra.postinst | 2 ++ redhat/cassandra.spec | 6 +++--- 3 files changed, 6 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17420) Test Failure: org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-17420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-17420:
---
Assignee: Berenguer Blasi
> Test Failure:
> org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
> ---
>
> Key: CASSANDRA-17420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17420
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/992/testReport/org.apache.cassandra.cql3.validation.miscellaneous/CrcCheckChanceTest/testChangingCrcCheckChanceOldFormat_2/
> bq. Error setting schema for test (query was: CREATE KEYSPACE IF NOT EXISTS
> cql_test_keyspace WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'})
> 1 failure
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17420) Test Failure: org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-17420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17420:
Resolution: Cannot Reproduce
Status: Resolved (was: Open)
> Test Failure:
> org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
> ---
>
> Key: CASSANDRA-17420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17420
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/992/testReport/org.apache.cassandra.cql3.validation.miscellaneous/CrcCheckChanceTest/testChangingCrcCheckChanceOldFormat_2/
> bq. Error setting schema for test (query was: CREATE KEYSPACE IF NOT EXISTS
> cql_test_keyspace WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'})
> 1 failure
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17470) Default directory permissions for /var/lib/cassandra could be more restrictive
[
https://issues.apache.org/jira/browse/CASSANDRA-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17470:
Status: Ready to Commit (was: Review In Progress)
> Default directory permissions for /var/lib/cassandra could be more restrictive
> --
>
> Key: CASSANDRA-17470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17470
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Sebastian Schulze
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> I noticed that the default permissions for /var/lib/cassandra and everything
> below seem to be "world readable", e.g. "{{{}drwxr-xr-x 6 cassandra
> cassandra{}}}".
> It might depend on the distribution / package used, but I can at least
> confirm this for the official Cassandra Debian packages as well as the Docker
> containers. Out of curiosity I compared it to Postgres and MySQL to see which
> defaults they would opt for and they are
> {{drwxr-x--- 2 mysql mysql 4.0K Mar 22 10:00 mysql}}
> and respectively
> {{drwx-- 19 postgres postgres 4.0K Mar 22 10:01 data}}
> which is way more appropriate in my option. ([Here is a Gist with the script
> to compare
> them|https://gist.github.com/bascht/31fa749d4121b9898902d5d557a01f82])
> If there is no particular reason behind this, I would suggest that the
> default packages should have stricter ulimits that restricts access to the
> data directory to the cassandra user & group.
> (See also this [mailing list
> thread|https://lists.apache.org/thread/gyoqb4xnq4ry0c726f0ntz83rvn0w5kx])
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17470) Default directory permissions for /var/lib/cassandra could be more restrictive
[
https://issues.apache.org/jira/browse/CASSANDRA-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541985#comment-17541985
]
Berenguer Blasi commented on CASSANDRA-17470:
-
14 on truck sgtm. +1
> Default directory permissions for /var/lib/cassandra could be more restrictive
> --
>
> Key: CASSANDRA-17470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17470
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Sebastian Schulze
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> I noticed that the default permissions for /var/lib/cassandra and everything
> below seem to be "world readable", e.g. "{{{}drwxr-xr-x 6 cassandra
> cassandra{}}}".
> It might depend on the distribution / package used, but I can at least
> confirm this for the official Cassandra Debian packages as well as the Docker
> containers. Out of curiosity I compared it to Postgres and MySQL to see which
> defaults they would opt for and they are
> {{drwxr-x--- 2 mysql mysql 4.0K Mar 22 10:00 mysql}}
> and respectively
> {{drwx-- 19 postgres postgres 4.0K Mar 22 10:01 data}}
> which is way more appropriate in my option. ([Here is a Gist with the script
> to compare
> them|https://gist.github.com/bascht/31fa749d4121b9898902d5d557a01f82])
> If there is no particular reason behind this, I would suggest that the
> default packages should have stricter ulimits that restricts access to the
> data directory to the cassandra user & group.
> (See also this [mailing list
> thread|https://lists.apache.org/thread/gyoqb4xnq4ry0c726f0ntz83rvn0w5kx])
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17470) Default directory permissions for /var/lib/cassandra could be more restrictive
[
https://issues.apache.org/jira/browse/CASSANDRA-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541985#comment-17541985
]
Berenguer Blasi edited comment on CASSANDRA-17470 at 5/25/22 11:16 AM:
---
14 on trunk sgtm. +1
was (Author: bereng):
14 on truck sgtm. +1
> Default directory permissions for /var/lib/cassandra could be more restrictive
> --
>
> Key: CASSANDRA-17470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17470
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Sebastian Schulze
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> I noticed that the default permissions for /var/lib/cassandra and everything
> below seem to be "world readable", e.g. "{{{}drwxr-xr-x 6 cassandra
> cassandra{}}}".
> It might depend on the distribution / package used, but I can at least
> confirm this for the official Cassandra Debian packages as well as the Docker
> containers. Out of curiosity I compared it to Postgres and MySQL to see which
> defaults they would opt for and they are
> {{drwxr-x--- 2 mysql mysql 4.0K Mar 22 10:00 mysql}}
> and respectively
> {{drwx-- 19 postgres postgres 4.0K Mar 22 10:01 data}}
> which is way more appropriate in my option. ([Here is a Gist with the script
> to compare
> them|https://gist.github.com/bascht/31fa749d4121b9898902d5d557a01f82])
> If there is no particular reason behind this, I would suggest that the
> default packages should have stricter ulimits that restricts access to the
> data directory to the cassandra user & group.
> (See also this [mailing list
> thread|https://lists.apache.org/thread/gyoqb4xnq4ry0c726f0ntz83rvn0w5kx])
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17470) Default directory permissions for /var/lib/cassandra could be more restrictive
[
https://issues.apache.org/jira/browse/CASSANDRA-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17470:
Reviewers: Berenguer Blasi
Status: Review In Progress (was: Patch Available)
> Default directory permissions for /var/lib/cassandra could be more restrictive
> --
>
> Key: CASSANDRA-17470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17470
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Sebastian Schulze
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> I noticed that the default permissions for /var/lib/cassandra and everything
> below seem to be "world readable", e.g. "{{{}drwxr-xr-x 6 cassandra
> cassandra{}}}".
> It might depend on the distribution / package used, but I can at least
> confirm this for the official Cassandra Debian packages as well as the Docker
> containers. Out of curiosity I compared it to Postgres and MySQL to see which
> defaults they would opt for and they are
> {{drwxr-x--- 2 mysql mysql 4.0K Mar 22 10:00 mysql}}
> and respectively
> {{drwx-- 19 postgres postgres 4.0K Mar 22 10:01 data}}
> which is way more appropriate in my option. ([Here is a Gist with the script
> to compare
> them|https://gist.github.com/bascht/31fa749d4121b9898902d5d557a01f82])
> If there is no particular reason behind this, I would suggest that the
> default packages should have stricter ulimits that restricts access to the
> data directory to the cassandra user & group.
> (See also this [mailing list
> thread|https://lists.apache.org/thread/gyoqb4xnq4ry0c726f0ntz83rvn0w5kx])
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17657) WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
[
https://issues.apache.org/jira/browse/CASSANDRA-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541967#comment-17541967
]
Erick Ramirez commented on CASSANDRA-17657:
---
I’ve completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch ‘asf-site’ set up to track remote branch ‘asf-site’ from ‘origin’.
Switched to a new branch ‘asf-site’
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at 83c6ef87 generate docs for 17718e18
$ git push -f origin asf-site
Username for ‘https://github.com’: erickramirezau
Password for ‘https://erickramire...@github.com’:
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/apache/cassandra-website.git
+ f70fa50c...83c6ef87 asf-site -> asf-site (forced update){noformat}
The blog post is now live on the site --
https://cassandra.apache.org/_/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.html
> WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password
> Hashing"
> -
>
> Key: CASSANDRA-17657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17657
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: NA
>
> Attachments: c17657-01-blog_index.png, c17657-02-blog_post.png
>
>
> This ticket is to capture the work associated with publishing the May 2022
> blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
> If this blog cannot be published by the *May 26, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (f70fa50c -> 83c6ef87)
This is an automated email from the ASF dual-hosted git repository.
erickramirezau pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard f70fa50c generate docs for c0f50fd6
add 17718e18 BLOG - Cassandra 4.1 Features: Client-side Password Hashing
add 83c6ef87 generate docs for 17718e18
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (f70fa50c)
\
N -- N -- N refs/heads/asf-site (83c6ef87)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
...-side-password-hashing-unsplash-jan-baborak.jpg | Bin 0 -> 159700 bytes
content/_/blog.html| 24 +++
...4.1-Features-Client-side-Password-Hashing.html} | 120 ++--
.../cassandra/configuration/cass_yaml_file.html| 211 +++--
content/doc/4.1/cassandra/new/configuration.html | 22 ++-
.../4.1/cassandra/tools/nodetool/bootstrap.html| 7 +-
.../doc/4.1/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.1/cassandra/tools/nodetool/nodetool.html | 6 +-
.../4.1/cassandra/tools/nodetool/repair_admin.html | 80
.../cassandra/configuration/cass_yaml_file.html| 211 +++--
.../doc/latest/cassandra/new/configuration.html| 22 ++-
.../latest/cassandra/tools/nodetool/bootstrap.html | 7 +-
.../latest/cassandra/tools/nodetool/import.html| 6 +-
.../latest/cassandra/tools/nodetool/nodetool.html | 6 +-
.../cassandra/tools/nodetool/repair_admin.html | 80
.../cassandra/configuration/cass_yaml_file.html| 211 +++--
content/doc/trunk/cassandra/new/configuration.html | 22 ++-
.../trunk/cassandra/tools/nodetool/bootstrap.html | 7 +-
.../doc/trunk/cassandra/tools/nodetool/import.html | 6 +-
.../trunk/cassandra/tools/nodetool/nodetool.html | 6 +-
.../cassandra/tools/nodetool/repair_admin.html | 80
content/search-index.js| 2 +-
...-side-password-hashing-unsplash-jan-baborak.jpg | Bin 0 -> 159700 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25 +++
...-4.1-Features-Client-side-Password-Hashing.adoc | 75
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
26 files changed, 817 insertions(+), 425 deletions(-)
create mode 100644
content/_/_images/blog/apache-cassandra-4.1-features-client-side-password-hashing-unsplash-jan-baborak.jpg
copy content/_/blog/{ApacheCon-NA-2022-Call-for-Papers-Open.html =>
Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.html} (72%)
create mode 100644
site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-features-client-side-password-hashing-unsplash-jan-baborak.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17657) WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
[ https://issues.apache.org/jira/browse/CASSANDRA-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541962#comment-17541962 ] Erick Ramirez commented on CASSANDRA-17657: --- The blog post is now in staging -- https://cassandra.staged.apache.org/_/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.html > WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password > Hashing" > - > > Key: CASSANDRA-17657 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17657 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17657-01-blog_index.png, c17657-02-blog_post.png > > > This ticket is to capture the work associated with publishing the May 2022 > blog "Apache Cassandra 4.1 Features: Client-side Password Hashing" > If this blog cannot be published by the *May 26, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (561ad8ab -> 83c6ef87)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard 561ad8ab generate docs for c0f50fd6
add 17718e18 BLOG - Cassandra 4.1 Features: Client-side Password Hashing
new 83c6ef87 generate docs for 17718e18
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (561ad8ab)
\
N -- N -- N refs/heads/asf-staging (83c6ef87)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
...-side-password-hashing-unsplash-jan-baborak.jpg | Bin 0 -> 159700 bytes
content/_/blog.html| 24 +
...4.1-Features-Client-side-Password-Hashing.html} | 120 +
content/search-index.js| 2 +-
...-side-password-hashing-unsplash-jan-baborak.jpg | Bin 0 -> 159700 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25 +
...-4.1-Features-Client-side-Password-Hashing.adoc | 75 +
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
8 files changed, 178 insertions(+), 68 deletions(-)
create mode 100644
content/_/_images/blog/apache-cassandra-4.1-features-client-side-password-hashing-unsplash-jan-baborak.jpg
copy content/_/blog/{ApacheCon-NA-2022-Call-for-Papers-Open.html =>
Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.html} (72%)
create mode 100644
site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-features-client-side-password-hashing-unsplash-jan-baborak.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17649) Fix flaky tests in TopPartitionsTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541957#comment-17541957 ] Andres de la Peña commented on CASSANDRA-17649: --- Yes, thanks, I meant CASSANDRA-17616. > Fix flaky tests in TopPartitionsTest > > > Key: CASSANDRA-17649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17649 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x > > > While working on other tickets we noticed a few tests from TopPartitionTest > are flaky on 4.1. > Example run with the CircleCI multiplexer: > [https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=flaky_top_partitions_test_4.1&filter=all] > I haven't seen those in Jenkins though. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17657) WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
[
https://issues.apache.org/jira/browse/CASSANDRA-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541950#comment-17541950
]
Erick Ramirez commented on CASSANDRA-17657:
---
The website content is currently getting built in staging:
||Branch||PR||Commit||Build||
|{{trunk}}|[#133|https://github.com/apache/cassandra-website/pull/133]|[17718e1
|https://github.com/apache/cassandra-website/commit/17718e188b997f29467b09d1eeb6d4c497fb0326]|[#277|https://ci-cassandra.apache.org/job/cassandra-website/277/]|
> WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password
> Hashing"
> -
>
> Key: CASSANDRA-17657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17657
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: NA
>
> Attachments: c17657-01-blog_index.png, c17657-02-blog_post.png
>
>
> This ticket is to capture the work associated with publishing the May 2022
> blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
> If this blog cannot be published by the *May 26, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17657) WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
[
https://issues.apache.org/jira/browse/CASSANDRA-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17657:
--
Source Control Link:
https://github.com/apache/cassandra-website/commit/17718e188b997f29467b09d1eeb6d4c497fb0326
(was:
https://github.com/apache/cassandra-website/pull/133/commits/fee4125e803916359d74f9795fc341732baa0bf7)
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#133|https://github.com/apache/cassandra-website/pull/133]|[17718e1
|https://github.com/apache/cassandra-website/commit/17718e188b997f29467b09d1eeb6d4c497fb0326]|
> WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password
> Hashing"
> -
>
> Key: CASSANDRA-17657
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17657
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: NA
>
> Attachments: c17657-01-blog_index.png, c17657-02-blog_post.png
>
>
> This ticket is to capture the work associated with publishing the May 2022
> blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
> If this blog cannot be published by the *May 26, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17657) WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
[ https://issues.apache.org/jira/browse/CASSANDRA-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17657: -- Status: Ready to Commit (was: Changes Suggested) > WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password > Hashing" > - > > Key: CASSANDRA-17657 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17657 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17657-01-blog_index.png, c17657-02-blog_post.png > > > This ticket is to capture the work associated with publishing the May 2022 > blog "Apache Cassandra 4.1 Features: Client-side Password Hashing" > If this blog cannot be published by the *May 26, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17657) WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
[ https://issues.apache.org/jira/browse/CASSANDRA-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17657: -- Status: Changes Suggested (was: Review In Progress) I've completed the review of the PR and made the following changes: * reformatted code examples for readability * replaced 6MB vanity image with a 160KB version !c17657-01-blog_index.png|width=300! !c17657-02-blog_post.png|width=300! > WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password > Hashing" > - > > Key: CASSANDRA-17657 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17657 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17657-01-blog_index.png, c17657-02-blog_post.png > > > This ticket is to capture the work associated with publishing the May 2022 > blog "Apache Cassandra 4.1 Features: Client-side Password Hashing" > If this blog cannot be published by the *May 26, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17657) WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
[ https://issues.apache.org/jira/browse/CASSANDRA-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17657: -- Attachment: c17657-02-blog_post.png c17657-01-blog_index.png > WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password > Hashing" > - > > Key: CASSANDRA-17657 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17657 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17657-01-blog_index.png, c17657-02-blog_post.png > > > This ticket is to capture the work associated with publishing the May 2022 > blog "Apache Cassandra 4.1 Features: Client-side Password Hashing" > If this blog cannot be published by the *May 26, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17420) Test Failure: org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-17420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541945#comment-17541945
]
Brandon Williams commented on CASSANDRA-17420:
--
I don't see where else there is go here, this is just barely old enough to fall
off of nightlies and there's nothing to go on from the ticket itself. I think
it's at least in the realm of possibility to get this from running out of
space, so I suggest we close and reopen if needed.
> Test Failure:
> org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
> ---
>
> Key: CASSANDRA-17420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17420
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/992/testReport/org.apache.cassandra.cql3.validation.miscellaneous/CrcCheckChanceTest/testChangingCrcCheckChanceOldFormat_2/
> bq. Error setting schema for test (query was: CREATE KEYSPACE IF NOT EXISTS
> cql_test_keyspace WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'})
> 1 failure
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: BLOG - Cassandra 4.1 Features: Client-side Password Hashing
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 17718e18 BLOG - Cassandra 4.1 Features: Client-side Password Hashing 17718e18 is described below commit 17718e188b997f29467b09d1eeb6d4c497fb0326 Author: Diogenese Topper AuthorDate: Tue May 24 21:39:43 2022 -0700 BLOG - Cassandra 4.1 Features: Client-side Password Hashing patch by Berenguer Blasi, Diogenese Topper; reviewed by Berenguer Blasi, Erick Ramirez for CASSANDRA-17657 Co-authored by: Berenguer Blasi Co-authored by: Diogenese Topper Co-authored-by: bereng <6973517+ber...@users.noreply.github.com> --- ...-side-password-hashing-unsplash-jan-baborak.jpg | Bin 0 -> 159700 bytes site-content/source/modules/ROOT/pages/blog.adoc | 25 +++ ...-4.1-Features-Client-side-Password-Hashing.adoc | 75 + 3 files changed, 100 insertions(+) diff --git a/site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-features-client-side-password-hashing-unsplash-jan-baborak.jpg b/site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-features-client-side-password-hashing-unsplash-jan-baborak.jpg new file mode 100644 index ..97a4f446 Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/apache-cassandra-4.1-features-client-side-password-hashing-unsplash-jan-baborak.jpg differ diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index 34141efd..09b02c2b 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -8,6 +8,31 @@ NOTES FOR CONTENT CREATORS - Replace post tile, date, description and link to you post. +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] +=== Apache Cassandra 4.1 Features: Client-side Password Hashing +[discrete] + May 26, 2022 +-- +[openblock,card-content] +-- +To strengthen security and avoid the use of plain-text credentials altogether, Apache Cassandra has added the option to use client-side password hashes in 4.1. + +[openblock,card-btn card-btn--blog] + + +[.btn.btn--alt] +xref:blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.adoc[Read More] + + +-- + +//end card + //start card [openblock,card shadow relative test] diff --git a/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.adoc b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.adoc new file mode 100644 index ..9886faa3 --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-Features-Client-side-Password-Hashing.adoc @@ -0,0 +1,75 @@ += Apache Cassandra 4.1 Features: Client-side Password Hashing +:page-layout: single-post +:page-role: blog-post +:page-post-date: May 26, 2022 +:page-post-author: Berenguer Blasi +:description: Client-side password hashing in Apache Cassandra 4.1 +:keywords: + +:!figure-caption: + +.Image credit: https://unsplash.com/@janbaborak[Jan Baborák on Unsplash^] +image::blog/apache-cassandra-4.1-features-client-side-password-hashing-unsplash-jan-baborak.jpg[Client-side password hashing] + +Apache Cassandra, just like any other database, needs users to connect. This means using a login and a password which up until recently would be provided as plain text. + +This has the potential to create security concerns as, for instance, audit logging could store the credentials in plain text. This problem also applied to any other system in Cassandra that might log data, bearing in mind that Apache Cassandra is an open source project and, therefore, it does not control all possible forks and implementations and what and how data is logged. + +The solution was to sanitize any logging for sensitive information, and this has been addressed recently. But that still left the door open to some corner cases where the detection or removal of such sensitive information could fail. There are also specific use cases, services and applications that might need to store a user’s credentials and up until 4.1, they would be storing that in plain text as well. + +To strengthen security, we wanted to avoid the use of plain-text credentials altogether, so https://issues.apache.org/jira/browse/CASSANDRA-17334[CASSANDRA-17334^] and the release of Apache Cassandra 4.1 will add the option to use client-side password hashes. + +=== New Hash Password Tool + +This feature introduces a new tool called `tools/bin/hash_password`. Here is an example: + +``` +$ tools/bin/hash_password -p mySecret +$2a$10$F5pRau9mKg5abP.DsuPQl.8rQpEoNm3OV91mKjb9vdKPUPejIPq/u +``` + +The to
[jira] [Commented] (CASSANDRA-17470) Default directory permissions for /var/lib/cassandra could be more restrictive
[
https://issues.apache.org/jira/browse/CASSANDRA-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541944#comment-17541944
]
Brandon Williams commented on CASSANDRA-17470:
--
That looks better, WDYT?
> Default directory permissions for /var/lib/cassandra could be more restrictive
> --
>
> Key: CASSANDRA-17470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17470
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Sebastian Schulze
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> I noticed that the default permissions for /var/lib/cassandra and everything
> below seem to be "world readable", e.g. "{{{}drwxr-xr-x 6 cassandra
> cassandra{}}}".
> It might depend on the distribution / package used, but I can at least
> confirm this for the official Cassandra Debian packages as well as the Docker
> containers. Out of curiosity I compared it to Postgres and MySQL to see which
> defaults they would opt for and they are
> {{drwxr-x--- 2 mysql mysql 4.0K Mar 22 10:00 mysql}}
> and respectively
> {{drwx-- 19 postgres postgres 4.0K Mar 22 10:01 data}}
> which is way more appropriate in my option. ([Here is a Gist with the script
> to compare
> them|https://gist.github.com/bascht/31fa749d4121b9898902d5d557a01f82])
> If there is no particular reason behind this, I would suggest that the
> default packages should have stricter ulimits that restricts access to the
> data directory to the cassandra user & group.
> (See also this [mailing list
> thread|https://lists.apache.org/thread/gyoqb4xnq4ry0c726f0ntz83rvn0w5kx])
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17649) Fix flaky tests in TopPartitionsTest
[ https://issues.apache.org/jira/browse/CASSANDRA-17649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541935#comment-17541935 ] Berenguer Blasi commented on CASSANDRA-17649: - ^you probably mean the patch for CASSANDRA-17616 > Fix flaky tests in TopPartitionsTest > > > Key: CASSANDRA-17649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17649 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.1-beta, 4.1.x > > > While working on other tickets we noticed a few tests from TopPartitionTest > are flaky on 4.1. > Example run with the CircleCI multiplexer: > [https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=flaky_top_partitions_test_4.1&filter=all] > I haven't seen those in Jenkins though. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17651) Fix flaky dtest - org.apache.cassandra.distributed.upgrade.BatchUpgradeTest.batchTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541931#comment-17541931
]
Berenguer Blasi commented on CASSANDRA-17651:
-
Probably a dup of CASSANDRA-17641
> Fix flaky dtest -
> org.apache.cassandra.distributed.upgrade.BatchUpgradeTest.batchTest
> --
>
> Key: CASSANDRA-17651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17651
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Batch Log
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> {code}
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught
> exceptions were thrown during test
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1056)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1042)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:239)
> at
> org.apache.cassandra.distributed.upgrade.BatchUpgradeTest.batchTest(BatchUpgradeTest.java:53)
> Suppressed: java.lang.RuntimeException: java.lang.AssertionError
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:495)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
> at
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:120)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.AssertionError
> at
> org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:1171)
> at
> org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:1185)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:95)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getLocalReplicaFor(AbstractReplicationStrategy.java:111)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:108)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
> at
> org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> {code}
> https://ci-cassandra.apache.org/job/Cassandra-4.1/34/testReport/org.apache.cassandra.distributed.upgrade/BatchUpgradeTest/batchTest/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17657) WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
[ https://issues.apache.org/jira/browse/CASSANDRA-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17657: -- Reviewers: Berenguer Blasi, Erick Ramirez (was: Berenguer Blasi, Berenguer Blasi) Status: Review In Progress (was: Patch Available) > WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password > Hashing" > - > > Key: CASSANDRA-17657 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17657 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the May 2022 > blog "Apache Cassandra 4.1 Features: Client-side Password Hashing" > If this blog cannot be published by the *May 26, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17657) WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password Hashing"
[ https://issues.apache.org/jira/browse/CASSANDRA-17657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-17657: - Assignee: Erick Ramirez > WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Client-side Password > Hashing" > - > > Key: CASSANDRA-17657 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17657 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the May 2022 > blog "Apache Cassandra 4.1 Features: Client-side Password Hashing" > If this blog cannot be published by the *May 26, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17652) Fix flaky dtest - org.apache.cassandra.distributed.upgrade.MixedModeConsistencyV3XTest.testConsistency
[
https://issues.apache.org/jira/browse/CASSANDRA-17652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541916#comment-17541916
]
Berenguer Blasi commented on CASSANDRA-17652:
-
Probably a dup of CASSANDRA-17641
> Fix flaky dtest -
> org.apache.cassandra.distributed.upgrade.MixedModeConsistencyV3XTest.testConsistency
> --
>
> Key: CASSANDRA-17652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17652
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> {code}
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught
> exceptions were thrown during test
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1056)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1042)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:239)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeConsistencyTestBase.testConsistency(MixedModeConsistencyTestBase.java:68)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeConsistencyTestBase.testConsistency(MixedModeConsistencyTestBase.java:45)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeConsistencyV3XTest.testConsistency(MixedModeConsistencyV3XTest.java:33)
> Suppressed: java.lang.RuntimeException: java.lang.AssertionError
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:495)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
> at
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:120)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.AssertionError
> at
> org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:1171)
> at
> org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:1185)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:95)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getLocalReplicaFor(AbstractReplicationStrategy.java:111)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:108)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
> at
> org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> Suppressed: java.lang.RuntimeException: java.lang.AssertionError
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:495)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
> at
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:120)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.AssertionError
> at
> org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:1171)
> at
> org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:1185)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:95)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getLocalReplicaFor(AbstractReplicationStrategy.java:111)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:108)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
> at
> org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> {code}
> https://ci-cassandra.apache.org/job/Cassandra-4.1/34/testReport/org.apache.cassandra.distributed.upgrade/MixedModeConsistencyV3XTest/testConsistency/
--
T
[jira] [Commented] (CASSANDRA-17642) Fix flaky dtest - org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageImplicitNullInClusteringTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541914#comment-17541914
]
Berenguer Blasi commented on CASSANDRA-17642:
-
Probably a dup of CASSANDRA-17641
> Fix flaky dtest -
> org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageImplicitNullInClusteringTest
> ---
>
> Key: CASSANDRA-17642
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17642
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.1-beta, 4.1.x
>
>
> {code}
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught
> exceptions were thrown during test
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1056)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1042)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:239)
> at
> org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest.compactStorageImplicitNullInClusteringTest(CompactStorageUpgradeTest.java:107)
> Suppressed: java.lang.RuntimeException: java.lang.AssertionError
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:495)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
> at
> org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:120)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.AssertionError
> at
> org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:1171)
> at
> org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:1185)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:95)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getLocalReplicaFor(AbstractReplicationStrategy.java:111)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:108)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
> at
> org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at
> org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> {code}
> https://ci-cassandra.apache.org/job/Cassandra-4.1/28/testReport/org.apache.cassandra.distributed.test/SchemaTest/readRepair/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17420) Test Failure: org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
[
https://issues.apache.org/jira/browse/CASSANDRA-17420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541897#comment-17541897
]
Berenguer Blasi commented on CASSANDRA-17420:
-
I'm wondering if we should close this one. I don't see any recent failures
neither I can fish any traces to investigate?
> Test Failure:
> org.apache.cassandra.cql3.validation.miscellaneous.CrcCheckChanceTest.testChangingCrcCheckChanceOldFormat
> ---
>
> Key: CASSANDRA-17420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17420
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/992/testReport/org.apache.cassandra.cql3.validation.miscellaneous/CrcCheckChanceTest/testChangingCrcCheckChanceOldFormat_2/
> bq. Error setting schema for test (query was: CREATE KEYSPACE IF NOT EXISTS
> cql_test_keyspace WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'})
> 1 failure
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17607) Fix org.apache.cassandra.db.commitlog.BatchCommitLogTest.testOutOfOrderFlushRecovery[3]-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541886#comment-17541886
]
Berenguer Blasi commented on CASSANDRA-17607:
-
This one is probably also a duplicate of CASSANDRA-17232. Closing tentatively
and we can reopen if it turns out wrong.
> Fix
> org.apache.cassandra.db.commitlog.BatchCommitLogTest.testOutOfOrderFlushRecovery[3]-cdc
> ---
>
> Key: CASSANDRA-17607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17607
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1130/testReport/org.apache.cassandra.db.commitlog/BatchCommitLogTest/testOutOfOrderFlushRecovery_3__cdc/]
>
> h3.
> {code:java}
> Stacktrace
> java.io.UncheckedIOException at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:768)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:753)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:255) at
> org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:297) at
> org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:304) at
> org.apache.cassandra.io.util.File.delete(File.java:158) at
> org.apache.cassandra.io.util.File.delete(File.java:167) at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:691)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:449)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.discardAvailableSegment(AbstractCommitLogSegmentManager.java:519)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.shutdown(AbstractCommitLogSegmentManager.java:506)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:157)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:452)
> at
> org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:504) at
> org.apache.cassandra.db.commitlog.CommitLog.resetUnsafe(CommitLog.java:470)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.testOutOfOrderFlushRecovery(CommitLogTest.java:991)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.testOutOfOrderFlushRecovery(CommitLogTest.java:1057)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/commitlog/CommitLog-7-1651753848882.log at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:249)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1142) at
> org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:250)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17607) Fix org.apache.cassandra.db.commitlog.BatchCommitLogTest.testOutOfOrderFlushRecovery[3]-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-17607:
---
Assignee: Berenguer Blasi
> Fix
> org.apache.cassandra.db.commitlog.BatchCommitLogTest.testOutOfOrderFlushRecovery[3]-cdc
> ---
>
> Key: CASSANDRA-17607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17607
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1130/testReport/org.apache.cassandra.db.commitlog/BatchCommitLogTest/testOutOfOrderFlushRecovery_3__cdc/]
>
> h3.
> {code:java}
> Stacktrace
> java.io.UncheckedIOException at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:768)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:753)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:255) at
> org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:297) at
> org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:304) at
> org.apache.cassandra.io.util.File.delete(File.java:158) at
> org.apache.cassandra.io.util.File.delete(File.java:167) at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:691)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:449)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.discardAvailableSegment(AbstractCommitLogSegmentManager.java:519)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.shutdown(AbstractCommitLogSegmentManager.java:506)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:157)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:452)
> at
> org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:504) at
> org.apache.cassandra.db.commitlog.CommitLog.resetUnsafe(CommitLog.java:470)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.testOutOfOrderFlushRecovery(CommitLogTest.java:991)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.testOutOfOrderFlushRecovery(CommitLogTest.java:1057)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/commitlog/CommitLog-7-1651753848882.log at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:249)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1142) at
> org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:250)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17607) Fix org.apache.cassandra.db.commitlog.BatchCommitLogTest.testOutOfOrderFlushRecovery[3]-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17607:
Resolution: Duplicate
Status: Resolved (was: Open)
> Fix
> org.apache.cassandra.db.commitlog.BatchCommitLogTest.testOutOfOrderFlushRecovery[3]-cdc
> ---
>
> Key: CASSANDRA-17607
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17607
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1130/testReport/org.apache.cassandra.db.commitlog/BatchCommitLogTest/testOutOfOrderFlushRecovery_3__cdc/]
>
> h3.
> {code:java}
> Stacktrace
> java.io.UncheckedIOException at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:768)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:753)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:255) at
> org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:297) at
> org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:304) at
> org.apache.cassandra.io.util.File.delete(File.java:158) at
> org.apache.cassandra.io.util.File.delete(File.java:167) at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:691)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:449)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.discardAvailableSegment(AbstractCommitLogSegmentManager.java:519)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.shutdown(AbstractCommitLogSegmentManager.java:506)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.shutdown(CommitLogSegmentManagerCDC.java:157)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:452)
> at
> org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:504) at
> org.apache.cassandra.db.commitlog.CommitLog.resetUnsafe(CommitLog.java:470)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.testOutOfOrderFlushRecovery(CommitLogTest.java:991)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.testOutOfOrderFlushRecovery(CommitLogTest.java:1057)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/commitlog/CommitLog-7-1651753848882.log at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:249)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1142) at
> org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:250)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17469) Test Failure: org.apache.cassandra.db.commitlog.GroupCommitLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-17469:
---
Assignee: Berenguer Blasi
> Test Failure: org.apache.cassandra.db.commitlog.GroupCommitLogTest
> --
>
> Key: CASSANDRA-17469
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17469
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Intermitent failures in
> {{{}org.apache.cassandra.db.commitlog.GroupCommitLogTest{}}}:
> *
> [testTruncateWithoutSnapshotNonDurable|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testRecoveryWithEmptyLog|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testOutOfOrderLogDiscardWithCompaction|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testExceedRecordLimitWithMultiplePartitions|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testExceedRecordLimitWithMultiplePartitions_5__cdc_2/]
> *
> [testRecoveryWithShortMutationSize|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testRecoveryWithShortMutationSize_4__cdc_2/]
> {code:java}
> Failed 2 times in the last 11 runs. Flakiness: 30%, Stability: 81%
> Stacktrace
> java.io.UncheckedIOException
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:768)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:753)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:255)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:297)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:304)
> at org.apache.cassandra.io.util.File.delete(File.java:158)
> at org.apache.cassandra.io.util.File.delete(File.java:167)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.discard(CommitLogSegmentManagerCDC.java:75)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.closeAndDeleteSegmentUnsafe(AbstractCommitLogSegmentManager.java:479)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:452)
> at
> org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:504)
> at
> org.apache.cassandra.db.commitlog.CommitLog.resetUnsafe(CommitLog.java:470)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.beforeTest(CommitLogTest.java:184)
> at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/commitlog/CommitLog-7-1647704321215.log
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:249)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1142)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:250)
> Standard Output
> DEBUG [main] 2022-03-19 15:41:04,702 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-03-19 15:41:04,712 InternalThreadLocalMap.java:83 -
> -Dio.netty.threadLocalMap.stringBuilder.initialSize: 1024
> DEBUG [main] 2022-03-19 15:41:04,712 InternalThreadLocalMap.java:86 -
> -Dio.netty.threadLocalMap.stringBuilder.maxSize: 4096
> INFO [main] 2022-03-19 15:41:04,713 CipherFactory.java:68 - initializing
> CipherFactory
> INFO [main] 2022-03-19 15:41:04,713 JKSKeyPro
> ...[truncated 1879728 chars]...
> tLog-7-1647704466908.log
> INFO [main] 2022-03-19 15:41:26,711 CommitLog.java:175 - No commitlog files
> found; skipping replay
> DEBUG [main] 2022-03-19 15:41:28,150 CommitLogReader.java:266 - Readin
[jira] [Commented] (CASSANDRA-17469) Test Failure: org.apache.cassandra.db.commitlog.GroupCommitLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541881#comment-17541881
]
Berenguer Blasi commented on CASSANDRA-17469:
-
Closing tentatively as dup of CASSANDRA-17232. They point to different stacks
but I have an educated suspicion it's the same underlying cause. We can reopen
if this turns out wrong.
> Test Failure: org.apache.cassandra.db.commitlog.GroupCommitLogTest
> --
>
> Key: CASSANDRA-17469
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17469
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Intermitent failures in
> {{{}org.apache.cassandra.db.commitlog.GroupCommitLogTest{}}}:
> *
> [testTruncateWithoutSnapshotNonDurable|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testRecoveryWithEmptyLog|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testOutOfOrderLogDiscardWithCompaction|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testExceedRecordLimitWithMultiplePartitions|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testExceedRecordLimitWithMultiplePartitions_5__cdc_2/]
> *
> [testRecoveryWithShortMutationSize|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testRecoveryWithShortMutationSize_4__cdc_2/]
> {code:java}
> Failed 2 times in the last 11 runs. Flakiness: 30%, Stability: 81%
> Stacktrace
> java.io.UncheckedIOException
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:768)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:753)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:255)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:297)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:304)
> at org.apache.cassandra.io.util.File.delete(File.java:158)
> at org.apache.cassandra.io.util.File.delete(File.java:167)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.discard(CommitLogSegmentManagerCDC.java:75)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.closeAndDeleteSegmentUnsafe(AbstractCommitLogSegmentManager.java:479)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:452)
> at
> org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:504)
> at
> org.apache.cassandra.db.commitlog.CommitLog.resetUnsafe(CommitLog.java:470)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.beforeTest(CommitLogTest.java:184)
> at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/commitlog/CommitLog-7-1647704321215.log
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:249)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1142)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:250)
> Standard Output
> DEBUG [main] 2022-03-19 15:41:04,702 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-03-19 15:41:04,712 InternalThreadLocalMap.java:83 -
> -Dio.netty.threadLocalMap.stringBuilder.initialSize: 1024
> DEBUG [main] 2022-03-19 15:41:04,712 InternalThreadLocalMap.java:86 -
> -Dio.netty.threadLocalMap.stringBuilder.maxSize: 4096
> INFO [main] 2022-03-19 15:41:04,713 CipherFactory.java:68 - initializing
> CipherFactory
> INFO [main] 2022-03-19 15:41:04,713 JKSKeyPro
> ...[truncated 1879728 chars]...
> tLog-7-1647704466908.log
> INFO [ma
[jira] [Updated] (CASSANDRA-17469) Test Failure: org.apache.cassandra.db.commitlog.GroupCommitLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17469:
Resolution: Duplicate
Status: Resolved (was: Open)
> Test Failure: org.apache.cassandra.db.commitlog.GroupCommitLogTest
> --
>
> Key: CASSANDRA-17469
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17469
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> Intermitent failures in
> {{{}org.apache.cassandra.db.commitlog.GroupCommitLogTest{}}}:
> *
> [testTruncateWithoutSnapshotNonDurable|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testRecoveryWithEmptyLog|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testOutOfOrderLogDiscardWithCompaction|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testTruncateWithoutSnapshotNonDurable_4__cdc_2/]
> *
> [testExceedRecordLimitWithMultiplePartitions|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testExceedRecordLimitWithMultiplePartitions_5__cdc_2/]
> *
> [testRecoveryWithShortMutationSize|https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db.commitlog/GroupCommitLogTest/testRecoveryWithShortMutationSize_4__cdc_2/]
> {code:java}
> Failed 2 times in the last 11 runs. Flakiness: 30%, Stability: 81%
> Stacktrace
> java.io.UncheckedIOException
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:768)
> at
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:753)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:255)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:297)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:304)
> at org.apache.cassandra.io.util.File.delete(File.java:158)
> at org.apache.cassandra.io.util.File.delete(File.java:167)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC.discard(CommitLogSegmentManagerCDC.java:75)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.closeAndDeleteSegmentUnsafe(AbstractCommitLogSegmentManager.java:479)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.stopUnsafe(AbstractCommitLogSegmentManager.java:452)
> at
> org.apache.cassandra.db.commitlog.CommitLog.stopUnsafe(CommitLog.java:504)
> at
> org.apache.cassandra.db.commitlog.CommitLog.resetUnsafe(CommitLog.java:470)
> at
> org.apache.cassandra.db.commitlog.CommitLogTest.beforeTest(CommitLogTest.java:184)
> at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: java.nio.file.NoSuchFileException:
> build/test/cassandra/commitlog/CommitLog-7-1647704321215.log
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:249)
> at
> java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
> at java.base/java.nio.file.Files.delete(Files.java:1142)
> at org.apache.cassandra.io.util.PathUtils.delete(PathUtils.java:250)
> Standard Output
> DEBUG [main] 2022-03-19 15:41:04,702 InternalLoggerFactory.java:63 - Using
> SLF4J as the default logging framework
> DEBUG [main] 2022-03-19 15:41:04,712 InternalThreadLocalMap.java:83 -
> -Dio.netty.threadLocalMap.stringBuilder.initialSize: 1024
> DEBUG [main] 2022-03-19 15:41:04,712 InternalThreadLocalMap.java:86 -
> -Dio.netty.threadLocalMap.stringBuilder.maxSize: 4096
> INFO [main] 2022-03-19 15:41:04,713 CipherFactory.java:68 - initializing
> CipherFactory
> INFO [main] 2022-03-19 15:41:04,713 JKSKeyPro
> ...[truncated 1879728 chars]...
> tLog-7-1647704466908.log
> INFO [main] 2022-03-19 15:41:26,711 CommitLog.java:175 - No commitlog files
> found; skipping replay
> DEBUG [main] 2022-03-19 15:41:28,150 Commit
[jira] [Created] (CASSANDRA-17661) Adding support to perform certificate based internode authentication
Jyothsna Konisa created CASSANDRA-17661: --- Summary: Adding support to perform certificate based internode authentication Key: CASSANDRA-17661 URL: https://issues.apache.org/jira/browse/CASSANDRA-17661 Project: Cassandra Issue Type: New Feature Reporter: Jyothsna Konisa Assignee: Jyothsna Konisa Changes are to be made in IInternodeAuthenticator interface to support certificate based authentication and to add a new pipeline in InboundConnectionInitiator should be added to perform certificate based authentication for internode communications. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
