[jira] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Complexity: Normal Change Category: Performance Status: Open (was: Triage Needed) > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > > Tracks evaluating a 192 node cluster with compression and encryption on. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14746) Ensure Netty Internode Messaging Refactor is Solid
[ https://issues.apache.org/jira/browse/CASSANDRA-14746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch reassigned CASSANDRA-14746: Assignee: Joseph Lynch > Ensure Netty Internode Messaging Refactor is Solid > -- > > Key: CASSANDRA-14746 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14746 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Streaming and Messaging >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Labels: 4.0-QA > Fix For: 4.0 > > > Before we release 4.0 let's ensure that the internode messaging refactor is > 100% solid. As internode messaging is naturally used in many code paths and > widely configurable we have a large number of cluster configurations and test > configurations that must be vetted. > We plan to vary the following: > * Version of Cassandra 3.0.17 vs 4.0-alpha > * Cluster sizes with *multi-dc* deployments ranging from 6 - 100 nodes > * Client request rates varying between 1k QPS and 100k QPS of varying sizes > and shapes (BATCH, INSERT, SELECT point, SELECT range, etc ...) > * Internode compression > * Internode SSL (as well as openssl vs jdk) > * Internode Coalescing options > We are looking to measure the following as appropriate: > * Latency distributions of reads and writes (lower is better) > * Scaling limit, aka maximum throughput before violating p99 latency > deadline of 10ms @ LOCAL_QUORUM, on a fixed hardware deployment for 100% > writes, 100% reads and 50-50 writes+reads (higher is better) > * Thread counts (lower is better) > * Context switches (lower is better) > * On-CPU time of tasks (higher periods without context switch is better) > * GC allocation rates / throughput for a fixed size heap (lower allocation > better) > * Streaming recovery time for a single node failure, i.e. can Cassandra > saturate the NIC > > The goal is that 4.0 should have better latency, more throughput, fewer > threads, fewer context switches, less GC allocation, and faster recovery > time. I'm putting Jason Brown as the reviewer since he implemented most of > the internode refactor. > Current collaborators driving this QA task: Dinesh Joshi, Jordan West, Joey > Lynch (Netflix), Vinay Chella (Netflix) > Owning committer(s): Jason Brown -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
Joseph Lynch created CASSANDRA-15175: Summary: Evaluate 200 node, compression=on, encryption=all Key: CASSANDRA-15175 URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 Project: Cassandra Issue Type: Sub-task Components: Test/benchmark Reporter: Joseph Lynch Assignee: Joseph Lynch Tracks evaluating a 192 node cluster with compression and encryption on. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15174) some utils do not run on windows with default bat scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CASSANDRA-15174:
---
Labels: pull-request-available (was: )
> some utils do not run on windows with default bat scripts
> -
>
> Key: CASSANDRA-15174
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15174
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/sstable
>Reporter: Nathan Jackels
>Priority: Normal
> Labels: pull-request-available
>
> The following scripts in tools/bin do not pass %CASSANDRA_PARAMS% to the jvm
> which prevent successful execution because cassandra.storagedir is not set.
> * sstablemetadata.bat
> * sstableexpiredblockers.bat
> {noformat}
> > sstablemetadata.bat
> > D:\data\system\local-7ad54392bcdd35a684174e047860b377\mc-1288-big-Data.db
> ...
> INFO 03:05:35 Loaded cassandra-topology.properties for compatibility
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: hints_directory is missing and
> -Dcassandra.storagedir is not set
> hints_directory is missing and -Dcassandra.storagedir is not set
> {noformat}
> observed with 3.0.10
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15174) some utils do not run on windows with default bat scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Jackels updated CASSANDRA-15174:
---
Description:
The following scripts in tools/bin do not pass %CASSANDRA_PARAMS% to the jvm
which prevent successful execution because cassandra.storagedir is not set.
* sstablemetadata.bat
* sstableexpiredblockers.bat
{noformat}
> sstablemetadata.bat
> D:\data\system\local-7ad54392bcdd35a684174e047860b377\mc-1288-big-Data.db
...
INFO 03:05:35 Loaded cassandra-topology.properties for compatibility
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered
during startup: hints_directory is missing and -Dcassandra.storagedir is not set
hints_directory is missing and -Dcassandra.storagedir is not set
{noformat}
observed with 3.0.10
was:
The following scripts in tools/bin do not pass %CASSANDRA_PARAMS% to the jvm
which prevent successful execution because cassandra.storagedir is not set.
* sstablemetadata.bat
* sstableexpiredblockers.bat
{noformat}
> sstablemetadata.bat
> D:\data\system\local-7ad54392bcdd35a684174e047860b377\mc-1288-big-Data.db
...
INFO 03:05:35 Loaded cassandra-topology.properties for compatibility
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered
during startup: hints_directory is missing and -Dcassandra.storagedir is not set
hints_directory is missing and -Dcassandra.storagedir is not set
{noformat}
> some utils do not run on windows with default bat scripts
> -
>
> Key: CASSANDRA-15174
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15174
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/sstable
>Reporter: Nathan Jackels
>Priority: Normal
>
> The following scripts in tools/bin do not pass %CASSANDRA_PARAMS% to the jvm
> which prevent successful execution because cassandra.storagedir is not set.
> * sstablemetadata.bat
> * sstableexpiredblockers.bat
> {noformat}
> > sstablemetadata.bat
> > D:\data\system\local-7ad54392bcdd35a684174e047860b377\mc-1288-big-Data.db
> ...
> INFO 03:05:35 Loaded cassandra-topology.properties for compatibility
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: hints_directory is missing and
> -Dcassandra.storagedir is not set
> hints_directory is missing and -Dcassandra.storagedir is not set
> {noformat}
> observed with 3.0.10
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15174) some utils do not run on windows with default bat scripts
[
https://issues.apache.org/jira/browse/CASSANDRA-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Jackels updated CASSANDRA-15174:
---
Description:
The following scripts in tools/bin do not pass %CASSANDRA_PARAMS% to the jvm
which prevent successful execution because cassandra.storagedir is not set.
* sstablemetadata.bat
* sstableexpiredblockers.bat
{noformat}
> sstablemetadata.bat
> D:\data\system\local-7ad54392bcdd35a684174e047860b377\mc-1288-big-Data.db
...
INFO 03:05:35 Loaded cassandra-topology.properties for compatibility
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered
during startup: hints_directory is missing and -Dcassandra.storagedir is not set
hints_directory is missing and -Dcassandra.storagedir is not set
{noformat}
was:
The following scripts in tools/bin do not pass %CASSANDRA_PARAMS% to the jvm
which prevent successful execution because cassandra.storagedir is not set.
* sstablemetadata.bat
* sstableexpiredblockers.bat
> some utils do not run on windows with default bat scripts
> -
>
> Key: CASSANDRA-15174
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15174
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/sstable
>Reporter: Nathan Jackels
>Priority: Normal
>
> The following scripts in tools/bin do not pass %CASSANDRA_PARAMS% to the jvm
> which prevent successful execution because cassandra.storagedir is not set.
> * sstablemetadata.bat
> * sstableexpiredblockers.bat
> {noformat}
> > sstablemetadata.bat
> > D:\data\system\local-7ad54392bcdd35a684174e047860b377\mc-1288-big-Data.db
> ...
> INFO 03:05:35 Loaded cassandra-topology.properties for compatibility
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: hints_directory is missing and
> -Dcassandra.storagedir is not set
> hints_directory is missing and -Dcassandra.storagedir is not set
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15174) some utils do not run on windows with default bat scripts
Nathan Jackels created CASSANDRA-15174: -- Summary: some utils do not run on windows with default bat scripts Key: CASSANDRA-15174 URL: https://issues.apache.org/jira/browse/CASSANDRA-15174 Project: Cassandra Issue Type: Improvement Components: Tool/sstable Reporter: Nathan Jackels The following scripts in tools/bin do not pass %CASSANDRA_PARAMS% to the jvm which prevent successful execution because cassandra.storagedir is not set. * sstablemetadata.bat * sstableexpiredblockers.bat -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14757) GCInspector "Error accessing field of java.nio.Bits" under java11
[
https://issues.apache.org/jira/browse/CASSANDRA-14757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-14757:
Authors: mck (was: Robert Stupp)
Reviewers: Robert Stupp
> GCInspector "Error accessing field of java.nio.Bits" under java11
> -
>
> Key: CASSANDRA-14757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14757
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Jason Brown
>Assignee: Robert Stupp
>Priority: Low
> Labels: Java11, pull-request-available
> Fix For: 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running under java11, {{GCInspector}} throws the following exception:
> {noformat}
> DEBUG [main] 2018-09-18 05:18:25,905 GCInspector.java:78 - Error accessing
> field of java.nio.Bits
> java.lang.NoSuchFieldException: totalCapacity
> at java.base/java.lang.Class.getDeclaredField(Class.java:2412)
> at
> org.apache.cassandra.service.GCInspector.(GCInspector.java:72)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:308)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:590)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679)
> {noformat}
> This is because {{GCInspector}} uses reflection to read the {{totalCapacity}}
> from {{java.nio.Bits}}. This field was renamed to {{TOTAL_CAPACITY}}
> somewhere between java8 and java11.
> Note: this is a rather harmless error, as we only look at
> {{Bits.totalCapacity}} for metrics collection on how much direct memory is
> being used by {{ByteBuffer}}s. If we fail to read the field, we simply return
> -1 for the metric value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14757) GCInspector "Error accessing field of java.nio.Bits" under java11
[
https://issues.apache.org/jira/browse/CASSANDRA-14757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868210#comment-16868210
]
mck commented on CASSANDRA-14757:
-
done. am i free to merge [~snazy]?
> GCInspector "Error accessing field of java.nio.Bits" under java11
> -
>
> Key: CASSANDRA-14757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14757
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Jason Brown
>Assignee: Robert Stupp
>Priority: Low
> Labels: Java11, pull-request-available
> Fix For: 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running under java11, {{GCInspector}} throws the following exception:
> {noformat}
> DEBUG [main] 2018-09-18 05:18:25,905 GCInspector.java:78 - Error accessing
> field of java.nio.Bits
> java.lang.NoSuchFieldException: totalCapacity
> at java.base/java.lang.Class.getDeclaredField(Class.java:2412)
> at
> org.apache.cassandra.service.GCInspector.(GCInspector.java:72)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:308)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:590)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679)
> {noformat}
> This is because {{GCInspector}} uses reflection to read the {{totalCapacity}}
> from {{java.nio.Bits}}. This field was renamed to {{TOTAL_CAPACITY}}
> somewhere between java8 and java11.
> Note: this is a rather harmless error, as we only look at
> {{Bits.totalCapacity}} for metrics collection on how much direct memory is
> being used by {{ByteBuffer}}s. If we fail to read the field, we simply return
> -1 for the metric value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15173) fix log for inconsistent-left-subrange in merkle-tree
[
https://issues.apache.org/jira/browse/CASSANDRA-15173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868203#comment-16868203
]
Nathan Jackels commented on CASSANDRA-15173:
Created [pull request #327|https://github.com/apache/cassandra/pull/327]
> fix log for inconsistent-left-subrange in merkle-tree
> -
>
> Key: CASSANDRA-15173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15173
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Nathan Jackels
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> One of the logs added in CASSANDRA-13052 is called with incorrect arguments.
> In org.apache.cassandra.utils.MerkleTree::differenceHelper the right-side
> subrange logs with right:
> {code:java}
> else if (!rreso)
> {
> logger.debug("({}) Right sub-range fully inconsistent {}",
> active.depth, right);
> rdiff = FULLY_INCONSISTENT;
> }
> {code}
> but left side is also (incorrectly) logged with right:
> {code:java}
> else if (!lreso)
> {
> logger.debug("({}) Left sub-range fully inconsistent {}",
> active.depth, right);
> ldiff = FULLY_INCONSISTENT;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15173) fix log for inconsistent-left-subrange in merkle-tree
[
https://issues.apache.org/jira/browse/CASSANDRA-15173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CASSANDRA-15173:
---
Labels: pull-request-available (was: )
> fix log for inconsistent-left-subrange in merkle-tree
> -
>
> Key: CASSANDRA-15173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15173
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Nathan Jackels
>Priority: Normal
> Labels: pull-request-available
>
> One of the logs added in CASSANDRA-13052 is called with incorrect arguments.
> In org.apache.cassandra.utils.MerkleTree::differenceHelper the right-side
> subrange logs with right:
> {code:java}
> else if (!rreso)
> {
> logger.debug("({}) Right sub-range fully inconsistent {}",
> active.depth, right);
> rdiff = FULLY_INCONSISTENT;
> }
> {code}
> but left side is also (incorrectly) logged with right:
> {code:java}
> else if (!lreso)
> {
> logger.debug("({}) Left sub-range fully inconsistent {}",
> active.depth, right);
> ldiff = FULLY_INCONSISTENT;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15173) fix log for inconsistent-left-subrange in merkle-tree
Nathan Jackels created CASSANDRA-15173:
--
Summary: fix log for inconsistent-left-subrange in merkle-tree
Key: CASSANDRA-15173
URL: https://issues.apache.org/jira/browse/CASSANDRA-15173
Project: Cassandra
Issue Type: Improvement
Components: Legacy/Streaming and Messaging
Reporter: Nathan Jackels
One of the logs added in CASSANDRA-13052 is called with incorrect arguments.
In org.apache.cassandra.utils.MerkleTree::differenceHelper the right-side
subrange logs with right:
{code:java}
else if (!rreso)
{
logger.debug("({}) Right sub-range fully inconsistent {}",
active.depth, right);
rdiff = FULLY_INCONSISTENT;
}
{code}
but left side is also (incorrectly) logged with right:
{code:java}
else if (!lreso)
{
logger.debug("({}) Left sub-range fully inconsistent {}", active.depth,
right);
ldiff = FULLY_INCONSISTENT;
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15132) warning should not be logged when client auth is disabled for client encryption
[
https://issues.apache.org/jira/browse/CASSANDRA-15132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867922#comment-16867922
]
John Sanda commented on CASSANDRA-15132:
I went back and looked at this again. I think it would better to reduce the
logging level to DEBUG or altogether remove the log statement instead of the
check that I added in my branch.
[~djoshi3] what do you think?
> warning should not be logged when client auth is disabled for client
> encryption
> ---
>
> Key: CASSANDRA-15132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15132
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: John Sanda
>Priority: Normal
>
> CASSANDRA-14652 caused a regression for client/native transport encryption.
> It broken one-way TLS authentication where only the client authenticates the
> coordinator node's certificate chain. This would be configured in
> cassandra.yaml as such:
> {noformat}
> client_encryption_options:
> enabled: true
> keystore: /path/to/keystore
> keystore_password: my_keystore_password
> optional: false
> require_client_auth: false
> {noformat}
> With the changes in CASSANDRA-14652, ServerConnection.java always assumes
> that there will always be a client certificate chain, which will not be the
> case with the above configuration.
> Here is the error that shows up in the logs:
> {noformat}
> ERROR [Native-Transport-Requests-1] 2019-05-17 18:20:20,016
> ServerConnection.java:147 - Failed to get peer certificates for peer
> /127.0.0.1:50736
> javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> at
> sun.security.ssl.SSLSessionImpl.getPeerCertificateChain(SSLSessionImpl.java:501)
> ~[na:1.8.0_202]
> at
> org.apache.cassandra.transport.ServerConnection.certificates(ServerConnection.java:143)
> [main/:na]
> at
> org.apache.cassandra.transport.ServerConnection.getSaslNegotiator(ServerConnection.java:127)
> [main/:na]
> at
> org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:75)
> [main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:566)
> [main/:na]
> at
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
> [main/:na]
> at
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
> [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:357)
> [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
> [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:348)
> [netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_202]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> [main/:na]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7825) node decommission leaves ghost nodes in system.peers table and JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867854#comment-16867854 ] Yuping Wang commented on CASSANDRA-7825: Thanks Michael. We are also reproducing this consistently. the UpEndpoints shows the total, the DownEndpointFailures show 1... this is already a day after the replacement. What do you need to do to reopen this issue? Or any workaround? > node decommission leaves ghost nodes in system.peers table and JMX > -- > > Key: CASSANDRA-7825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7825 > Project: Cassandra > Issue Type: Bug > Environment: OS: Ubuntu 12.04.4 LTS > Cassandra: ReleaseVersion: 2.0.8.39 > DSE 4.5.1 > OpsCenter: 5.0.0 >Reporter: nayden kolev >Assignee: Brandon Williams >Priority: Low > > I have a 4-node cluster (split in 2 DCs) running DSE 4.5.1, C* 2.0.8.39. I > needed to cycle a node (add a new node and remove one). I followed this doc > (more specifically steps 1 and 2): > http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_remove_node_t.html > After the decom, the decommissioned node logged this: > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:08,243 > ThriftServer.java (line 141) Stop listening to thrift clients > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:08,269 Server.java > (line 182) Stop listening for CQL clients > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:08,270 > Gossiper.java (line 1279) Announcing shutdown > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:10,271 > MessagingService.java (line 683) Waiting for messaging service to quiesce > INFO [ACCEPT-/10.1.129.27] 2014-08-23 09:57:10,272 MessagingService.java > (line 923) MessagingService has terminated the accept() thread > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:10,280 > StorageService.java (line 1007) DECOMMISSIONED > The decommissioned node no longer appears in OpsCenter, and 'nodetool status' > shows it gone from the cluster as well, with the remaining 4 nodes un UN > state. > All is good... Then I noticed that the DownEndpointCount (still) shows as 1 - > using a JMX console, and browsing to org.apache.cassandra.net, > FailureDetector, Attributes, DownEdpointCount. While there, I also noticed > that SimpleStates shows the decommissioned node as down, and the > AllEndpointStates shows it as STATUS:LEFT > I tried running a 'nodetool removenode decom-node's-host-id', but it failed > with "Host ID not found", which I expected, given I decommissioned it and it > does not show in nodetool status. > nodetool describecluster lists only the expected 4 nodes (does not show the > decommissioned node) > checking the system.peers table lists the decomm-ed node with a null host_id, > rack, release_version, rpc_address, schema_version, etc. > Adding JVM_OPTS="$JVM_OPTS -Dcassandra.load_ring_state=false" to the > Cassandra-env.sh as suggested here: > https://issues.apache.org/jira/browse/CASSANDRA-6053 > does not help. I have actually tried this before, when I was decommissioning > a node on an older C* version and it worked, but now it does nothing. If I > delete the row mentioning the decommissioned node from the system.peers table > it stays out of there until the next dse service restart. > This is causing apps to timeout, since they get a invalid node's IP... As a > workaround I remove the entry from the peers table, but it is not permanent... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7825) node decommission leaves ghost nodes in system.peers table and JMX
[ https://issues.apache.org/jira/browse/CASSANDRA-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867573#comment-16867573 ] Michael Shuler commented on CASSANDRA-7825: --- This JIRA was simply closed as "Cannot Reproduce." The other stuff you see in history was JIRA internal changes - there were no real ticket updates since Oct 2014. > node decommission leaves ghost nodes in system.peers table and JMX > -- > > Key: CASSANDRA-7825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7825 > Project: Cassandra > Issue Type: Bug > Environment: OS: Ubuntu 12.04.4 LTS > Cassandra: ReleaseVersion: 2.0.8.39 > DSE 4.5.1 > OpsCenter: 5.0.0 >Reporter: nayden kolev >Assignee: Brandon Williams >Priority: Low > > I have a 4-node cluster (split in 2 DCs) running DSE 4.5.1, C* 2.0.8.39. I > needed to cycle a node (add a new node and remove one). I followed this doc > (more specifically steps 1 and 2): > http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_remove_node_t.html > After the decom, the decommissioned node logged this: > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:08,243 > ThriftServer.java (line 141) Stop listening to thrift clients > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:08,269 Server.java > (line 182) Stop listening for CQL clients > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:08,270 > Gossiper.java (line 1279) Announcing shutdown > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:10,271 > MessagingService.java (line 683) Waiting for messaging service to quiesce > INFO [ACCEPT-/10.1.129.27] 2014-08-23 09:57:10,272 MessagingService.java > (line 923) MessagingService has terminated the accept() thread > INFO [RMI TCP Connection(17)-10.1.129.27] 2014-08-23 09:57:10,280 > StorageService.java (line 1007) DECOMMISSIONED > The decommissioned node no longer appears in OpsCenter, and 'nodetool status' > shows it gone from the cluster as well, with the remaining 4 nodes un UN > state. > All is good... Then I noticed that the DownEndpointCount (still) shows as 1 - > using a JMX console, and browsing to org.apache.cassandra.net, > FailureDetector, Attributes, DownEdpointCount. While there, I also noticed > that SimpleStates shows the decommissioned node as down, and the > AllEndpointStates shows it as STATUS:LEFT > I tried running a 'nodetool removenode decom-node's-host-id', but it failed > with "Host ID not found", which I expected, given I decommissioned it and it > does not show in nodetool status. > nodetool describecluster lists only the expected 4 nodes (does not show the > decommissioned node) > checking the system.peers table lists the decomm-ed node with a null host_id, > rack, release_version, rpc_address, schema_version, etc. > Adding JVM_OPTS="$JVM_OPTS -Dcassandra.load_ring_state=false" to the > Cassandra-env.sh as suggested here: > https://issues.apache.org/jira/browse/CASSANDRA-6053 > does not help. I have actually tried this before, when I was decommissioning > a node on an older C* version and it worked, but now it does nothing. If I > delete the row mentioning the decommissioned node from the system.peers table > it stays out of there until the next dse service restart. > This is causing apps to timeout, since they get a invalid node's IP... As a > workaround I remove the entry from the peers table, but it is not permanent... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15108) Support building Cassandra with JDK 11
[
https://issues.apache.org/jira/browse/CASSANDRA-15108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867497#comment-16867497
]
Robert Stupp commented on CASSANDRA-15108:
--
The change here removed the additional source folder for Java 11 specific
stuff, to be able to add support for example for Direct-I/O (CASSANDRA-14466)
or use the new {{ByteBuffer.mismatch()}}.
C* built w/ Java 11 doesn't work on Java 8 ({{(Byte)Buffer}} in particular).
> Support building Cassandra with JDK 11
> --
>
> Key: CASSANDRA-15108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15108
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 4.0
>
>
> With the changes in java 8 support and licensing, we should be able to build
> and run Cassandra with java 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14757) GCInspector "Error accessing field of java.nio.Bits" under java11
[
https://issues.apache.org/jira/browse/CASSANDRA-14757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867496#comment-16867496
]
Robert Stupp commented on CASSANDRA-14757:
--
[~michaelsembwever] LGTM - let's change roles (assignee/reviewer)
> GCInspector "Error accessing field of java.nio.Bits" under java11
> -
>
> Key: CASSANDRA-14757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14757
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Jason Brown
>Assignee: Robert Stupp
>Priority: Low
> Labels: Java11, pull-request-available
> Fix For: 4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running under java11, {{GCInspector}} throws the following exception:
> {noformat}
> DEBUG [main] 2018-09-18 05:18:25,905 GCInspector.java:78 - Error accessing
> field of java.nio.Bits
> java.lang.NoSuchFieldException: totalCapacity
> at java.base/java.lang.Class.getDeclaredField(Class.java:2412)
> at
> org.apache.cassandra.service.GCInspector.(GCInspector.java:72)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:308)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:590)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679)
> {noformat}
> This is because {{GCInspector}} uses reflection to read the {{totalCapacity}}
> from {{java.nio.Bits}}. This field was renamed to {{TOTAL_CAPACITY}}
> somewhere between java8 and java11.
> Note: this is a rather harmless error, as we only look at
> {{Bits.totalCapacity}} for metrics collection on how much direct memory is
> being used by {{ByteBuffer}}s. If we fail to read the field, we simply return
> -1 for the metric value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11968) More metrics on native protocol requests & responses
[ https://issues.apache.org/jira/browse/CASSANDRA-11968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp reassigned CASSANDRA-11968: Assignee: (was: Robert Stupp) > More metrics on native protocol requests & responses > > > Key: CASSANDRA-11968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11968 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Robert Stupp >Priority: Low > Fix For: 4.x > > > Proposal to add more metrics to the native protocol: > - number of requests per request-type > - number of responses by response-type > - size of request messages in bytes > - size of response messages in bytes > - number of in-flight requests (from request arrival to response) > (Will provide a patch soon) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14606) Add documentation for java 11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-14606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Stupp reassigned CASSANDRA-14606: Assignee: (was: Robert Stupp) > Add documentation for java 11 support > - > > Key: CASSANDRA-14606 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14606 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jason Brown >Priority: Low > Labels: Java11 > Fix For: 4.0 > > > Let's add some documentation for operators around the java 11 support that > was introduced in CASSANDRA-9608. Also, we should point out changes in the > scripts that might affect automation that operators have in place. > Parking on [~snazy] just 'cuz ;) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15172) AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4
Shalom created CASSANDRA-15172:
--
Summary: AbstractLocalAwareExecutorService Exception During
Upgrade to 3.11.4
Key: CASSANDRA-15172
URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
Project: Cassandra
Issue Type: Bug
Reporter: Shalom
Hi All,
This is the first time I open an issue, so apologies if I'm not following the
rules properly.
After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
lot of AbstractLocalAwareExecutorService exceptions. This happened right after
the node successfully started up with the new 3.11.4 binaries.
INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
proceeding
INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
using native Epoll event loop
INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
[netty-buffer=netty-buffer-4.0.44.Final.452812a,
netty-codec=netty-codec-4.0.44.Final.452812a,
netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
netty-common=netty-common-4.0.44.Final.452812a,
netty-handler=netty-handler-4.0.44.Final.452812a,
netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
netty-transport=netty-transport-4.0.44.Final.452812a,
netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
CQL clients on /0.0.0.0:9042 (unencrypted)...
INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool
(enablethrift) to start it
INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145 AuthCache.java:161
- (Re)initializing PermissionsCache (validity period/update interval/max
entries) (2000/2000/1000)
INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409 -
Converting legacy permissions data
INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
WARN [ReadStage-2] 2019-06-05 04:41:39,857
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-2,5,main]: {}
java.lang.ArrayIndexOutOfBoundsException: 1
at
org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
at
org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
at
org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
at
org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
at
org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
at
org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
at
org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
at
org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
at
org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
at
org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
at
org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:114)
at java.lang.Thread.run(Thread.java:745)
After several of the above warnings, the following warning appeared as well:
WARN [ReadStage-9] 2019-06-05 04:42:04,369
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-9,5,main]: {}
java.lang.ArrayIndexOutOfBoundsException: null
[jira] [Commented] (CASSANDRA-13990) Remove OldNetworkTopologyStrategy
[ https://issues.apache.org/jira/browse/CASSANDRA-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16867397#comment-16867397 ] Robert Stupp commented on CASSANDRA-13990: -- Yea - it's definitely time to get rid of this one. The algorithm is weird and it's also super slow. Most importantly, I'm not aware of any user of ONTS. > Remove OldNetworkTopologyStrategy > - > > Key: CASSANDRA-13990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13990 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Jeremy Hanna >Assignee: Pedro Gordo >Priority: Low > Labels: lhf > > RackAwareStrategy was renamed OldNetworkTopologyStrategy back in 0.7 > (CASSANDRA-1392) and it's still around. Is there any reason to keep this > relatively dead code in the codebase at this point? I'm not aware of its use > and it sometimes confuses users. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mazhenlin updated CASSANDRA-15169:
--
Test and Documentation Plan:
I don't know what is supposed to write here, so I just type some words to get
through the step.
It is a tiny modification and I have wrote a UT along with the fix to reproduce
the bug .
Status: Patch Available (was: Open)
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15169) SASIIndex does not compare strings correctly
[
https://issues.apache.org/jira/browse/CASSANDRA-15169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mazhenlin updated CASSANDRA-15169:
--
Severity: Normal
Complexity: Normal
Discovered By: User Report
Bug Category: Parent values: Correctness(12982)Level 1 values: Semantic
Failure(12988)
Status: Open (was: Triage Needed)
> SASIIndex does not compare strings correctly
>
>
> Key: CASSANDRA-15169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15169
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: mazhenlin
>Assignee: mazhenlin
>Priority: Normal
> Attachments: CASSANDRA-15169-v1.patch
>
>
> In our scenario, we need to query with '>' conditions on string columns. So I
> created index with is_literal = false. like the following:
>
> {code:java}
> CREATE TABLE test (id int primary key, t text);
> CREATE CUSTOM INDEX ON test (t) USING
> 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'is_literal':
> 'false'};
> {code}
> I also inserted some records and query:
>
> {code:java}
> insert into test(id,t) values(1,'abc');
> select * from test where t > 'ab';
> {code}
> At first ,it worked. But after flush, the query returned none record.
> I have read the code of SASIIndex and found that it is because in the
> {code:java}
> Expression.isLowerSatisfiedBy{code}
> function,
> {code:java}
> term.compareTo{code}
> was called with parameter checkFully=false, which cause the string 'abc' was
> only compared with its first 2 characters( length of expression value).
>
> I have wrote a UT for this case and fixed it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
