[jira] [Updated] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuqi Gu updated CASSANDRA-17019: Attachment: UTs_snappy_upgrading.txt > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428594#comment-17428594
]
Yuqi Gu commented on CASSANDRA-17019:
-
After upgrading snappy to latest version, all unit tests are passed except one:
{code:java}
org.apache.cassandra.net.MessagingServiceTest
{code}
{code:java}
[junit-timeout] Testsuite: org.apache.cassandra.net.MessagingServiceTest
[junit-timeout] Testsuite: org.apache.cassandra.net.MessagingServiceTest Tests
run: 14, Failures: 2, Errors: 4, Skipped: 0, Time elapsed: 1.502 sec
[junit-timeout]
[junit-timeout] Testcase:
listenRequiredSecureConnectionWithBroadcastAddrAndLegacyPort(org.apache.cassandra.net.MessagingServiceTest):
Caused an ERROR
[junit-timeout] failed to bind to: /127.0.0.2:17012
[junit-timeout] org.apache.cassandra.exceptions.ConfigurationException: failed
to bind to: /127.0.0.2:17012
[junit-timeout] at
org.apache.cassandra.net.InboundConnectionInitiator.bind(InboundConnectionInitiator.java:189)
[junit-timeout] at
org.apache.cassandra.net.InboundConnectionInitiator.bind(InboundConnectionInitiator.java:199)
[junit-timeout] at
org.apache.cassandra.net.InboundSockets$InboundSocket.open(InboundSockets.java:100)
[junit-timeout] at
org.apache.cassandra.net.InboundSockets$InboundSocket.open(InboundSockets.java:87)
[junit-timeout] at
org.apache.cassandra.net.InboundSockets.open(InboundSockets.java:236)
[junit-timeout] at
org.apache.cassandra.net.MessagingServiceTest.listen(MessagingServiceTest.java:342)
[junit-timeout] at
org.apache.cassandra.net.MessagingServiceTest.listenRequiredSecureConnectionWithBroadcastAddrAndLegacyPort(MessagingServiceTest.java:307)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout] Caused by: java.net.BindException: Can't assign requested
address
[junit-timeout] at java.base/sun.nio.ch.Net.bind0(Native Method)
[junit-timeout] at java.base/sun.nio.ch.Net.bind(Net.java:455)
[junit-timeout] at java.base/sun.nio.ch.Net.bind(Net.java:447)
[junit-timeout] at
java.base/sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:227)
[junit-timeout] at
io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:134)
[junit-timeout] at
io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:550)
[junit-timeout] at
io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1334)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:506)
[junit-timeout] at
io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:491)
[junit-timeout] at
io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:973)
[junit-timeout] at
io.netty.channel.AbstractChannel.bind(AbstractChannel.java:248)
[junit-timeout] at
io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:356)
[junit-timeout] at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
[junit-timeout] at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
[junit-timeout] at
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
[junit-timeout] at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
[junit-timeout] at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
[junit-timeout] at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[junit-timeout] at java.base/java.lang.Thread.run(Thread.java:829)
[junit-timeout]
[junit-timeout]
{code}
> JNA 5.6.0 does not support arm64
>
>
> Key: CASSANDRA-17019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17019
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Igamr Palsenberg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1
>
> Attachments: cassandra_UTs.txt
>
>
> Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native
> binding into the C library.
> JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing
> cassandra to fail on bootstrap.
> Bumping the dependency to 5.9.0 adds arm64 support. Will a PR
[jira] [Commented] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428593#comment-17428593
]
Yuqi Gu commented on CASSANDRA-17040:
-
The PR: https://github.com/apache/cassandra/pull/1268
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuqi Gu updated CASSANDRA-17040:
Test and Documentation Plan: The PR:
https://github.com/apache/cassandra/pull/1268
Status: Patch Available (was: In Progress)
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuqi Gu updated CASSANDRA-17040:
Comment: was deleted
(was: The PR: https://github.com/apache/cassandra/pull/1268)
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuqi Gu updated CASSANDRA-17040:
Attachment: UTs.txt
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428585#comment-17428585 ] Yuqi Gu edited comment on CASSANDRA-17019 at 10/14/21, 3:06 AM: [~djoshi] Yes, snappy-java didn't support Apple M1 until 1.1.8.2 release. [~stefan.miklosovic] I upgraded snappy to the latest verison 1.1.8.4 to support M1: https://github.com/apache/cassandra/pull/1268 The releated unit tests were passed and the logs will be attached to CASSANDRA-17040 soon. was (Author: yqgu): [~djoshi] Yes, snappy-java didn't support Apple M1 until 1.1.8.2 release. [~stefan.miklosovic] I upgraded snappy to the latest verison 1.1.8.4 to support M1: https://github.com/apache/cassandra/pull/1268 The unit tests were passed and the logs will be attached to CASSANDRA-17040 soon. > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Attachments: cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428585#comment-17428585 ] Yuqi Gu edited comment on CASSANDRA-17019 at 10/14/21, 3:01 AM: [~djoshi] Yes, snappy-java didn't support Apple M1 until 1.1.8.2 release. [~stefan.miklosovic] I upgraded snappy to the latest verison 1.1.8.4 to support M1: https://github.com/apache/cassandra/pull/1268 The unit tests were passed and the logs will be attached to CASSANDRA-17040 soon. was (Author: yqgu): [~djoshi] Yes, snappy-java didn't support Apple M1 until 1.1.8.2 release. [~stefan.miklosovic] I upgraded snappy to the latest verison 1.1.8.4 to support M1: https://github.com/apache/cassandra/pull/1256 The unit tests were passed and the logs will be attached to CASSANDRA-17040 soon. > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Attachments: cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428585#comment-17428585 ] Yuqi Gu commented on CASSANDRA-17019: - [~djoshi] Yes, snappy-java didn't support Apple M1 until 1.1.8.2 release. [~stefan.miklosovic] I upgraded snappy to the latest verison 1.1.8.4 to support M1: https://github.com/apache/cassandra/pull/1256 The unit tests were passed and the logs will be attached to CASSANDRA-17040 soon. > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Attachments: cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17031) Add support for PEM based key material for SSL
[
https://issues.apache.org/jira/browse/CASSANDRA-17031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428584#comment-17428584
]
Maulin Vasavada edited comment on CASSANDRA-17031 at 10/14/21, 2:59 AM:
[~dchenbecker] I looked at the ticket you provided. Thanks for the contribution
and improving the security posture of Apache Cassandra. I am okay to do
something similar for the SSL encryption options but have a feeling that it
could be a follow-up ticket to keep the scope clearer. We will have to make
change for the DefaultSslContextFactory also along with the PEM based ssl
factory for reading the password from a file. Based on others' feedback I am
open to take up that work as part of this ticket OR another ticket.
[~jonmeredith] and others, please provide your thoughts on the same.
was (Author: maulin.vasavada):
[~dchenbecker] I looked at the ticket you provided. Thanks for the contribution
and improving the security posture of Apache Cassandra. I am okay to do
something similar for the SSL encryption options but have a feeling that it
could be a follow-up ticket to keep the scope clearer. We will have to make
change for the DefaultSslContextFactory also along with the PEM based ssl
factory for reading the password from a file. Based on other's feedback I am
open to take up that work as part of this ticket OR another ticket.
[~jonmeredith] and others, please provide your thoughts on the same.
> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL
> keys/certificates. The scope of this enhancement is to add support for PEM
> based key material (keys/certificate) given that PEM is widely used common
> format for the same. We intend to add support for Password Based Encrypted
> (PBE) PEM Private Keys with standard algorithms along with the certificate
> chain for the private key and PEM based certificates. The work here is going
> to be built on top of [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
> for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values
> input OR via the file (configured with keystore and truststore configurations
> today). We are not going to model PEM as a valid 'store_type' given that
> 'store_type' has a [specific
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>
> h1. Approach
> Create an implementation for
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
> extending
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
> implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates
> and Apache Cassandra's current implementation lacks the support for
> specifying the PEM formatted key material for SSL configurations. This means
> operators have to re-create the key material to comply to the supported
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an
> operational task for managing it. This is an operational overhead we can
> avoid by supporting the PEM format making Apache Cassandra even more customer
> friendly and drive more adoption.
> h1. Proposed Changes
> # A new implementation for ISslContextFactory - PEMBasedSslContextFactory
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options: }}
> {{}}{{ssl_context_factory:}}
> {{}}{{class_name:
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
> {{}}{{parameters:}}
> {{ }}{{private_key: certificate chain>}}
> {{ }}{{private_key_password: {{key }}{{if}} {{it is encrypted>}}
> {{ }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the
> 'private_key_password'. However PEM encoded private key is not a 'keystore'
> in itself hence it would be inappropriate to piggyback on that other than
> avoid duplicating similar fields.
> # The PEMBasedSslContextFactory will also support file based key material
> (and the
[jira] [Commented] (CASSANDRA-17031) Add support for PEM based key material for SSL
[
https://issues.apache.org/jira/browse/CASSANDRA-17031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428584#comment-17428584
]
Maulin Vasavada commented on CASSANDRA-17031:
-
[~dchenbecker] I looked at the ticket you provided. Thanks for the contribution
and improving the security posture of Apache Cassandra. I am okay to do
something similar for the SSL encryption options but have a feeling that it
could be a follow-up ticket to keep the scope clearer. We will have to make
change for the DefaultSslContextFactory also along with the PEM based ssl
factory for reading the password from a file. Based on other's feedback I am
open to take up that work as part of this ticket OR another ticket.
[~jonmeredith] and others, please provide your thoughts on the same.
> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL
> keys/certificates. The scope of this enhancement is to add support for PEM
> based key material (keys/certificate) given that PEM is widely used common
> format for the same. We intend to add support for Password Based Encrypted
> (PBE) PEM Private Keys with standard algorithms along with the certificate
> chain for the private key and PEM based certificates. The work here is going
> to be built on top of [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
> for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values
> input OR via the file (configured with keystore and truststore configurations
> today). We are not going to model PEM as a valid 'store_type' given that
> 'store_type' has a [specific
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>
> h1. Approach
> Create an implementation for
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
> extending
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
> implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates
> and Apache Cassandra's current implementation lacks the support for
> specifying the PEM formatted key material for SSL configurations. This means
> operators have to re-create the key material to comply to the supported
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an
> operational task for managing it. This is an operational overhead we can
> avoid by supporting the PEM format making Apache Cassandra even more customer
> friendly and drive more adoption.
> h1. Proposed Changes
> # A new implementation for ISslContextFactory - PEMBasedSslContextFactory
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options: }}
> {{}}{{ssl_context_factory:}}
> {{}}{{class_name:
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
> {{}}{{parameters:}}
> {{ }}{{private_key: certificate chain>}}
> {{ }}{{private_key_password: {{key }}{{if}} {{it is encrypted>}}
> {{ }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the
> 'private_key_password'. However PEM encoded private key is not a 'keystore'
> in itself hence it would be inappropriate to piggyback on that other than
> avoid duplicating similar fields.
> # The PEMBasedSslContextFactory will also support file based key material
> (and the corresponding HOT Reloading based on file timestamp updates) for the
> PEM format via existing 'keystore' and 'truststore' encryption options.
> However in that case the 'truststore_password' configuration won't be used
> since generally PEM formatted certificates for truststore don't get encrypted
> with a password.
> # The PEMBasedSslContextFactory will internally create PKCS12 keystore for
> private key and the trusted certificates. However, this doesn't impact the
> user of the implementation in anyway and it is mentioned for clarity only.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CASSANDRA-17031) Add support for PEM based key material for SSL
[
https://issues.apache.org/jira/browse/CASSANDRA-17031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428583#comment-17428583
]
Maulin Vasavada commented on CASSANDRA-17031:
-
[PR# 1267|https://github.com/apache/cassandra/pull/1267] Raised.
[~dchenbecker] let me look at the ticket you provided and will update here with
my thoughts.
> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL
> keys/certificates. The scope of this enhancement is to add support for PEM
> based key material (keys/certificate) given that PEM is widely used common
> format for the same. We intend to add support for Password Based Encrypted
> (PBE) PEM Private Keys with standard algorithms along with the certificate
> chain for the private key and PEM based certificates. The work here is going
> to be built on top of [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
> for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values
> input OR via the file (configured with keystore and truststore configurations
> today). We are not going to model PEM as a valid 'store_type' given that
> 'store_type' has a [specific
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>
> h1. Approach
> Create an implementation for
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
> extending
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
> implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates
> and Apache Cassandra's current implementation lacks the support for
> specifying the PEM formatted key material for SSL configurations. This means
> operators have to re-create the key material to comply to the supported
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an
> operational task for managing it. This is an operational overhead we can
> avoid by supporting the PEM format making Apache Cassandra even more customer
> friendly and drive more adoption.
> h1. Proposed Changes
> # A new implementation for ISslContextFactory - PEMBasedSslContextFactory
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options: }}
> {{}}{{ssl_context_factory:}}
> {{}}{{class_name:
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
> {{}}{{parameters:}}
> {{ }}{{private_key: certificate chain>}}
> {{ }}{{private_key_password: {{key }}{{if}} {{it is encrypted>}}
> {{ }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the
> 'private_key_password'. However PEM encoded private key is not a 'keystore'
> in itself hence it would be inappropriate to piggyback on that other than
> avoid duplicating similar fields.
> # The PEMBasedSslContextFactory will also support file based key material
> (and the corresponding HOT Reloading based on file timestamp updates) for the
> PEM format via existing 'keystore' and 'truststore' encryption options.
> However in that case the 'truststore_password' configuration won't be used
> since generally PEM formatted certificates for truststore don't get encrypted
> with a password.
> # The PEMBasedSslContextFactory will internally create PKCS12 keystore for
> private key and the trusted certificates. However, this doesn't impact the
> user of the implementation in anyway and it is mentioned for clarity only.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428580#comment-17428580
]
Yuqi Gu commented on CASSANDRA-17040:
-
The PR: https://github.com/apache/cassandra/pull/1268
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuqi Gu updated CASSANDRA-17040:
Change Category: Quality Assurance
Complexity: Normal
Component/s: CI
Fix Version/s: 4.1
Status: Open (was: Triage Needed)
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
Yuqi Gu created CASSANDRA-17040:
---
Summary: Upgrade Snappy version to support Apple M1
Key: CASSANDRA-17040
URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
Project: Cassandra
Issue Type: Task
Reporter: Yuqi Gu
Assignee: Yuqi Gu
Some Unit test cases were failed in Apple M1:
{code:java}
[junit-timeout] Testcase:
testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
Caused an ERROR
[junit-timeout] SnappyCompressor.create() threw an error:
java.lang.NoClassDefFoundError Could not initialize class
org.xerial.snappy.Snappy
[junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError Could
not initialize class org.xerial.snappy.Snappy
[junit-timeout] at
org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
[junit-timeout] at
org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
[junit-timeout] at
org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
[junit-timeout] at
org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
[junit-timeout] at
org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
[junit-timeout] at
...
..
{code}
Snappy-java added M1 support since
1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428554#comment-17428554 ] Dinesh Joshi commented on CASSANDRA-17019: -- It looks like snappy lacks support for M1 Mac. However, it is expected to fall back on a pure Java implementation. > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Attachments: cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16334) Replica failure causes timeout on multi-DC write
[
https://issues.apache.org/jira/browse/CASSANDRA-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428545#comment-17428545
]
Andres de la Peña commented on CASSANDRA-16334:
---
It seems that the new dtest failures in the above CI runs for 3.0 and 3.11 are
caused by a NPE
[here|https://github.com/Ge/cassandra/blob/0cfe205c012605affb06d5a53edcd594e6682c76/src/java/org/apache/cassandra/service/AbstractWriteResponseHandler.java#L125],
where the {{consistencyLevel}} can be {{null}} in the new check for DC local.
> Replica failure causes timeout on multi-DC write
>
>
> Key: CASSANDRA-16334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16334
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Messaging/Internode
>Reporter: Paulo Motta
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws
> a write error on a single DC keyspace with RF=3:
> {noformat}
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 0 responses and 3
> failures: UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN
> from /127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 3}
> {noformat}
> The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
> {noformat}
> cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
> out waiting for replica nodes' responses] message="Operation timed out -
> received only 0 responses." info={'consistency': 'LOCAL_ONE',
> 'required_responses': 1, 'received_responses': 0}
> {noformat}
> Reproduction steps:
> {noformat}
> # Setup cluster
> ccm create -n 3:3 test
> for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
> ~/.ccm/test/node$i/conf/cassandra.yaml; done
> ccm start
> # Create schema
> ccm node1 cqlsh
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': 3, 'dc2': 3};
> CREATE TABLE test.test (key int PRIMARY KEY, val blob);
> exit;
> # Insert data
> python
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect('test')
> blob = f = open("2mbBlob", "rb").read().hex()
> session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob
> + "'))")
> {noformat}
> Reproduced in 3.0, 3.11, 4.0, trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17039) Flaky RepairJobTest.testNoTreesRetainedAfterDifference
[
https://issues.apache.org/jira/browse/CASSANDRA-17039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17039:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Consistency/Repair
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Flaky RepairJobTest.testNoTreesRetainedAfterDifference
> --
>
> Key: CASSANDRA-17039
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17039
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Priority: Normal
>
> Sometimes fails an assertion:
> {noformat}
> Expecting:
> <1L>
> to be less than:
> <1L>
> {noformat}
> https://app.circleci.com/pipelines/github/driftx/cassandra/269/workflows/f2b0a738-0785-4011-9ac1-071837dc9170/jobs/2049/tests#failed-test-1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17039) Flaky RepairJobTest.testNoTreesRetainedAfterDifference
Brandon Williams created CASSANDRA-17039:
Summary: Flaky RepairJobTest.testNoTreesRetainedAfterDifference
Key: CASSANDRA-17039
URL: https://issues.apache.org/jira/browse/CASSANDRA-17039
Project: Cassandra
Issue Type: Bug
Reporter: Brandon Williams
Sometimes fails an assertion:
{noformat}
Expecting:
<1L>
to be less than:
<1L>
{noformat}
https://app.circleci.com/pipelines/github/driftx/cassandra/269/workflows/f2b0a738-0785-4011-9ac1-071837dc9170/jobs/2049/tests#failed-test-1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428420#comment-17428420
]
Igor Marinho edited comment on CASSANDRA-17035 at 10/13/21, 6:46 PM:
-
If I check system.local, right after running nodetool refresh I see that
there's much more tokens in system.local there if I compare to a node that was
not restored.
So that might be the issue.
Restored node.
{code:java}
cassandra@cqlsh> select * from system.local;
key | bootstrapped | broadcast_address | cluster_name | cql_version |
data_center | gossip_generation | host_id |
listen_address | native_protocol_version | partitioner
| rack | release_version | rpc_address | schema_version
| thrift_version | tokens
local | COMPLETED | 10.3...| Test Cluster | 3.4.4 | host |
1634143245 | c71adcfe-da4a-4ffd-9075-a0c0ed8cad21 | 10.3... |
4 | org.apache.cassandra.dht.Murmur3Partitioner | RAC1 |
3.11.10 | 0.0.0.0 | 47221f7f-9bd9-37f5-aff9-285372ee7fa0 | 20.1.0 |
{'-1021394005679452461', '-116301349977861046', '-1203501519365502105',
'-1208413920852887438', '-1240751781389454727', '-1260412322215710658',
'-1280704229750966021', '-1325697168327656348', '-1334402168064352275',
'-1354846238495650154', '-145475374322219502', '-146511291837265934',
'-146986887598593578', '-1479239976274584513', '-1487072689532536365',
'-1497009017160372976', '-1507754632854197529', '-1563326974907065915',
'-1613841171066844101', '-1626825473956036030', '-1644462005777453103',
'-1648035853611899444', '-1669288510978012099', '-1673291358115114310',
'-171883518747067194', '-1723863694942237802', '-1752554923178713249',
'-1781360084802950075', '-1808137525885885333', '-1823805500470334268',
'-1826568182292705682', '-1881405047189430236', '-1924963229922075654',
'-1973687112001756823', '-2061644249712621003', '-2103215668245054389',
'-2186775174047384968', '-2261746752176665649', '-2275622620153487382',
'-2306852353545212292', '-2329680004093421260', '-2379886743287453998',
'-2382984571313137639', '-2387043897442450243', '-2423663358907308008',
'-2423950268597164883', '-2476637378410440090', '-2511975642682719971',
'-2531034491639831011', '-2549902212915920889', '-2550078540930654087',
'-2587427338286755585', '-2628679213666263035', '-2688477754522977996',
'-2692230791886294589', '-2741442430280852619', '-2829557734855296072',
'-2844582037376483603', '-2845213655231971561', '-2849952191151039024',
'-2850721843494280039', '-2874300271514216429', '-2909736656143372790',
'-2938102019559827383', '-295433402350739389', '-2954744758804968703',
'-2975640126853683914', '-3022278519305983437', '-306444003028887010',
'-3088327142560900922', '-3101611433127953962', '-3117328597598811642',
'-3131771639852906126', '-3184762723624534765', '-3211123934860055222',
'-3275282712386823667', '-327859460317128173', '-3280861492062461918',
'-3292627522356286974', '-3329530734112080999', '-3341512071177780524',
'-3360215235853799432', '-3362809701087184729', '-3431124252203739671',
'-3432376460806882187', '-3533738709737801508', '-3557137303149960757',
'-3561375572763321106', '-3607634439492696846', '-3727996953730819569',
'-3741641353952303029', '-3754431892152953784', '-3810534252137765339',
'-3845559653175654026', '-3921662872706735069', '-3945522311425185129',
'-3959326405440087526', '-3982913372229308455', '-4033123509656229318',
'-4056894722661251326', '-4059554842621765281', '-4070627395329080474',
'-4106476253034676416', '-4201821365868828288', '-4223883475507906585',
'-4225028339767719402', '-4286596286182829955', '-4372082325745310219',
'-4376744870130476471', '-4426141004974672187', '-443237035977592',
'-4450258231306912382', '-4478810433687273860', '-4484838772580062469',
'-451693707053239734', '-4526718697447241143', '-455457144104943995',
'-4586640003036731697', '-4690909964455979541', '-4708323223360694475',
'-4808363746569486770', '-483576491880981440', '-484916362066107361',
'-4903034841137436408', '-4973244600755271209', '-5011867417617467884',
'-5068075856879764356', '-5186154146231194796', '-5198822099030782681',
'-5206136260947175009', '-5219210914680530374', '-5235509047688493416',
'-5264254858846919539', '-53166251057589790', '-5373454877497455134',
'-5492454721446074158', '-5501924457540508052', '-5502130642209022868',
'-5536642808156127441', '-5592250866944585536', '-5609551317179694873',
'-5667680681023087864', '-5685137719487130792', '-5691830136187870799',
'-5732248234429679498', '-5768707478970718871', '-5802173364943821505',
'-5818260679729824797', '-5843530573449713821', '-5848483163962964587',
'-5861694505974745652',
[jira] [Comment Edited] (CASSANDRA-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428420#comment-17428420
]
Igor Marinho edited comment on CASSANDRA-17035 at 10/13/21, 6:46 PM:
-
If I check system.local, right after running nodetool refresh I see that
there's double of the tokens in system.local there if I compare to a node that
was not restored.
So that might be the issue.
Restored node.
{code:java}
cassandra@cqlsh> select * from system.local;
key | bootstrapped | broadcast_address | cluster_name | cql_version |
data_center | gossip_generation | host_id |
listen_address | native_protocol_version | partitioner
| rack | release_version | rpc_address | schema_version
| thrift_version | tokens
local | COMPLETED | 10.3...| Test Cluster | 3.4.4 | host |
1634143245 | c71adcfe-da4a-4ffd-9075-a0c0ed8cad21 | 10.3... |
4 | org.apache.cassandra.dht.Murmur3Partitioner | RAC1 |
3.11.10 | 0.0.0.0 | 47221f7f-9bd9-37f5-aff9-285372ee7fa0 | 20.1.0 |
{'-1021394005679452461', '-116301349977861046', '-1203501519365502105',
'-1208413920852887438', '-1240751781389454727', '-1260412322215710658',
'-1280704229750966021', '-1325697168327656348', '-1334402168064352275',
'-1354846238495650154', '-145475374322219502', '-146511291837265934',
'-146986887598593578', '-1479239976274584513', '-1487072689532536365',
'-1497009017160372976', '-1507754632854197529', '-1563326974907065915',
'-1613841171066844101', '-1626825473956036030', '-1644462005777453103',
'-1648035853611899444', '-1669288510978012099', '-1673291358115114310',
'-171883518747067194', '-1723863694942237802', '-1752554923178713249',
'-1781360084802950075', '-1808137525885885333', '-1823805500470334268',
'-1826568182292705682', '-1881405047189430236', '-1924963229922075654',
'-1973687112001756823', '-2061644249712621003', '-2103215668245054389',
'-2186775174047384968', '-2261746752176665649', '-2275622620153487382',
'-2306852353545212292', '-2329680004093421260', '-2379886743287453998',
'-2382984571313137639', '-2387043897442450243', '-2423663358907308008',
'-2423950268597164883', '-2476637378410440090', '-2511975642682719971',
'-2531034491639831011', '-2549902212915920889', '-2550078540930654087',
'-2587427338286755585', '-2628679213666263035', '-2688477754522977996',
'-2692230791886294589', '-2741442430280852619', '-2829557734855296072',
'-2844582037376483603', '-2845213655231971561', '-2849952191151039024',
'-2850721843494280039', '-2874300271514216429', '-2909736656143372790',
'-2938102019559827383', '-295433402350739389', '-2954744758804968703',
'-2975640126853683914', '-3022278519305983437', '-306444003028887010',
'-3088327142560900922', '-3101611433127953962', '-3117328597598811642',
'-3131771639852906126', '-3184762723624534765', '-3211123934860055222',
'-3275282712386823667', '-327859460317128173', '-3280861492062461918',
'-3292627522356286974', '-3329530734112080999', '-3341512071177780524',
'-3360215235853799432', '-3362809701087184729', '-3431124252203739671',
'-3432376460806882187', '-3533738709737801508', '-3557137303149960757',
'-3561375572763321106', '-3607634439492696846', '-3727996953730819569',
'-3741641353952303029', '-3754431892152953784', '-3810534252137765339',
'-3845559653175654026', '-3921662872706735069', '-3945522311425185129',
'-3959326405440087526', '-3982913372229308455', '-4033123509656229318',
'-4056894722661251326', '-4059554842621765281', '-4070627395329080474',
'-4106476253034676416', '-4201821365868828288', '-4223883475507906585',
'-4225028339767719402', '-4286596286182829955', '-4372082325745310219',
'-4376744870130476471', '-4426141004974672187', '-443237035977592',
'-4450258231306912382', '-4478810433687273860', '-4484838772580062469',
'-451693707053239734', '-4526718697447241143', '-455457144104943995',
'-4586640003036731697', '-4690909964455979541', '-4708323223360694475',
'-4808363746569486770', '-483576491880981440', '-484916362066107361',
'-4903034841137436408', '-4973244600755271209', '-5011867417617467884',
'-5068075856879764356', '-5186154146231194796', '-5198822099030782681',
'-5206136260947175009', '-5219210914680530374', '-5235509047688493416',
'-5264254858846919539', '-53166251057589790', '-5373454877497455134',
'-5492454721446074158', '-5501924457540508052', '-5502130642209022868',
'-5536642808156127441', '-5592250866944585536', '-5609551317179694873',
'-5667680681023087864', '-5685137719487130792', '-5691830136187870799',
'-5732248234429679498', '-5768707478970718871', '-5802173364943821505',
'-5818260679729824797', '-5843530573449713821', '-5848483163962964587',
'-5861694505974745652',
[jira] [Commented] (CASSANDRA-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428420#comment-17428420
]
Igor Marinho commented on CASSANDRA-17035:
--
If I check system.local, right after running nodetool refresh I see that
there's double of the tokens in system.local there if I compare to a node that
was not restored.
So that might be the issue.
{code:java}
cassandra@cqlsh> select * from system.local;
key | bootstrapped | broadcast_address | cluster_name | cql_version |
data_center | gossip_generation | host_id |
listen_address | native_protocol_version | partitioner
| rack | release_version | rpc_address | schema_version
| thrift_version | tokens
local | COMPLETED | 10.3...| Test Cluster | 3.4.4 | host |
1634143245 | c71adcfe-da4a-4ffd-9075-a0c0ed8cad21 | 10.3... |
4 | org.apache.cassandra.dht.Murmur3Partitioner | RAC1 |
3.11.10 | 0.0.0.0 | 47221f7f-9bd9-37f5-aff9-285372ee7fa0 | 20.1.0 |
{'-1021394005679452461', '-116301349977861046', '-1203501519365502105',
'-1208413920852887438', '-1240751781389454727', '-1260412322215710658',
'-1280704229750966021', '-1325697168327656348', '-1334402168064352275',
'-1354846238495650154', '-145475374322219502', '-146511291837265934',
'-146986887598593578', '-1479239976274584513', '-1487072689532536365',
'-1497009017160372976', '-1507754632854197529', '-1563326974907065915',
'-1613841171066844101', '-1626825473956036030', '-1644462005777453103',
'-1648035853611899444', '-1669288510978012099', '-1673291358115114310',
'-171883518747067194', '-1723863694942237802', '-1752554923178713249',
'-1781360084802950075', '-1808137525885885333', '-1823805500470334268',
'-1826568182292705682', '-1881405047189430236', '-1924963229922075654',
'-1973687112001756823', '-2061644249712621003', '-2103215668245054389',
'-2186775174047384968', '-2261746752176665649', '-2275622620153487382',
'-2306852353545212292', '-2329680004093421260', '-2379886743287453998',
'-2382984571313137639', '-2387043897442450243', '-2423663358907308008',
'-2423950268597164883', '-2476637378410440090', '-2511975642682719971',
'-2531034491639831011', '-2549902212915920889', '-2550078540930654087',
'-2587427338286755585', '-2628679213666263035', '-2688477754522977996',
'-2692230791886294589', '-2741442430280852619', '-2829557734855296072',
'-2844582037376483603', '-2845213655231971561', '-2849952191151039024',
'-2850721843494280039', '-2874300271514216429', '-2909736656143372790',
'-2938102019559827383', '-295433402350739389', '-2954744758804968703',
'-2975640126853683914', '-3022278519305983437', '-306444003028887010',
'-3088327142560900922', '-3101611433127953962', '-3117328597598811642',
'-3131771639852906126', '-3184762723624534765', '-3211123934860055222',
'-3275282712386823667', '-327859460317128173', '-3280861492062461918',
'-3292627522356286974', '-3329530734112080999', '-3341512071177780524',
'-3360215235853799432', '-3362809701087184729', '-3431124252203739671',
'-3432376460806882187', '-3533738709737801508', '-3557137303149960757',
'-3561375572763321106', '-3607634439492696846', '-3727996953730819569',
'-3741641353952303029', '-3754431892152953784', '-3810534252137765339',
'-3845559653175654026', '-3921662872706735069', '-3945522311425185129',
'-3959326405440087526', '-3982913372229308455', '-4033123509656229318',
'-4056894722661251326', '-4059554842621765281', '-4070627395329080474',
'-4106476253034676416', '-4201821365868828288', '-4223883475507906585',
'-4225028339767719402', '-4286596286182829955', '-4372082325745310219',
'-4376744870130476471', '-4426141004974672187', '-443237035977592',
'-4450258231306912382', '-4478810433687273860', '-4484838772580062469',
'-451693707053239734', '-4526718697447241143', '-455457144104943995',
'-4586640003036731697', '-4690909964455979541', '-4708323223360694475',
'-4808363746569486770', '-483576491880981440', '-484916362066107361',
'-4903034841137436408', '-4973244600755271209', '-5011867417617467884',
'-5068075856879764356', '-5186154146231194796', '-5198822099030782681',
'-5206136260947175009', '-5219210914680530374', '-5235509047688493416',
'-5264254858846919539', '-53166251057589790', '-5373454877497455134',
'-5492454721446074158', '-5501924457540508052', '-5502130642209022868',
'-5536642808156127441', '-5592250866944585536', '-5609551317179694873',
'-5667680681023087864', '-5685137719487130792', '-5691830136187870799',
'-5732248234429679498', '-5768707478970718871', '-5802173364943821505',
'-5818260679729824797', '-5843530573449713821', '-5848483163962964587',
'-5861694505974745652', '-5897480853924739187', '-6015673644682890306',
'-6070359467944652843',
[jira] [Assigned] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tatu Saloranta reassigned CASSANDRA-15453:
--
Assignee: (was: Tatu Saloranta)
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tatu Saloranta reassigned CASSANDRA-15453:
--
Assignee: Tatu Saloranta
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Assignee: Tatu Saloranta
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428357#comment-17428357
]
Tatu Saloranta edited comment on CASSANDRA-15453 at 10/13/21, 6:37 PM:
---
Also created second PR:
[https://github.com/apache/cassandra/pull/1266]
which upgrades Guava to 25.1-jre. One change I am unsure about is to
`cassandra-driver-core`: upgrade to (at least) 3.2.0 is a must wrt Guava, but
there are some issues with protocol handling that I hope will not complicate
actual operation, but that required a small (? ) change to test code.
All local tests (ant test) pass with these changes as well (first had fails
before upgrading Airline dependency) so would need to get full integration
tests done next.
was (Author: cowtowncoder):
Also created second PR:
[https://github.com/apache/cassandra/pull/1266]
which upgrades Guava to 25.1-jre. One change I am unsure about is to
`cassandra-driver-core`: upgrade to (at least) 3.2.0 is a must wrt Guava, but
there are some issues with protocol handling that I hope will not complicate
actual operation, but that required a small (? ) change to test code.
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17038) InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming the logs
[
https://issues.apache.org/jira/browse/CASSANDRA-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428398#comment-17428398
]
Brandon Williams commented on CASSANDRA-17038:
--
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17038]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17038]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17038-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17038-trunk]|
Between making this nospam or pushing to trace, I decided on trace since with
nospam if you do have a connection flooding issue, you won't have any way to
tell from the logs. We could of course do both, but that seems like overkill
here.
> InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming
> the logs
> --
>
> Key: CASSANDRA-17038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17038
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Francesco Animali
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> incoming client requests are generating DEBUG messages that spam the logs:
> DEBUG [epollEventLoopGroup-5-30] 2021-10-12 04:55:01,014
> InitialConnectionHandler.java:153 - Configured pipeline:
> DefaultChannelPipeline\{(envelopeDecoder =
> org.apache.cassandra.transport.Envelope$Decoder), (envelopeEncoder=
> org.apache.cassandra.transport.Envelope$Encoder), (decompressor =
> org.apache.cassandra.transport.Envelope$Decompressor), (compressor =
> org.apache.cassandra.transport.Envelope$Compressor), (messageDecoder
> =org.apache.cassandra.transport.PreV5Handlers$ProtocolDecoder),
> (messageEncoder =
> org.apache.cassandra.transport.PreV5Handlers$ProtocolEncoder),
> (legacyCqlProcessor
> =org.apache.cassandra.transport.PreV5Handlers$LegacyDispatchHandler),
> (exceptionHandler =
> org.apache.cassandra.transport.PreV5Handlers$ExceptionHandler)}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17038) InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming the logs
[
https://issues.apache.org/jira/browse/CASSANDRA-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17038:
-
Test and Documentation Plan: Run CI
Status: Patch Available (was: Open)
> InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming
> the logs
> --
>
> Key: CASSANDRA-17038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17038
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Francesco Animali
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> incoming client requests are generating DEBUG messages that spam the logs:
> DEBUG [epollEventLoopGroup-5-30] 2021-10-12 04:55:01,014
> InitialConnectionHandler.java:153 - Configured pipeline:
> DefaultChannelPipeline\{(envelopeDecoder =
> org.apache.cassandra.transport.Envelope$Decoder), (envelopeEncoder=
> org.apache.cassandra.transport.Envelope$Encoder), (decompressor =
> org.apache.cassandra.transport.Envelope$Decompressor), (compressor =
> org.apache.cassandra.transport.Envelope$Compressor), (messageDecoder
> =org.apache.cassandra.transport.PreV5Handlers$ProtocolDecoder),
> (messageEncoder =
> org.apache.cassandra.transport.PreV5Handlers$ProtocolEncoder),
> (legacyCqlProcessor
> =org.apache.cassandra.transport.PreV5Handlers$LegacyDispatchHandler),
> (exceptionHandler =
> org.apache.cassandra.transport.PreV5Handlers$ExceptionHandler)}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17038) InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming the logs
[
https://issues.apache.org/jira/browse/CASSANDRA-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17038:
Assignee: Brandon Williams
> InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming
> the logs
> --
>
> Key: CASSANDRA-17038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17038
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Francesco Animali
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> incoming client requests are generating DEBUG messages that spam the logs:
> DEBUG [epollEventLoopGroup-5-30] 2021-10-12 04:55:01,014
> InitialConnectionHandler.java:153 - Configured pipeline:
> DefaultChannelPipeline\{(envelopeDecoder =
> org.apache.cassandra.transport.Envelope$Decoder), (envelopeEncoder=
> org.apache.cassandra.transport.Envelope$Encoder), (decompressor =
> org.apache.cassandra.transport.Envelope$Decompressor), (compressor =
> org.apache.cassandra.transport.Envelope$Compressor), (messageDecoder
> =org.apache.cassandra.transport.PreV5Handlers$ProtocolDecoder),
> (messageEncoder =
> org.apache.cassandra.transport.PreV5Handlers$ProtocolEncoder),
> (legacyCqlProcessor
> =org.apache.cassandra.transport.PreV5Handlers$LegacyDispatchHandler),
> (exceptionHandler =
> org.apache.cassandra.transport.PreV5Handlers$ExceptionHandler)}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10303) streaming for 'nodetool rebuild' fails after adding a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-10303:
-
Resolution: Fixed
Status: Resolved (was: Open)
> streaming for 'nodetool rebuild' fails after adding a datacenter
> -
>
> Key: CASSANDRA-10303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10303
> Project: Cassandra
> Issue Type: Bug
> Environment: jdk1.7
> cassandra 2.1.8
>Reporter: zhaoyan
>Assignee: Yuki Morishita
>Priority: Normal
>
> we add another datacenter.
> use nodetool rebuild DC1
> stream from some node of old datacenter always hang up with these exception:
> {code}
> ERROR [Thread-1472] 2015-09-10 19:24:53,091 CassandraDaemon.java:223 -
> Exception in thread Thread[Thread-1472,5,RMI Runtime]
> java.lang.RuntimeException: java.io.IOException: Connection timed out
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> Caused by: java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.7.0_60]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:59)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> ~[na:1.7.0_60]
> at
> org.apache.cassandra.streaming.compress.CompressedInputStream$Reader.runMayThrow(CompressedInputStream.java:172)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> ... 1 common frames omitted
> {code}
> i must restart node to stop current rebuild, and rebuild agagin and again to
> success
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10303) streaming for 'nodetool rebuild' fails after adding a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guang Zhao updated CASSANDRA-10303:
---
Mentor: Yuki Morishita
Resolution: (was: Fixed)
Status: Open (was: Resolved)
> streaming for 'nodetool rebuild' fails after adding a datacenter
> -
>
> Key: CASSANDRA-10303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10303
> Project: Cassandra
> Issue Type: Bug
> Environment: jdk1.7
> cassandra 2.1.8
>Reporter: zhaoyan
>Assignee: Yuki Morishita
>Priority: Normal
>
> we add another datacenter.
> use nodetool rebuild DC1
> stream from some node of old datacenter always hang up with these exception:
> {code}
> ERROR [Thread-1472] 2015-09-10 19:24:53,091 CassandraDaemon.java:223 -
> Exception in thread Thread[Thread-1472,5,RMI Runtime]
> java.lang.RuntimeException: java.io.IOException: Connection timed out
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> Caused by: java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.7.0_60]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:59)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> ~[na:1.7.0_60]
> at
> org.apache.cassandra.streaming.compress.CompressedInputStream$Reader.runMayThrow(CompressedInputStream.java:172)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> ... 1 common frames omitted
> {code}
> i must restart node to stop current rebuild, and rebuild agagin and again to
> success
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-10303) streaming for 'nodetool rebuild' fails after adding a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guang Zhao reassigned CASSANDRA-10303:
--
Assignee: Yuki Morishita
> streaming for 'nodetool rebuild' fails after adding a datacenter
> -
>
> Key: CASSANDRA-10303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10303
> Project: Cassandra
> Issue Type: Bug
> Environment: jdk1.7
> cassandra 2.1.8
>Reporter: zhaoyan
>Assignee: Yuki Morishita
>Priority: Normal
>
> we add another datacenter.
> use nodetool rebuild DC1
> stream from some node of old datacenter always hang up with these exception:
> {code}
> ERROR [Thread-1472] 2015-09-10 19:24:53,091 CassandraDaemon.java:223 -
> Exception in thread Thread[Thread-1472,5,RMI Runtime]
> java.lang.RuntimeException: java.io.IOException: Connection timed out
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> Caused by: java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.7.0_60]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:59)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> ~[na:1.7.0_60]
> at
> org.apache.cassandra.streaming.compress.CompressedInputStream$Reader.runMayThrow(CompressedInputStream.java:172)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> ... 1 common frames omitted
> {code}
> i must restart node to stop current rebuild, and rebuild agagin and again to
> success
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10303) streaming for 'nodetool rebuild' fails after adding a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428390#comment-17428390
]
Guang Zhao commented on CASSANDRA-10303:
[~yukim], I am facing the same issue when bootstrap a node into my two-dc
cluster with cassandra version 2.2.13. What was the solution?
> streaming for 'nodetool rebuild' fails after adding a datacenter
> -
>
> Key: CASSANDRA-10303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10303
> Project: Cassandra
> Issue Type: Bug
> Environment: jdk1.7
> cassandra 2.1.8
>Reporter: zhaoyan
>Priority: Normal
>
> we add another datacenter.
> use nodetool rebuild DC1
> stream from some node of old datacenter always hang up with these exception:
> {code}
> ERROR [Thread-1472] 2015-09-10 19:24:53,091 CassandraDaemon.java:223 -
> Exception in thread Thread[Thread-1472,5,RMI Runtime]
> java.lang.RuntimeException: java.io.IOException: Connection timed out
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> Caused by: java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.7.0_60]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:59)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> ~[na:1.7.0_60]
> at
> org.apache.cassandra.streaming.compress.CompressedInputStream$Reader.runMayThrow(CompressedInputStream.java:172)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> ... 1 common frames omitted
> {code}
> i must restart node to stop current rebuild, and rebuild agagin and again to
> success
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-10303) streaming for 'nodetool rebuild' fails after adding a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guang Zhao reassigned CASSANDRA-10303:
--
Assignee: (was: Yuki Sugawara)
> streaming for 'nodetool rebuild' fails after adding a datacenter
> -
>
> Key: CASSANDRA-10303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10303
> Project: Cassandra
> Issue Type: Bug
> Environment: jdk1.7
> cassandra 2.1.8
>Reporter: zhaoyan
>Priority: Normal
>
> we add another datacenter.
> use nodetool rebuild DC1
> stream from some node of old datacenter always hang up with these exception:
> {code}
> ERROR [Thread-1472] 2015-09-10 19:24:53,091 CassandraDaemon.java:223 -
> Exception in thread Thread[Thread-1472,5,RMI Runtime]
> java.lang.RuntimeException: java.io.IOException: Connection timed out
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> Caused by: java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.7.0_60]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:59)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> ~[na:1.7.0_60]
> at
> org.apache.cassandra.streaming.compress.CompressedInputStream$Reader.runMayThrow(CompressedInputStream.java:172)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> ... 1 common frames omitted
> {code}
> i must restart node to stop current rebuild, and rebuild agagin and again to
> success
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-10303) streaming for 'nodetool rebuild' fails after adding a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guang Zhao reassigned CASSANDRA-10303:
--
Assignee: Yuki Sugawara
> streaming for 'nodetool rebuild' fails after adding a datacenter
> -
>
> Key: CASSANDRA-10303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10303
> Project: Cassandra
> Issue Type: Bug
> Environment: jdk1.7
> cassandra 2.1.8
>Reporter: zhaoyan
>Assignee: Yuki Sugawara
>Priority: Normal
>
> we add another datacenter.
> use nodetool rebuild DC1
> stream from some node of old datacenter always hang up with these exception:
> {code}
> ERROR [Thread-1472] 2015-09-10 19:24:53,091 CassandraDaemon.java:223 -
> Exception in thread Thread[Thread-1472,5,RMI Runtime]
> java.lang.RuntimeException: java.io.IOException: Connection timed out
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> Caused by: java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.7.0_60]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:59)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> ~[na:1.7.0_60]
> at
> org.apache.cassandra.streaming.compress.CompressedInputStream$Reader.runMayThrow(CompressedInputStream.java:172)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> ... 1 common frames omitted
> {code}
> i must restart node to stop current rebuild, and rebuild agagin and again to
> success
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428357#comment-17428357
]
Tatu Saloranta commented on CASSANDRA-15453:
Also created second PR:
[https://github.com/apache/cassandra/pull/1266]
which upgrades Guava to 25.1-jre. One change I am unsure about is to
`cassandra-driver-core`: upgrade to (at least) 3.2.0 is a must wrt Guava, but
there are some issues with protocol handling that I hope will not complicate
actual operation, but that required a small (? ) change to test code.
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16882) Save CircleCI resources with optional test jobs
[ https://issues.apache.org/jira/browse/CASSANDRA-16882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16882: -- Status: Ready to Commit (was: Review In Progress) > Save CircleCI resources with optional test jobs > --- > > Key: CASSANDRA-16882 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16882 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > This ticket implements the addition of approval steps in the CircleCI > workflows as it was proposed in [this > email|https://lists.apache.org/thread.html/r57bab800d037c087af01b3779fd266d83b538cdd29c120f74a5dbe63%40%3Cdev.cassandra.apache.org%3E] > sent to the dev list: > The current CircleCI configuration automatically runs the unit tests, JVM > dtests and cqhshlib tests. This is done by default for every commit or, with > some configuration, for every push. > Along the lifecycle of a ticket it is quite frequent to have multiple commits > and pushes, all running these test jobs. I'd say that frequently it is not > necessary to run the tests for some of those intermediate commits and pushes. > For example, one can show proofs of concept, or have multiple rounds of > review before actually running the tests. Running the tests for every change > can produce an unnecessary expense of CircleCI resources. > I think we could make running those tests optional, as well as clearly > specifying in the documentation what are the tests runs that are mandatory > before actually committing. We could do this in different ways: > # Make the entire CircleCI workflow optional, so the build job requires > manual approval. Once the build is approved the mandatory test jobs would > be run without any further approval, exactly as it's currently done. > # Make all the test jobs optional, so every test job requires manual > approval, and the documentation specifies which tests are mandatory in the > final steps of a ticket. > # Make all the mandatory test jobs depend on a single optional job, so we > have a single button to optionally run all the mandatory tests. > I think any of these changes, or a combination of them, would significantly > reduce the usage of resources without making things less tested. The only > downside I can think of is that we would need some additional clicks on the > CircleCI GUI. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428306#comment-17428306
]
Bowen Song commented on CASSANDRA-16956:
[~stefan.miklosovic] Please see PR
https://github.com/instaclustr/cassandra/pull/36
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428304#comment-17428304
]
Josh McKenzie commented on CASSANDRA-16956:
---
{quote}all the comments which are also mentioning the fact that "this has to be
done like that because on Windows
{quote}
Probably should update those to indicate "this was done this way specifically
for windows support which we've deprecated" so future maintainers that come
along know it's safe to change.
Going to take a look now on the review; sorry for the delay.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428298#comment-17428298
]
Bowen Song commented on CASSANDRA-16956:
That's okay. I will do that.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428296#comment-17428296
]
Stefan Miklosovic commented on CASSANDRA-16956:
---
[~Bowen Song] I saw your comments. I think this is beyond my skills here. Would
it be possible for you to actually fork my branch and put all that stuff on top
of that? You may be co-author of this work (reflected in the commit message).
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17032) Allow configuring max allowable disk usage quota by keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428278#comment-17428278 ] Paulo Motta commented on CASSANDRA-17032: - Another thought that ocurred to me is that we should probably make quota validations at the replica end and not at the coordinator, for the following reasons: - prevent inconsistent quota enforcement depending on which coordinator coordinates the request (ie. coordinator A is above quota but not coordinator B) - support non-replica (ie. proxy) coordinators which is a common deployment model and would not be supported if we always assume coordinators are also replicas This would make the patch a bit more involved in order to make the feature more complete and predictable. > Allow configuring max allowable disk usage quota by keyspace > > > Key: CASSANDRA-17032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17032 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > This is a similar idea (basically identical idea; didn't want to steamroll > that old ticket w/an update to description etc) to what was raised and closed > in CASSANDRA-5394. In multi-tenant situations it can be very helpful to > provide disk quotas per Keyspaces for users. > We can do this via a low priority background job that periodically checks > disk usage and flips a bit on the Keyspaces when it's over as well as reverts > it when things settle back down to prevent needing the read-before-write a > hard realtime requirement would introduce. While this would of course allow > users to "burst" their usage past that limit in the time window, it would > still be sufficient for many use-cases. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17032) Allow configuring max allowable disk usage quota by keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428261#comment-17428261 ] Paulo Motta commented on CASSANDRA-17032: - bq. I will point out that the two are not mutually exclusive. Like a compaction strategy, you could define it in the schema but also retain the ability to change it via JMX. This. Even though it's still not perfect, our schema metadata broadcast is much more reliable now and issues are the exception rather than the rule. I think we should be making new features easy to use for new users which don't have the tooling available, and optionally have a JMX safety valve for advanced users to deal with the hairy edge cases. > Allow configuring max allowable disk usage quota by keyspace > > > Key: CASSANDRA-17032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17032 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > This is a similar idea (basically identical idea; didn't want to steamroll > that old ticket w/an update to description etc) to what was raised and closed > in CASSANDRA-5394. In multi-tenant situations it can be very helpful to > provide disk quotas per Keyspaces for users. > We can do this via a low priority background job that periodically checks > disk usage and flips a bit on the Keyspaces when it's over as well as reverts > it when things settle back down to prevent needing the read-before-write a > hard realtime requirement would introduce. While this would of course allow > users to "burst" their usage past that limit in the time window, it would > still be sufficient for many use-cases. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428257#comment-17428257
]
Bowen Song commented on CASSANDRA-16956:
[~stefan.miklosovic] I'm happy to do that.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16828) Add a warning in case of validation failure of replication parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-16828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16828: Resolution: Not A Problem Status: Resolved (was: Open) > Add a warning in case of validation failure of replication parameters > - > > Key: CASSANDRA-16828 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16828 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.x > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16828) Add a warning in case of validation failure of replication parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-16828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428252#comment-17428252 ] Ekaterina Dimitrova commented on CASSANDRA-16828: - This validation is not currently done on startup. Closing the ticket > Add a warning in case of validation failure of replication parameters > - > > Key: CASSANDRA-16828 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16828 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.x > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17032) Allow configuring max allowable disk usage quota by keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428251#comment-17428251 ] Brandon Williams commented on CASSANDRA-17032: -- I will point out that the two are not mutually exclusive. Like a compaction strategy, you could define it in the schema but also retain the ability to change it via JMX. > Allow configuring max allowable disk usage quota by keyspace > > > Key: CASSANDRA-17032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17032 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > This is a similar idea (basically identical idea; didn't want to steamroll > that old ticket w/an update to description etc) to what was raised and closed > in CASSANDRA-5394. In multi-tenant situations it can be very helpful to > provide disk quotas per Keyspaces for users. > We can do this via a low priority background job that periodically checks > disk usage and flips a bit on the Keyspaces when it's over as well as reverts > it when things settle back down to prevent needing the read-before-write a > hard realtime requirement would introduce. While this would of course allow > users to "burst" their usage past that limit in the time window, it would > still be sufficient for many use-cases. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17038) InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming the logs
[
https://issues.apache.org/jira/browse/CASSANDRA-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17038:
-
Fix Version/s: 4.x
4.0.x
> InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming
> the logs
> --
>
> Key: CASSANDRA-17038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17038
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Francesco Animali
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> incoming client requests are generating DEBUG messages that spam the logs:
> DEBUG [epollEventLoopGroup-5-30] 2021-10-12 04:55:01,014
> InitialConnectionHandler.java:153 - Configured pipeline:
> DefaultChannelPipeline\{(envelopeDecoder =
> org.apache.cassandra.transport.Envelope$Decoder), (envelopeEncoder=
> org.apache.cassandra.transport.Envelope$Encoder), (decompressor =
> org.apache.cassandra.transport.Envelope$Decompressor), (compressor =
> org.apache.cassandra.transport.Envelope$Compressor), (messageDecoder
> =org.apache.cassandra.transport.PreV5Handlers$ProtocolDecoder),
> (messageEncoder =
> org.apache.cassandra.transport.PreV5Handlers$ProtocolEncoder),
> (legacyCqlProcessor
> =org.apache.cassandra.transport.PreV5Handlers$LegacyDispatchHandler),
> (exceptionHandler =
> org.apache.cassandra.transport.PreV5Handlers$ExceptionHandler)}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17038) InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming the logs
[
https://issues.apache.org/jira/browse/CASSANDRA-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17038:
-
Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug
Workflow)
Issue Type: Improvement (was: Bug)
> InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming
> the logs
> --
>
> Key: CASSANDRA-17038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17038
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Francesco Animali
>Priority: Normal
>
> incoming client requests are generating DEBUG messages that spam the logs:
> DEBUG [epollEventLoopGroup-5-30] 2021-10-12 04:55:01,014
> InitialConnectionHandler.java:153 - Configured pipeline:
> DefaultChannelPipeline\{(envelopeDecoder =
> org.apache.cassandra.transport.Envelope$Decoder), (envelopeEncoder=
> org.apache.cassandra.transport.Envelope$Encoder), (decompressor =
> org.apache.cassandra.transport.Envelope$Decompressor), (compressor =
> org.apache.cassandra.transport.Envelope$Compressor), (messageDecoder
> =org.apache.cassandra.transport.PreV5Handlers$ProtocolDecoder),
> (messageEncoder =
> org.apache.cassandra.transport.PreV5Handlers$ProtocolEncoder),
> (legacyCqlProcessor
> =org.apache.cassandra.transport.PreV5Handlers$LegacyDispatchHandler),
> (exceptionHandler =
> org.apache.cassandra.transport.PreV5Handlers$ExceptionHandler)}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17038) InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming the logs
[
https://issues.apache.org/jira/browse/CASSANDRA-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17038:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming
> the logs
> --
>
> Key: CASSANDRA-17038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17038
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Francesco Animali
>Priority: Normal
>
> incoming client requests are generating DEBUG messages that spam the logs:
> DEBUG [epollEventLoopGroup-5-30] 2021-10-12 04:55:01,014
> InitialConnectionHandler.java:153 - Configured pipeline:
> DefaultChannelPipeline\{(envelopeDecoder =
> org.apache.cassandra.transport.Envelope$Decoder), (envelopeEncoder=
> org.apache.cassandra.transport.Envelope$Encoder), (decompressor =
> org.apache.cassandra.transport.Envelope$Decompressor), (compressor =
> org.apache.cassandra.transport.Envelope$Compressor), (messageDecoder
> =org.apache.cassandra.transport.PreV5Handlers$ProtocolDecoder),
> (messageEncoder =
> org.apache.cassandra.transport.PreV5Handlers$ProtocolEncoder),
> (legacyCqlProcessor
> =org.apache.cassandra.transport.PreV5Handlers$LegacyDispatchHandler),
> (exceptionHandler =
> org.apache.cassandra.transport.PreV5Handlers$ExceptionHandler)}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17038) InitialConnectionHandler Configured pipeline: DefaultChannelPipeline spamming the logs
Francesco Animali created CASSANDRA-17038:
-
Summary: InitialConnectionHandler Configured pipeline:
DefaultChannelPipeline spamming the logs
Key: CASSANDRA-17038
URL: https://issues.apache.org/jira/browse/CASSANDRA-17038
Project: Cassandra
Issue Type: Bug
Components: Messaging/Client
Reporter: Francesco Animali
incoming client requests are generating DEBUG messages that spam the logs:
DEBUG [epollEventLoopGroup-5-30] 2021-10-12 04:55:01,014
InitialConnectionHandler.java:153 - Configured pipeline:
DefaultChannelPipeline\{(envelopeDecoder =
org.apache.cassandra.transport.Envelope$Decoder), (envelopeEncoder=
org.apache.cassandra.transport.Envelope$Encoder), (decompressor =
org.apache.cassandra.transport.Envelope$Decompressor), (compressor =
org.apache.cassandra.transport.Envelope$Compressor), (messageDecoder
=org.apache.cassandra.transport.PreV5Handlers$ProtocolDecoder), (messageEncoder
= org.apache.cassandra.transport.PreV5Handlers$ProtocolEncoder),
(legacyCqlProcessor
=org.apache.cassandra.transport.PreV5Handlers$LegacyDispatchHandler),
(exceptionHandler =
org.apache.cassandra.transport.PreV5Handlers$ExceptionHandler)}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16902) A user should be able to view permissions of role they created
[
https://issues.apache.org/jira/browse/CASSANDRA-16902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428247#comment-17428247
]
Aleksei Zotov commented on CASSANDRA-16902:
---
[~blerer]
Oh ok, got it. I did not know it is blocked by something else. Sorry for
disturbing!
> A user should be able to view permissions of role they created
> --
>
> Key: CASSANDRA-16902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16902
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently users are denied to view permissions to see a role they created:
> {code}
> CREATE ROLE parent WITH PASSWORD = 'x' AND LOGIN = true;
> GRANT CREATE ON ALL ROLES TO parent;
> LOGIN parent;
> CREATE ROLE child WITH PASSWORD = 'x' AND LOGIN = true;
> LIST ALL PERMISSIONS OF 'child'; -- You are not authorized to view child's
> permissions
> {code}
> When a user creates a role they should get the {{DESCRIBE}} permission on
> that role by default.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17037) Log time spent writing keys during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-17037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17037: Status: Ready to Commit (was: Review In Progress) +1 > Log time spent writing keys during compaction > - > > Key: CASSANDRA-17037 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17037 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While we log a lot of info during compaction, we don't log the time spent > doing so. No reason not to include this for operator visibility and log > analysis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17017) Add required -f / --force option to nodetool verify
[ https://issues.apache.org/jira/browse/CASSANDRA-17017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17017: -- Status: Patch Available (was: Review In Progress) > Add required -f / --force option to nodetool verify > --- > > Key: CASSANDRA-17017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17017 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > nodetool verify has some pretty significant problems with it (see > CASSANDRA-9947). > Until such time as we do the heavy(er) lift to fix the command, we should > make it harder for people to shoot themselves in the foot with it. Adding a > required "-f" flag to it with a requisite "Do you really know what you're > doing? Check out this JIRA first" seems like it'd be the right thing to do in > the interim. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17017) Add required -f / --force option to nodetool verify
[ https://issues.apache.org/jira/browse/CASSANDRA-17017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17017: -- Status: In Progress (was: Patch Available) > Add required -f / --force option to nodetool verify > --- > > Key: CASSANDRA-17017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17017 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > nodetool verify has some pretty significant problems with it (see > CASSANDRA-9947). > Until such time as we do the heavy(er) lift to fix the command, we should > make it harder for people to shoot themselves in the foot with it. Adding a > required "-f" flag to it with a requisite "Do you really know what you're > doing? Check out this JIRA first" seems like it'd be the right thing to do in > the interim. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17032) Allow configuring max allowable disk usage quota by keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17032: -- Status: Open (was: Patch Available) > Allow configuring max allowable disk usage quota by keyspace > > > Key: CASSANDRA-17032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17032 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > This is a similar idea (basically identical idea; didn't want to steamroll > that old ticket w/an update to description etc) to what was raised and closed > in CASSANDRA-5394. In multi-tenant situations it can be very helpful to > provide disk quotas per Keyspaces for users. > We can do this via a low priority background job that periodically checks > disk usage and flips a bit on the Keyspaces when it's over as well as reverts > it when things settle back down to prevent needing the read-before-write a > hard realtime requirement would introduce. While this would of course allow > users to "burst" their usage past that limit in the time window, it would > still be sufficient for many use-cases. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17037) Log time spent writing keys during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-17037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17037: Reviewers: Marcus Eriksson Status: Review In Progress (was: Patch Available) > Log time spent writing keys during compaction > - > > Key: CASSANDRA-17037 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17037 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While we log a lot of info during compaction, we don't log the time spent > doing so. No reason not to include this for operator visibility and log > analysis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17032) Allow configuring max allowable disk usage quota by keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428242#comment-17428242
]
Josh McKenzie commented on CASSANDRA-17032:
---
{quote}I wonder if we should not make quotas a keyspace schema option, so quota
updates are automatically broadcasted to all nodes?
{quote}
We get the "broadcast to all nodes" plus side with the "now exposed to all the
problems of our non-transactional and inconsistent metadata" problems.
In the tradeoff between "you can deterministically change this during
firefighting" and "you can configure this more easily up front", I lean towards
the former even with all the warts, operating under the assumption most
operators have some tooling to do cluster-wide JMX and nodetool operations at
this point.
Ideally we wouldn't have that tradeoff but we're not there yet.
> Allow configuring max allowable disk usage quota by keyspace
>
>
> Key: CASSANDRA-17032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17032
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> This is a similar idea (basically identical idea; didn't want to steamroll
> that old ticket w/an update to description etc) to what was raised and closed
> in CASSANDRA-5394. In multi-tenant situations it can be very helpful to
> provide disk quotas per Keyspaces for users.
> We can do this via a low priority background job that periodically checks
> disk usage and flips a bit on the Keyspaces when it's over as well as reverts
> it when things settle back down to prevent needing the read-before-write a
> hard realtime requirement would introduce. While this would of course allow
> users to "burst" their usage past that limit in the time window, it would
> still be sufficient for many use-cases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17037) Log time spent writing keys during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-17037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17037: -- Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) [Branch|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:cassandra-17037?expand=1] > Log time spent writing keys during compaction > - > > Key: CASSANDRA-17037 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17037 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While we log a lot of info during compaction, we don't log the time spent > doing so. No reason not to include this for operator visibility and log > analysis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17037) Log time spent writing keys during compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-17037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17037: -- Test and Documentation Plan: No testing nor doc changes needed. Status: Patch Available (was: Open) > Log time spent writing keys during compaction > - > > Key: CASSANDRA-17037 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17037 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > While we log a lot of info during compaction, we don't log the time spent > doing so. No reason not to include this for operator visibility and log > analysis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16976:
-
Reviewers: Brandon Williams, Stefan Miklosovic (was: Stefan Miklosovic)
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428236#comment-17428236
]
Brandon Williams commented on CASSANDRA-16976:
--
bq. I just start/finish compaction manually on some hardcoded data. Taking into
account this functionality is trivial (and not mission critical) and we need to
test output format only, I feel this is more than enough.
I agree. +1 to the patch.
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428234#comment-17428234
]
Stefan Miklosovic commented on CASSANDRA-16956:
---
hi [~Bowen Song], could you please go over Python bits where I removed Windows
support? It would be hightly appreciated. Touches the discussion we had about
Windows support on CASSANDRA-16983.
https://github.com/apache/cassandra/pull/1249
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17037) Log time spent writing keys during compaction
Josh McKenzie created CASSANDRA-17037: - Summary: Log time spent writing keys during compaction Key: CASSANDRA-17037 URL: https://issues.apache.org/jira/browse/CASSANDRA-17037 Project: Cassandra Issue Type: Improvement Components: Local/Compaction Reporter: Josh McKenzie Assignee: Josh McKenzie While we log a lot of info during compaction, we don't log the time spent doing so. No reason not to include this for operator visibility and log analysis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17036) Add logging and metrics to Index Summary Redistribution
[ https://issues.apache.org/jira/browse/CASSANDRA-17036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17036: -- Fix Version/s: 4.1 Source Control Link: https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=2ce9b13e8ff1d5d54d87e403a25561a82c9490a0 Resolution: Fixed Status: Resolved (was: Ready to Commit) Ninja'd in the change from System.nanoTime to Clock.nanoTime post CEP-10 on commit. > Add logging and metrics to Index Summary Redistribution > --- > > Key: CASSANDRA-17036 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17036 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.1 > > > We don't have much visibility into the performance / impact / time taken on > index summary redistribution, either in memory impact or time to execute. We > should add some metrics and slightly tweak the logging around that to make it > more useful. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add logging and metrics for index summary redistribution
This is an automated email from the ASF dual-hosted git repository.
jmckenzie pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 2ce9b13 Add logging and metrics for index summary redistribution
2ce9b13 is described below
commit 2ce9b13e8ff1d5d54d87e403a25561a82c9490a0
Author: Marcus Eriksson
AuthorDate: Tue Oct 12 12:28:35 2021 -0400
Add logging and metrics for index summary redistribution
Patch by Marcus Eriksson, reviewed by David Capwell for CASSANDRA-17036
Co-authored-by: Marcus Eriksson
Co-authored-by: Josh McKenzie
---
CHANGES.txt | 1 +
.../org/apache/cassandra/io/sstable/IndexSummaryManager.java | 4 +++-
.../cassandra/io/sstable/IndexSummaryRedistribution.java | 12
.../apache/cassandra/io/sstable/format/SSTableReader.java| 2 +-
src/java/org/apache/cassandra/metrics/CompactionMetrics.java | 5 -
5 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 384576b..0c3dd81 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Add metrics and logging around index summary redistribution
(CASSANDRA-17036)
* Add configuration options for minimum allowable replication factor and
default replication factor (CASSANDRA-14557)
* Expose information about stored hints via a nodetool command and a virtual
table (CASSANDRA-14795)
* Add broadcast_rpc_address to system.local (CASSANDRA-11181)
diff --git a/src/java/org/apache/cassandra/io/sstable/IndexSummaryManager.java
b/src/java/org/apache/cassandra/io/sstable/IndexSummaryManager.java
index aac0be4..ee6f349 100644
--- a/src/java/org/apache/cassandra/io/sstable/IndexSummaryManager.java
+++ b/src/java/org/apache/cassandra/io/sstable/IndexSummaryManager.java
@@ -30,6 +30,8 @@ import java.util.concurrent.TimeoutException;
import com.google.common.annotations.VisibleForTesting;
import com.google.common.collect.ImmutableSet;
import com.google.common.collect.Sets;
+
+import com.codahale.metrics.Timer;
import org.apache.cassandra.concurrent.ScheduledExecutorPlus;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -231,7 +233,7 @@ public class IndexSummaryManager implements
IndexSummaryManagerMBean
Pair>
redistributionTransactionInfo = getRestributionTransactions();
Map transactions =
redistributionTransactionInfo.right;
long nonRedistributingOffHeapSize = redistributionTransactionInfo.left;
-try
+try (Timer.Context ctx =
CompactionManager.instance.getMetrics().indexSummaryRedistributionTime.time())
{
redistributeSummaries(new IndexSummaryRedistribution(transactions,
nonRedistributingOffHeapSize,
diff --git
a/src/java/org/apache/cassandra/io/sstable/IndexSummaryRedistribution.java
b/src/java/org/apache/cassandra/io/sstable/IndexSummaryRedistribution.java
index 90a8621..bac3280 100644
--- a/src/java/org/apache/cassandra/io/sstable/IndexSummaryRedistribution.java
+++ b/src/java/org/apache/cassandra/io/sstable/IndexSummaryRedistribution.java
@@ -26,6 +26,7 @@ import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.UUID;
+import java.util.concurrent.TimeUnit;
import com.google.common.annotations.VisibleForTesting;
@@ -46,6 +47,7 @@ import org.apache.cassandra.utils.Pair;
import org.apache.cassandra.utils.concurrent.Refs;
import static org.apache.cassandra.io.sstable.Downsampling.BASE_SAMPLING_LEVEL;
+import static org.apache.cassandra.utils.Clock.Global.nanoTime;
public class IndexSummaryRedistribution extends CompactionInfo.Holder
{
@@ -80,6 +82,7 @@ public class IndexSummaryRedistribution extends
CompactionInfo.Holder
public List redistributeSummaries() throws IOException
{
+long start = nanoTime();
logger.info("Redistributing index summaries");
List redistribute = new ArrayList<>();
for (LifecycleTransaction txn : transactions.values())
@@ -91,7 +94,7 @@ public class IndexSummaryRedistribution extends
CompactionInfo.Holder
for (SSTableReader sstable : redistribute)
total += sstable.getIndexSummaryOffHeapSize();
-logger.trace("Beginning redistribution of index summaries for {}
sstables with memory pool size {} MB; current spaced used is {} MB",
+logger.info("Beginning redistribution of index summaries for {}
sstables with memory pool size {} MB; current spaced used is {} MB",
redistribute.size(), memoryPoolBytes / 1024L / 1024L,
total / 1024.0 / 1024.0);
final Map readRates = new
HashMap<>(redistribute.size());
@@ -129,9 +132,9 @@ public class IndexSummaryRedistribution extends
CompactionInfo.Holder
total = nonRedistributingOffHeapSize;
for
[jira] [Commented] (CASSANDRA-16902) A user should be able to view permissions of role they created
[
https://issues.apache.org/jira/browse/CASSANDRA-16902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428201#comment-17428201
]
Benjamin Lerer commented on CASSANDRA-16902:
[~azotcsit] Sorry, I am the one blocking that issue. I had a discussion with
[~adelapena] about simplifying the unit tests but those simplification would
require the changes that are part of CASSANDRA-17027.
> A user should be able to view permissions of role they created
> --
>
> Key: CASSANDRA-16902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16902
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently users are denied to view permissions to see a role they created:
> {code}
> CREATE ROLE parent WITH PASSWORD = 'x' AND LOGIN = true;
> GRANT CREATE ON ALL ROLES TO parent;
> LOGIN parent;
> CREATE ROLE child WITH PASSWORD = 'x' AND LOGIN = true;
> LIST ALL PERMISSIONS OF 'child'; -- You are not authorized to view child's
> permissions
> {code}
> When a user creates a role they should get the {{DESCRIBE}} permission on
> that role by default.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14013:
--
Component/s: Local/Snapshots
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16334) Replica failure causes timeout on multi-DC write
[
https://issues.apache.org/jira/browse/CASSANDRA-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428161#comment-17428161
]
Andres de la Peña commented on CASSANDRA-16334:
---
Ok, the repeated dtest runs are failing because the MID resources config for
Circle is using medium runners, while it should use large runners. Indeed, the
test passes as part of the regular dtest jobs because those jobs correctly use
large runners. I'll open a ticket for fixing this. In the meantime, I have
manually set the right resource class and the repeated runs pass, as it was
expected:
||branch||CI||
|3.0|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1006/workflows/4c3774df-f49a-4e0b-b1a4-9e5bfee06087]|
|3.11|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1005/workflows/cd497fac-1348-4736-8b0d-fccb4dbaacbe]|
|4.0|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1007/workflows/c54bf75a-8005-4843-a432-40487f77b435]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1007/workflows/8814397a-d3fe-41ab-bdb5-fa10ca021494]|
|trunk|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1004/workflows/0fc6f761-4eb1-4f88-a281-cccf0c79cb48]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1004/workflows/97e60123-d1af-46d6-9973-654f14f7eb21]|
> Replica failure causes timeout on multi-DC write
>
>
> Key: CASSANDRA-16334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16334
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Messaging/Internode
>Reporter: Paulo Motta
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws
> a write error on a single DC keyspace with RF=3:
> {noformat}
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 0 responses and 3
> failures: UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN
> from /127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 3}
> {noformat}
> The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
> {noformat}
> cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
> out waiting for replica nodes' responses] message="Operation timed out -
> received only 0 responses." info={'consistency': 'LOCAL_ONE',
> 'required_responses': 1, 'received_responses': 0}
> {noformat}
> Reproduction steps:
> {noformat}
> # Setup cluster
> ccm create -n 3:3 test
> for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
> ~/.ccm/test/node$i/conf/cassandra.yaml; done
> ccm start
> # Create schema
> ccm node1 cqlsh
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': 3, 'dc2': 3};
> CREATE TABLE test.test (key int PRIMARY KEY, val blob);
> exit;
> # Insert data
> python
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect('test')
> blob = f = open("2mbBlob", "rb").read().hex()
> session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob
> + "'))")
> {noformat}
> Reproduced in 3.0, 3.11, 4.0, trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16976:
--
Status: Needs Committer (was: Review In Progress)
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428138#comment-17428138
]
Stefan Miklosovic commented on CASSANDRA-16976:
---
Thanks [~azotcsit], I reviewed, nice idea with tests. I left couple nits in PR
but otherwise it looks fine.
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16976:
--
Reviewers: Stefan Miklosovic
Status: Review In Progress (was: Patch Available)
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16976:
--
Status: In Progress (was: Patch Available)
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16976:
--
Status: Patch Available (was: In Progress)
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-16976:
--
Test and Documentation Plan: I wrote unit tests to cover both existing and
new logic. Also I updated documentation.
Status: Patch Available (was: Open)
[~brandon.williams] [~stefan.miklosovic]
I created tests to validate outputs of the nodetool command and the VT. Could
you please check the PR. In the meantime, I've triggered
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1206/].
PS:
After checking the suggested dtest, I came to conclusion that it would be an
overhead to generate a bunch of data to ensure that we catch compaction in
progress. So I just start/finish compaction manually on some hardcoded data.
Taking into account this functionality is trivial (and not mission critical)
and we need to test output format only, I feel this is more than enough.
Please, let me know if you have any concerns.
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428130#comment-17428130
]
Yuqi Gu edited comment on CASSANDRA-17019 at 10/13/21, 10:12 AM:
-
The snappy-java-1.1.2.6.jar could be found in:
{code:java}
cassandra/build/lib/jars{code}
I add this path to CLASS_PATH and add flag: {{}}
{{-Dorg.xerial.snappy.lib.name=libsnappyjava.jnilib
-Dorg.xerial.snappy.tempdir=/tmp}}
But also failed in test case for "SnappyCompressor.create() threw an error:
java.lang.NoClassDefFoundError".
was (Author: yqgu):
The snappy-java-1.1.2.6.jar could be found in:
{code:java}
cassandra/build/lib/jars{code}
I add this path to CLASS_PATH, but also failed in test case for
"SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError".
> JNA 5.6.0 does not support arm64
>
>
> Key: CASSANDRA-17019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17019
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Igamr Palsenberg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1
>
> Attachments: cassandra_UTs.txt
>
>
> Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native
> binding into the C library.
> JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing
> cassandra to fail on bootstrap.
> Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the
> dependency be acceptable ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428130#comment-17428130
]
Yuqi Gu edited comment on CASSANDRA-17019 at 10/13/21, 10:12 AM:
-
The snappy-java-1.1.2.6.jar could be found in:
{code:java}
cassandra/build/lib/jars{code}
I add this path to CLASS_PATH and add flag:
{{-Dorg.xerial.snappy.lib.name=libsnappyjava.jnilib
-Dorg.xerial.snappy.tempdir=/tmp}}
But also failed in test case for "SnappyCompressor.create() threw an error:
java.lang.NoClassDefFoundError".
was (Author: yqgu):
The snappy-java-1.1.2.6.jar could be found in:
{code:java}
cassandra/build/lib/jars{code}
I add this path to CLASS_PATH and add flag: {{}}
{{-Dorg.xerial.snappy.lib.name=libsnappyjava.jnilib
-Dorg.xerial.snappy.tempdir=/tmp}}
But also failed in test case for "SnappyCompressor.create() threw an error:
java.lang.NoClassDefFoundError".
> JNA 5.6.0 does not support arm64
>
>
> Key: CASSANDRA-17019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17019
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Igamr Palsenberg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1
>
> Attachments: cassandra_UTs.txt
>
>
> Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native
> binding into the C library.
> JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing
> cassandra to fail on bootstrap.
> Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the
> dependency be acceptable ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428130#comment-17428130
]
Yuqi Gu commented on CASSANDRA-17019:
-
The snappy-java-1.1.2.6.jar could be found in:
{code:java}
cassandra/build/lib/jars{code}
I add this path to CLASS_PATH, but also failed in test case for
"SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError".
> JNA 5.6.0 does not support arm64
>
>
> Key: CASSANDRA-17019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17019
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Igamr Palsenberg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1
>
> Attachments: cassandra_UTs.txt
>
>
> Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native
> binding into the C library.
> JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing
> cassandra to fail on bootstrap.
> Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the
> dependency be acceptable ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14557:
--
Source Control Link:
https://github.com/apache/cassandra/commit/5fdadb25f95099b8945d9d9ee11d3e380d3867f4
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14557:
--
Status: Ready to Commit (was: Changes Suggested)
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: add default_keyspace_rf and minimum_keyspace_rf configuration options
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 5fdadb2 add default_keyspace_rf and minimum_keyspace_rf configuration options 5fdadb2 is described below commit 5fdadb25f95099b8945d9d9ee11d3e380d3867f4 Author: Sumanth Pasupuleti AuthorDate: Mon May 11 16:18:51 2020 +0200 add default_keyspace_rf and minimum_keyspace_rf configuration options Patch by Sumanth Pasupuleti; reviewed by Jaydeepkumar Chovatia, Alex Petrov, Stefan Miklosovic and Alexander Zotov for CASSANDRA-14557. --- CHANGES.txt| 1 + conf/cassandra.yaml| 19 doc/source/cql/ddl.rst | 17 ++- .../org/apache/cassandra/auth/AuthKeyspace.java| 3 +- .../config/CassandraRelevantProperties.java| 2 + src/java/org/apache/cassandra/config/Config.java | 5 + .../cassandra/config/DatabaseDescriptor.java | 40 +++ .../locator/AbstractReplicationStrategy.java | 6 + .../cassandra/locator/NetworkTopologyStrategy.java | 12 +- .../apache/cassandra/locator/SimpleStrategy.java | 10 ++ .../repair/SystemDistributedKeyspace.java | 4 +- .../apache/cassandra/schema/ReplicationParams.java | 4 +- .../apache/cassandra/service/StorageService.java | 22 .../cassandra/service/StorageServiceMBean.java | 5 + src/java/org/apache/cassandra/tools/NodeProbe.java | 20 src/java/org/apache/cassandra/tools/NodeTool.java | 4 + .../tools/nodetool/GetDefaultKeyspaceRF.java | 32 ++ .../tools/nodetool/GetMinimumKeyspaceRF.java | 33 ++ .../tools/nodetool/SetDefaultKeyspaceRF.java | 36 ++ .../tools/nodetool/SetMinimumKeyspaceRF.java | 36 ++ .../apache/cassandra/tracing/TraceKeyspace.java| 6 +- .../cassandra/config/DatabaseDescriptorTest.java | 29 - .../cql3/validation/operations/AlterTest.java | 125 ++--- .../cql3/validation/operations/CreateTest.java | 45 +++- .../tools/nodetool/GetDefaultKeyspaceRFTest.java | 87 ++ .../tools/nodetool/GetMinimumKeyspaceRFTest.java | 87 ++ .../tools/nodetool/SetDefaultKeyspaceRFTest.java | 94 .../tools/nodetool/SetMinimumKeyspaceRFTest.java | 94 28 files changed, 847 insertions(+), 31 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index d910c80..384576b 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.1 + * Add configuration options for minimum allowable replication factor and default replication factor (CASSANDRA-14557) * Expose information about stored hints via a nodetool command and a virtual table (CASSANDRA-14795) * Add broadcast_rpc_address to system.local (CASSANDRA-11181) * Add support for type casting in WHERE clause components and in the values of INSERT/UPDATE statements (CASSANDRA-14337) diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index fb0263d..a9efa8d 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -1329,6 +1329,25 @@ compaction_tombstone_warning_threshold: 10 # as corrupted. This should be positive and less than 2048. # max_value_size_in_mb: 256 +# ** Impact on keyspace creation ** +# If replication factor is not mentioned as part of keyspace creation, default_keyspace_rf would apply. +# Changing this configuration would only take effect for keyspaces created after the change, but does not impact +# existing keyspaces created prior to the change. +# ** Impact on keyspace alter ** +# When altering a keyspace from NetworkTopologyStrategy to SimpleStrategy, default_keyspace_rf is applied if rf is not +# explicitly mentioned. +# ** Impact on system keyspaces ** +# This would also apply for any system keyspaces that need replication factor. +# A further note about system keyspaces - system_traces and system_distributed keyspaces take RF of 2 or default, +# whichever is higher, and system_auth keyspace takes RF of 1 or default, whichever is higher. +# Suggested value for use in production: 3 +# default_keyspace_rf: 1 + +# The minimum allowable replication factor. Creating a keyspace with a replication factor less than this value will be rejected. +# This would also apply to system keyspaces. +# Suggested value for use in production: 2 or higher +# minimum_keyspace_rf: 0 + # Coalescing Strategies # # Coalescing multiples messages turns out to significantly boost message processing throughput (think doubling or more). # On bare metal, the floor for packet processing throughput is high enough that many applications won't notice, but in diff --git a/doc/source/cql/ddl.rst b/doc/source/cql/ddl.rst index 2f442e9..7b69e91 100644 --- a/doc/source/cql/ddl.rst +++ b/doc/source/cql/ddl.rst @@ -83,13 +83,17
[jira] [Commented] (CASSANDRA-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428078#comment-17428078
]
Sumanth Pasupuleti commented on CASSANDRA-14557:
[~stefan.miklosovic] Made a follow up commit to fix the failing UTs.
Specifically this change
https://github.com/sumanth-pasupuleti/cassandra/commit/f10e681b60436b2c587747f4e48f0635d348280c#diff-8e56094eaea78601c862aca6d18a2b2e583ceecd933f01ebb85ea7019dfb54daR754-R755
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428050#comment-17428050 ] Stefan Miklosovic commented on CASSANDRA-17019: --- Interesting, that has to be some kind of a glitch I guess ... can you doblecheck you have that lib on the classpath? It fails on "ClassNotFoundException" > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Attachments: cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14557:
--
Status: Changes Suggested (was: Ready to Commit)
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428048#comment-17428048
]
Stefan Miklosovic commented on CASSANDRA-14557:
---
The build is failing (unit tests so far) and the cause is the change in this
ticket, some configuration matter [~sumanth.pasupuleti] could you fix it
please?
https://app.circleci.com/pipelines/github/instaclustr/cassandra/568/workflows/9c1b0294-f0ba-4b86-ab2c-8b05c8869d91/jobs/2884/tests#failed-test-0
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17009) Sstableverify unit test operate on SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-17009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428037#comment-17428037 ] Berenguer Blasi commented on CASSANDRA-17009: - Dropped a couple nits. Did you rebase? The PR doesn't mention it. It is failing to run tests locally on some rat report failure. > Sstableverify unit test operate on SSTables > --- > > Key: CASSANDRA-17009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17009 > Project: Cassandra > Issue Type: Sub-task > Components: Tool/sstable >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Time Spent: 3h 10m > Remaining Estimate: 0h > > as part of https://issues.apache.org/jira/browse/CASSANDRA-16009, unit > coverage is a bit lax and doesn't run through the verifier (based on my > coverage results). > There should be a unit test that exercises the internal verifier both for a > corrupt example and a working example. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
