[jira] [Updated] (CASSANDRA-13711) Invalid writetime for null columns in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13711:
---
Status: Patch Available (was: In Progress)
> Invalid writetime for null columns in cqlsh
> ---
>
> Key: CASSANDRA-13711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13711
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> From the user list:
> https://lists.apache.org/thread.html/448731c029eee72e499fc6acd44d257d1671193f850a68521c2c6681@%3Cuser.cassandra.apache.org%3E
> {code}
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm create test -n 1 -s -v 3.0.10
> Current cluster is now: test
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm node1 cqlsh
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.10 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE test.t ( a text primary key, b text );
> cqlsh> insert into test.t(a) values('z');
> cqlsh> insert into test.t(a) values('w');
> cqlsh> insert into test.t(a) values('e');
> cqlsh> insert into test.t(a) values('r');
> cqlsh> insert into test.t(a) values('t');
> cqlsh> select a,b, writetime (b) from test.t;
> a | b | writetime(b)
> ---+--+--
> z | null | null
> e | null | null
> r | null | null
> w | null | null
> t | null | null
> (5 rows)
> cqlsh>
> cqlsh> insert into test.t(a,b) values('t','x');
> cqlsh> insert into test.t(a) values('b');
> cqlsh> select a,b, writetime (b) from test.t;
> a | b| writetime(b)
> ---+--+--
> z | null | null
> e | null | null
> r | null | null
> w | null | null
> t |x | 1500565131354883
> b | null | 1500565131354883
> (6 rows)
> {code}
> Data on disk:
> {code}
> MacBook-Pro:~ jjirsa$ ~/.ccm/repository/3.0.14/tools/bin/sstabledump
> /Users/jjirsa/.ccm/test/node1/data0/test/t-bed196006d0511e7904be9daad294861/mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "z" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 20,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:54.818118Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "e" ],
> "position" : 21
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 44,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:04.288547Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "r" ],
> "position" : 45
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 68,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:08.991417Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "w" ],
> "position" : 69
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 92,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:59.005382Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "t" ],
> "position" : 93
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 120,
> "liveness_info" : { "tstamp" : "2017-07-20T15:38:51.354883Z" },
> "cells" : [
> { "name" : "b", "value" : "x" }
> ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "b" ],
> "position" : 121
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 146,
> "liveness_info" : { "tstamp" : "2017-07-20T15:39:03.631297Z" },
> "cells" : [ ]
> }
> ]
> }
> ]MacBook-Pro:~ jjirsa$
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13648) Upgrade metrics to 3.1.5
[
https://issues.apache.org/jira/browse/CASSANDRA-13648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13648:
---
Resolution: Fixed
Fix Version/s: (was: 4.x)
4.0
Status: Resolved (was: Ready to Commit)
Committed as {{1e7c4b9c0584b5f63d121a5c37e0fc1e352e6108}}
> Upgrade metrics to 3.1.5
>
>
> Key: CASSANDRA-13648
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13648
> Project: Cassandra
> Issue Type: Bug
> Components: Libraries
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 4.0
>
> Attachments: metrics-core-3.1.5.jar.asc, metrics-jvm-3.1.5.jar.asc,
> metrics-logback-3.1.5.jar.asc
>
>
> GH PR #123 indicates that metrics 3.1.5 will fix a reconnect bug:
> https://github.com/apache/cassandra/pull/123
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13732) GH PR #131 - Refactoring to primitive functional interfaces in AuthCache.java
[ https://issues.apache.org/jira/browse/CASSANDRA-13732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13732: --- Status: Patch Available (was: Open) > GH PR #131 - Refactoring to primitive functional interfaces in AuthCache.java > - > > Key: CASSANDRA-13732 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13732 > Project: Cassandra > Issue Type: Bug > Components: Auth >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa > Fix For: 4.x > > > https://github.com/apache/cassandra/pull/131 > Refactor to avoid unnecessary boxing/unboxing in auth cache. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13732) GH PR #131 - Refactoring to primitive functional interfaces in AuthCache.java
[ https://issues.apache.org/jira/browse/CASSANDRA-13732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13732: --- Status: Ready to Commit (was: Patch Available) > GH PR #131 - Refactoring to primitive functional interfaces in AuthCache.java > - > > Key: CASSANDRA-13732 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13732 > Project: Cassandra > Issue Type: Bug > Components: Auth >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa > Fix For: 4.0 > > > https://github.com/apache/cassandra/pull/131 > Refactor to avoid unnecessary boxing/unboxing in auth cache. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13732) GH PR #131 - Refactoring to primitive functional interfaces in AuthCache.java
[
https://issues.apache.org/jira/browse/CASSANDRA-13732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13732:
---
Resolution: Fixed
Fix Version/s: (was: 4.x)
4.0
Status: Resolved (was: Ready to Commit)
lgtm, committed as {{a5dff2f79621d7527a3837c0028d2e8b61d16e42}}
> GH PR #131 - Refactoring to primitive functional interfaces in AuthCache.java
> -
>
> Key: CASSANDRA-13732
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13732
> Project: Cassandra
> Issue Type: Bug
> Components: Auth
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 4.0
>
>
> https://github.com/apache/cassandra/pull/131
> Refactor to avoid unnecessary boxing/unboxing in auth cache.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13711) Invalid writetime for null columns in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104528#comment-16104528
]
Jeff Jirsa commented on CASSANDRA-13711:
[~blerer] you were in this code recently, interested in reviewing? If not,
[~beobal] or [~iamaleksey] ?
> Invalid writetime for null columns in cqlsh
> ---
>
> Key: CASSANDRA-13711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13711
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> From the user list:
> https://lists.apache.org/thread.html/448731c029eee72e499fc6acd44d257d1671193f850a68521c2c6681@%3Cuser.cassandra.apache.org%3E
> {code}
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm create test -n 1 -s -v 3.0.10
> Current cluster is now: test
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm node1 cqlsh
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.10 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE test.t ( a text primary key, b text );
> cqlsh> insert into test.t(a) values('z');
> cqlsh> insert into test.t(a) values('w');
> cqlsh> insert into test.t(a) values('e');
> cqlsh> insert into test.t(a) values('r');
> cqlsh> insert into test.t(a) values('t');
> cqlsh> select a,b, writetime (b) from test.t;
> a | b | writetime(b)
> ---+--+--
> z | null | null
> e | null | null
> r | null | null
> w | null | null
> t | null | null
> (5 rows)
> cqlsh>
> cqlsh> insert into test.t(a,b) values('t','x');
> cqlsh> insert into test.t(a) values('b');
> cqlsh> select a,b, writetime (b) from test.t;
> a | b| writetime(b)
> ---+--+--
> z | null | null
> e | null | null
> r | null | null
> w | null | null
> t |x | 1500565131354883
> b | null | 1500565131354883
> (6 rows)
> {code}
> Data on disk:
> {code}
> MacBook-Pro:~ jjirsa$ ~/.ccm/repository/3.0.14/tools/bin/sstabledump
> /Users/jjirsa/.ccm/test/node1/data0/test/t-bed196006d0511e7904be9daad294861/mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "z" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 20,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:54.818118Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "e" ],
> "position" : 21
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 44,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:04.288547Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "r" ],
> "position" : 45
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 68,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:08.991417Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "w" ],
> "position" : 69
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 92,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:59.005382Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "t" ],
> "position" : 93
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 120,
> "liveness_info" : { "tstamp" : "2017-07-20T15:38:51.354883Z" },
> "cells" : [
> { "name" : "b", "value" : "x" }
> ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "b" ],
> "position" : 121
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 146,
> "liveness_info" : { "tstamp" : "2017-07-20T15:39:03.631297Z" },
> "cells" : [ ]
> }
> ]
> }
> ]MacBook-Pro:~ jjirsa$
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10783) Allow literal value as parameter of UDF & UDA
[
https://issues.apache.org/jira/browse/CASSANDRA-10783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104967#comment-16104967
]
Jeff Jirsa commented on CASSANDRA-10783:
2.2 is bugfix only, this is a feature / enhancement, so it doesn't qualify for
2.2 (it's also a year old, and nobody else has asked for it to be backported in
that period, so it seems demand is fairly small).
> Allow literal value as parameter of UDF & UDA
> -
>
> Key: CASSANDRA-10783
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10783
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: DOAN DuyHai
>Assignee: Sylvain Lebresne
>Priority: Minor
> Labels: CQL3, UDF, client-impacting, doc-impacting
> Fix For: 3.8
>
>
> I have defined the following UDF
> {code:sql}
> CREATE OR REPLACE FUNCTION maxOf(current int, testValue int) RETURNS NULL ON
> NULL INPUT
> RETURNS int
> LANGUAGE java
> AS 'return Math.max(current,testValue);'
> CREATE TABLE maxValue(id int primary key, val int);
> INSERT INTO maxValue(id, val) VALUES(1, 100);
> SELECT maxOf(val, 101) FROM maxValue WHERE id=1;
> {code}
> I got the following error message:
> {code}
> SyntaxException: message="line 1:19 no viable alternative at input '101' (SELECT maxOf(val1,
> [101]...)">
> {code}
> It would be nice to allow literal value as parameter of UDF and UDA too.
> I was thinking about an use-case for an UDA groupBy() function where the end
> user can *inject* at runtime a literal value to select which aggregation he
> want to display, something similar to GROUP BY ... HAVING
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13348) Duplicate tokens after bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16105793#comment-16105793
]
Jeff Jirsa commented on CASSANDRA-13348:
[~jjordan] - that would be easier to explain than what Tom's seeing - [~tvdw]
suggests that he did one node on a given day and still saw it, which doesn't
feel like a race at all.
> Duplicate tokens after bootstrap
>
>
> Key: CASSANDRA-13348
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13348
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tom van der Woerdt
>Assignee: Dikang Gu
>Priority: Blocker
> Fix For: 3.0.x
>
>
> This one is a bit scary, and probably results in data loss. After a bootstrap
> of a few new nodes into an existing cluster, two new nodes have chosen some
> overlapping tokens.
> In fact, of the 256 tokens chosen, 51 tokens were already in use on the other
> node.
> Node 1 log :
> {noformat}
> INFO [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,461
> StorageService.java:1160 - JOINING: waiting for ring information
> INFO [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,461
> StorageService.java:1160 - JOINING: waiting for schema information to complete
> INFO [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,461
> StorageService.java:1160 - JOINING: schema complete, ready to bootstrap
> INFO [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,462
> StorageService.java:1160 - JOINING: waiting for pending range calculation
> INFO [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,462
> StorageService.java:1160 - JOINING: calculation complete, ready to bootstrap
> INFO [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,462
> StorageService.java:1160 - JOINING: getting bootstrap token
> WARN [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,564
> TokenAllocation.java:61 - Selected tokens [, 2959334889475814712,
> 3727103702384420083, 7183119311535804926, 6013900799616279548,
> -1222135324851761575, 1645259890258332163, -1213352346686661387,
> 7604192574911909354]
> WARN [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,729
> TokenAllocation.java:65 - Replicated node load in datacentre before
> allocation max 1.00 min 1.00 stddev 0.
> WARN [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,729
> TokenAllocation.java:66 - Replicated node load in datacentre after allocation
> max 1.00 min 1.00 stddev 0.
> WARN [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:43,729
> TokenAllocation.java:70 - Unexpected growth in standard deviation after
> allocation.
> INFO [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:42:44,150
> StorageService.java:1160 - JOINING: sleeping 3 ms for pending range setup
> INFO [RMI TCP Connection(107)-127.0.0.1] 2017-03-09 07:43:14,151
> StorageService.java:1160 - JOINING: Starting to bootstrap...
> {noformat}
> Node 2 log:
> {noformat}
> INFO [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:51,937
> StorageService.java:971 - Joining ring by operator request
> INFO [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:52,513
> StorageService.java:1160 - JOINING: waiting for ring information
> INFO [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:52,513
> StorageService.java:1160 - JOINING: waiting for schema information to complete
> INFO [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:52,513
> StorageService.java:1160 - JOINING: schema complete, ready to bootstrap
> INFO [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:52,513
> StorageService.java:1160 - JOINING: waiting for pending range calculation
> INFO [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:52,514
> StorageService.java:1160 - JOINING: calculation complete, ready to bootstrap
> INFO [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:52,514
> StorageService.java:1160 - JOINING: getting bootstrap token
> WARN [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:52,630
> TokenAllocation.java:61 - Selected tokens [.., 2890709530010722764,
> -2416006722819773829, -5820248611267569511, -5990139574852472056,
> 1645259890258332163, 9135021011763659240, -5451286144622276797,
> 7604192574911909354]
> WARN [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:52,794
> TokenAllocation.java:65 - Replicated node load in datacentre before
> allocation max 1.02 min 0.98 stddev 0.
> WARN [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:52,795
> TokenAllocation.java:66 - Replicated node load in datacentre after allocation
> max 1.00 min 1.00 stddev 0.
> INFO [RMI TCP Connection(380)-127.0.0.1] 2017-03-17 15:55:53,149
> StorageService.java:1160 - JOINING: sleeping 3 ms for pending range setup
> INFO [RMI TCP Connection(380)-127.0.0.1] 2017-0
[jira] [Commented] (CASSANDRA-13731) Timeout while setting keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16106829#comment-16106829 ] Jeff Jirsa commented on CASSANDRA-13731: The datastax driver is not a part of the project. Closing. > Timeout while setting keyspace > -- > > Key: CASSANDRA-13731 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13731 > Project: Cassandra > Issue Type: Bug > Environment: Cassandra 2.1.13 >Reporter: peng xiao > > Hi, > We are troubling a strange issue.Currently we have a Cluster with Cassandra > 2.1.13. > when the applications start,it will print the following warings.And it takes > long time for applications to start. > Could you please advise ? > https://datastax-oss.atlassian.net/browse/JAVA-1002 > this one says prepares a PreparedStatement caused this issue and has been > fixed. > but we are still experiencing this in 2.1.13. > 2017-07-26 15:49:20.676 WARN 11706 --- [-] [cluster1-nio-worker-2] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.xxx.xxx.xxx:9042-3, inFlight=5, closed=false]. This should > not happen but is not critical (it will be retried) > 2017-07-26 15:49:20.677 WARN 11706 --- [-] [cluster1-nio-worker-3] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.16.42.xxx:9042-3, inFlight=5, closed=false]. This should not > happen but is not critical (it will be retried) > 2017-07-26 15:49:20.676 WARN 11706 --- [-] [cluster1-nio-worker-0] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.16.42.xxx:9042-3, inFlight=5, closed=false]. This should not > happen but is not critical (it will be retried) > 2017-07-26 15:49:20.676 WARN 11706 --- [-] [cluster1-nio-worker-1] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.16.42.xxx:9042-3, inFlight=5, closed=false]. This should not > happen but is not critical (it will be retried) > 2017-07-26 15:49:32.777 WARN 11706 --- [-] [main] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.xx.xx.xxx:9042-3, inFlight=1, closed=false]. This should not > happen but is not critical (it will be retried) > Thanks -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-13731) Timeout while setting keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13731: --- Comment: was deleted (was: The datastax driver is not a part of the project. Closing. ) > Timeout while setting keyspace > -- > > Key: CASSANDRA-13731 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13731 > Project: Cassandra > Issue Type: Bug > Environment: Cassandra 2.1.13 >Reporter: peng xiao > > Hi, > We are troubling a strange issue.Currently we have a Cluster with Cassandra > 2.1.13. > when the applications start,it will print the following warings.And it takes > long time for applications to start. > Could you please advise ? > https://datastax-oss.atlassian.net/browse/JAVA-1002 > this one says prepares a PreparedStatement caused this issue and has been > fixed. > but we are still experiencing this in 2.1.13. > 2017-07-26 15:49:20.676 WARN 11706 --- [-] [cluster1-nio-worker-2] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.xxx.xxx.xxx:9042-3, inFlight=5, closed=false]. This should > not happen but is not critical (it will be retried) > 2017-07-26 15:49:20.677 WARN 11706 --- [-] [cluster1-nio-worker-3] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.16.42.xxx:9042-3, inFlight=5, closed=false]. This should not > happen but is not critical (it will be retried) > 2017-07-26 15:49:20.676 WARN 11706 --- [-] [cluster1-nio-worker-0] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.16.42.xxx:9042-3, inFlight=5, closed=false]. This should not > happen but is not critical (it will be retried) > 2017-07-26 15:49:20.676 WARN 11706 --- [-] [cluster1-nio-worker-1] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.16.42.xxx:9042-3, inFlight=5, closed=false]. This should not > happen but is not critical (it will be retried) > 2017-07-26 15:49:32.777 WARN 11706 --- [-] [main] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.xx.xx.xxx:9042-3, inFlight=1, closed=false]. This should not > happen but is not critical (it will be retried) > Thanks -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-13731) Timeout while setting keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-13731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa resolved CASSANDRA-13731. Resolution: Won't Fix The datastax driver is an unsupported third-party driver, which is not a part of the project. It appears upgrading that component may fix your issue, but since it's not a part of the project, I'm closing this issue. > Timeout while setting keyspace > -- > > Key: CASSANDRA-13731 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13731 > Project: Cassandra > Issue Type: Bug > Environment: Cassandra 2.1.13 >Reporter: peng xiao > > Hi, > We are troubling a strange issue.Currently we have a Cluster with Cassandra > 2.1.13. > when the applications start,it will print the following warings.And it takes > long time for applications to start. > Could you please advise ? > https://datastax-oss.atlassian.net/browse/JAVA-1002 > this one says prepares a PreparedStatement caused this issue and has been > fixed. > but we are still experiencing this in 2.1.13. > 2017-07-26 15:49:20.676 WARN 11706 --- [-] [cluster1-nio-worker-2] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.xxx.xxx.xxx:9042-3, inFlight=5, closed=false]. This should > not happen but is not critical (it will be retried) > 2017-07-26 15:49:20.677 WARN 11706 --- [-] [cluster1-nio-worker-3] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.16.42.xxx:9042-3, inFlight=5, closed=false]. This should not > happen but is not critical (it will be retried) > 2017-07-26 15:49:20.676 WARN 11706 --- [-] [cluster1-nio-worker-0] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.16.42.xxx:9042-3, inFlight=5, closed=false]. This should not > happen but is not critical (it will be retried) > 2017-07-26 15:49:20.676 WARN 11706 --- [-] [cluster1-nio-worker-1] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.16.42.xxx:9042-3, inFlight=5, closed=false]. This should not > happen but is not critical (it will be retried) > 2017-07-26 15:49:32.777 WARN 11706 --- [-] [main] > com.datastax.driver.core.Connection : Timeout while setting keyspace on > Connection[/xxx.xx.xx.xxx:9042-3, inFlight=1, closed=false]. This should not > happen but is not critical (it will be retried) > Thanks -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13711) Invalid writetime for null columns in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13711:
---
Resolution: Fixed
Fix Version/s: (was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
4.0
3.11.1
3.0.15
Status: Resolved (was: Ready to Commit)
Committed to 3.0 as {{9dc896f4ea51276de4ea76ffca3fd719e0c8b8a1}} and merged
3.11 and 4.0
> Invalid writetime for null columns in cqlsh
> ---
>
> Key: CASSANDRA-13711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13711
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> From the user list:
> https://lists.apache.org/thread.html/448731c029eee72e499fc6acd44d257d1671193f850a68521c2c6681@%3Cuser.cassandra.apache.org%3E
> {code}
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm create test -n 1 -s -v 3.0.10
> Current cluster is now: test
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm node1 cqlsh
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.10 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE test.t ( a text primary key, b text );
> cqlsh> insert into test.t(a) values('z');
> cqlsh> insert into test.t(a) values('w');
> cqlsh> insert into test.t(a) values('e');
> cqlsh> insert into test.t(a) values('r');
> cqlsh> insert into test.t(a) values('t');
> cqlsh> select a,b, writetime (b) from test.t;
> a | b | writetime(b)
> ---+--+--
> z | null | null
> e | null | null
> r | null | null
> w | null | null
> t | null | null
> (5 rows)
> cqlsh>
> cqlsh> insert into test.t(a,b) values('t','x');
> cqlsh> insert into test.t(a) values('b');
> cqlsh> select a,b, writetime (b) from test.t;
> a | b| writetime(b)
> ---+--+--
> z | null | null
> e | null | null
> r | null | null
> w | null | null
> t |x | 1500565131354883
> b | null | 1500565131354883
> (6 rows)
> {code}
> Data on disk:
> {code}
> MacBook-Pro:~ jjirsa$ ~/.ccm/repository/3.0.14/tools/bin/sstabledump
> /Users/jjirsa/.ccm/test/node1/data0/test/t-bed196006d0511e7904be9daad294861/mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "z" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 20,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:54.818118Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "e" ],
> "position" : 21
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 44,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:04.288547Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "r" ],
> "position" : 45
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 68,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:08.991417Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "w" ],
> "position" : 69
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 92,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:59.005382Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "t" ],
> "position" : 93
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 120,
> "liveness_info" : { "tstamp" : "2017-07-20T15:38:51.354883Z" },
> "cells" : [
> { "name" : "b", "value" : "x" }
> ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "b" ],
> "position" : 121
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 146,
> "liveness_info" : { "tstamp" : "2017-07-20T15:39:03.631297Z" },
> "cells" : [ ]
> }
> ]
> }
> ]MacBook-Pro:~ jjirsa$
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13711) Invalid writetime for null columns in cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13711:
---
Status: Ready to Commit (was: Patch Available)
> Invalid writetime for null columns in cqlsh
> ---
>
> Key: CASSANDRA-13711
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13711
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 3.0.15, 3.11.1, 4.0
>
>
> From the user list:
> https://lists.apache.org/thread.html/448731c029eee72e499fc6acd44d257d1671193f850a68521c2c6681@%3Cuser.cassandra.apache.org%3E
> {code}
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm create test -n 1 -s -v 3.0.10
> Current cluster is now: test
> (oss-ccm) MacBook-Pro:~ jjirsa$ ccm node1 cqlsh
> Connected to test at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.0.10 | CQL spec 3.4.0 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE test.t ( a text primary key, b text );
> cqlsh> insert into test.t(a) values('z');
> cqlsh> insert into test.t(a) values('w');
> cqlsh> insert into test.t(a) values('e');
> cqlsh> insert into test.t(a) values('r');
> cqlsh> insert into test.t(a) values('t');
> cqlsh> select a,b, writetime (b) from test.t;
> a | b | writetime(b)
> ---+--+--
> z | null | null
> e | null | null
> r | null | null
> w | null | null
> t | null | null
> (5 rows)
> cqlsh>
> cqlsh> insert into test.t(a,b) values('t','x');
> cqlsh> insert into test.t(a) values('b');
> cqlsh> select a,b, writetime (b) from test.t;
> a | b| writetime(b)
> ---+--+--
> z | null | null
> e | null | null
> r | null | null
> w | null | null
> t |x | 1500565131354883
> b | null | 1500565131354883
> (6 rows)
> {code}
> Data on disk:
> {code}
> MacBook-Pro:~ jjirsa$ ~/.ccm/repository/3.0.14/tools/bin/sstabledump
> /Users/jjirsa/.ccm/test/node1/data0/test/t-bed196006d0511e7904be9daad294861/mc-1-big-Data.db
> [
> {
> "partition" : {
> "key" : [ "z" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 20,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:54.818118Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "e" ],
> "position" : 21
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 44,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:04.288547Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "r" ],
> "position" : 45
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 68,
> "liveness_info" : { "tstamp" : "2017-07-20T04:42:08.991417Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "w" ],
> "position" : 69
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 92,
> "liveness_info" : { "tstamp" : "2017-07-20T04:41:59.005382Z" },
> "cells" : [ ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "t" ],
> "position" : 93
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 120,
> "liveness_info" : { "tstamp" : "2017-07-20T15:38:51.354883Z" },
> "cells" : [
> { "name" : "b", "value" : "x" }
> ]
> }
> ]
> },
> {
> "partition" : {
> "key" : [ "b" ],
> "position" : 121
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 146,
> "liveness_info" : { "tstamp" : "2017-07-20T15:39:03.631297Z" },
> "cells" : [ ]
> }
> ]
> }
> ]MacBook-Pro:~ jjirsa$
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11995) Commitlog replaced with all NULs
[
https://issues.apache.org/jira/browse/CASSANDRA-11995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16108122#comment-16108122
]
Jeff Jirsa commented on CASSANDRA-11995:
[~blambov] - I do think there's a few areas for improvement, though this is the
low hanging fruit of it. The one case where I was able to see this myself was
in a test environment where failures were expected (and indeed, injected), but
based on the descriptions above, I believe happens on any unclean shutdown
triggered during startup.
I'd personally like to commit this as an intermediate step, and not try to fix
ALL of the potential problems at once (I think this removes the most obvious
cause, and does it with very little risk). Are you ok with that, and we can
open some follow-up tickets as they arise?
> Commitlog replaced with all NULs
>
>
> Key: CASSANDRA-11995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows 10 Enterprise 1511
> DataStax Cassandra Community Server 2.2.3
>Reporter: James Howe
>Assignee: Jeff Jirsa
>
> I noticed this morning that Cassandra was failing to start, after being shut
> down on Friday.
> {code}
> ERROR 09:13:37 Exiting due to error while processing commit log during
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException:
> Could not read commit log descriptor in file C:\Program Files\DataStax
> Community\data\commitlog\CommitLog-5-1465571056722.log
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
> [apache-cassandra-2.2.3.jar:2.2.3]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
> [apache-cassandra-2.2.3.jar:2.2.3]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
> [apache-cassandra-2.2.3.jar:2.2.3]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189)
> [apache-cassandra-2.2.3.jar:2.2.3]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169)
> [apache-cassandra-2.2.3.jar:2.2.3]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273)
> [apache-cassandra-2.2.3.jar:2.2.3]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513)
> [apache-cassandra-2.2.3.jar:2.2.3]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622)
> [apache-cassandra-2.2.3.jar:2.2.3]
> {code}
> Checking the referenced file reveals it comprises 33,554,432 (32 * 1024 *
> 1024) NUL bytes.
> No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and
> appear exactly as normal.
> Is installed as a service via DataStax's distribution.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13736) CASSANDRA-9673 cause atomic batch p99 increase 3x
[
https://issues.apache.org/jira/browse/CASSANDRA-13736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16108355#comment-16108355
]
Jeff Jirsa commented on CASSANDRA-13736:
I think blocking for {{TWO}} on batchlog sync is the intended behavior, though
it's not technically in the
[docs|http://cassandra.apache.org/doc/latest/cql/dml.html#batch]
Having a batch only sync'd to one node doesn't seem like much of a guarantee.
> CASSANDRA-9673 cause atomic batch p99 increase 3x
> -
>
> Key: CASSANDRA-13736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13736
> Project: Cassandra
> Issue Type: Bug
>Reporter: xiangzhou xia
>Assignee: xiangzhou xia
>
> When we testing atomic batch in production traffic, we found that p99 latency
> in atomic batch write is 2x-3x worse than 2.2.
> After debuging, we found that the regression is causing by CASSANDRA-9673.
> This patch changed consistency level in batchlog store from ONE to TWO.
> [~iamaleksey] think only block for one batchlog message is a bug in batchlog
> and change it to block for two in CASSANDRA-9673, I think it's actually a
> very good optimization to reduce latency.
> Set the consistency to one will decrease the possibility of slow data node
> (GC, long message queue, etc) affect the latency of atomic batch. In our
> shadow cluster, when we change consistency from two to one, we notice a 2x-3x
> p99 latency drop in atomic batch.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13643) converting expired ttl cells to tombstones causing unnecessary digest mismatches
[
https://issues.apache.org/jira/browse/CASSANDRA-13643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16109383#comment-16109383
]
Jeff Jirsa commented on CASSANDRA-13643:
Missing a fixver btw.
> converting expired ttl cells to tombstones causing unnecessary digest
> mismatches
>
>
> Key: CASSANDRA-13643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13643
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
>
> In
> [{{AbstractCell#purge}}|https://github.com/apache/cassandra/blob/26e025804c6777a0d124dbc257747cba85b18f37/src/java/org/apache/cassandra/db/rows/AbstractCell.java#L77]
> , we convert expired ttl'd cells to tombstones, and set the the local
> deletion time to the cell's expiration time, less the ttl time. Depending on
> the timing of the purge, this can cause purge to generate tombstones that are
> otherwise purgeable. If compaction for a row with ttls isn't at the same
> state between replicas, this will then cause digest mismatches between
> logically identical rows, leading to unnecessary repair streaming and read
> repairs.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13643) converting expired ttl cells to tombstones causing unnecessary digest mismatches
[
https://issues.apache.org/jira/browse/CASSANDRA-13643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13643:
---
Fix Version/s: 4.0
> converting expired ttl cells to tombstones causing unnecessary digest
> mismatches
>
>
> Key: CASSANDRA-13643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13643
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Minor
> Fix For: 4.0
>
>
> In
> [{{AbstractCell#purge}}|https://github.com/apache/cassandra/blob/26e025804c6777a0d124dbc257747cba85b18f37/src/java/org/apache/cassandra/db/rows/AbstractCell.java#L77]
> , we convert expired ttl'd cells to tombstones, and set the the local
> deletion time to the cell's expiration time, less the ttl time. Depending on
> the timing of the purge, this can cause purge to generate tombstones that are
> otherwise purgeable. If compaction for a row with ttls isn't at the same
> state between replicas, this will then cause digest mismatches between
> logically identical rows, leading to unnecessary repair streaming and read
> repairs.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13651) Large amount of CPU used by epoll_wait(.., .., .., 0)
[
https://issues.apache.org/jira/browse/CASSANDRA-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110320#comment-16110320
]
Jeff Jirsa commented on CASSANDRA-13651:
That's really interesting. [~norman] - if you get a few minutes to glance,
always appreciate your thoughts here.
> Large amount of CPU used by epoll_wait(.., .., .., 0)
> -
>
> Key: CASSANDRA-13651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13651
> Project: Cassandra
> Issue Type: Bug
>Reporter: Corentin Chary
> Fix For: 4.x
>
> Attachments: cpu-usage.png
>
>
> I was trying to profile Cassandra under my workload and I kept seeing this
> backtrace:
> {code}
> epollEventLoopGroup-2-3 State: RUNNABLE CPU usage on sample: 240ms
> io.netty.channel.epoll.Native.epollWait0(int, long, int, int) Native.java
> (native)
> io.netty.channel.epoll.Native.epollWait(int, EpollEventArray, int)
> Native.java:111
> io.netty.channel.epoll.EpollEventLoop.epollWait(boolean)
> EpollEventLoop.java:230
> io.netty.channel.epoll.EpollEventLoop.run() EpollEventLoop.java:254
> io.netty.util.concurrent.SingleThreadEventExecutor$5.run()
> SingleThreadEventExecutor.java:858
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run()
> DefaultThreadFactory.java:138
> java.lang.Thread.run() Thread.java:745
> {code}
> At fist I though that the profiler might not be able to profile native code
> properly, but I wen't further and I realized that most of the CPU was used by
> {{epoll_wait()}} calls with a timeout of zero.
> Here is the output of perf on this system, which confirms that most of the
> overhead was with timeout == 0.
> {code}
> Samples: 11M of event 'syscalls:sys_enter_epoll_wait', Event count (approx.):
> 11594448
> Overhead Trace output
>
> ◆
> 90.06% epfd: 0x0047, events: 0x7f5588c0c000, maxevents: 0x2000,
> timeout: 0x
> ▒
>5.77% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x
> ▒
>1.98% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x03e8
> ▒
>0.04% epfd: 0x0003, events: 0x2f6af77b9c00, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.04% epfd: 0x002b, events: 0x121ebf63ac00, maxevents: 0x0040,
> timeout: 0x
> ▒
>0.03% epfd: 0x0026, events: 0x7f51f80019c0, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.02% epfd: 0x0003, events: 0x7fe4d80019d0, maxevents: 0x0020,
> timeout: 0x
> {code}
> Running this time with perf record -ag for call traces:
> {code}
> # Children Self sys usr Trace output
>
> #
>
> #
> 8.61% 8.61% 0.00% 8.61% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x
> |
> ---0x1000200af313
>|
> --8.61%--0x7fca6117bdac
> 0x7fca60459804
> epoll_wait
> 2.98% 2.98% 0.00% 2.98% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x03e8
> |
> ---0x1000200af313
>0x7fca6117b830
>0x7fca60459804
>epoll_wait
> {code}
> That looks like a lot of CPU used to wait for nothing. I'm not sure if pref
> reports a per-CPU percentage or a per-system percentage, but that would be
> still be 10% of the total CPU usage of Cassandra at the minimum.
> I went further and found the code of all that: We schedule a lot of
> {{Message::Flusher}} with a deadline of 10 usec (5 per messages I think) but
> netty+epoll only support timeouts above the milliseconds and will con
[jira] [Comment Edited] (CASSANDRA-13651) Large amount of CPU used by epoll_wait(.., .., .., 0)
[
https://issues.apache.org/jira/browse/CASSANDRA-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110320#comment-16110320
]
Jeff Jirsa edited comment on CASSANDRA-13651 at 8/2/17 5:58 AM:
That's really interesting. [~norman] - if you get a few minutes to glance,
always appreciate your thoughts here.
Also, [~iksaif] - can you share a bit more detail on your test? Is it just
stress? Have you tested with many connected clients? Any immediate reason you
suspect that CPU went down (significantly?), but throughput remains unchanged
(do you see the next bottleneck, the op rate on that stress run looks pretty
low, even for a single machine cluster?)
was (Author: jjirsa):
That's really interesting. [~norman] - if you get a few minutes to glance,
always appreciate your thoughts here.
> Large amount of CPU used by epoll_wait(.., .., .., 0)
> -
>
> Key: CASSANDRA-13651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13651
> Project: Cassandra
> Issue Type: Bug
>Reporter: Corentin Chary
> Fix For: 4.x
>
> Attachments: cpu-usage.png
>
>
> I was trying to profile Cassandra under my workload and I kept seeing this
> backtrace:
> {code}
> epollEventLoopGroup-2-3 State: RUNNABLE CPU usage on sample: 240ms
> io.netty.channel.epoll.Native.epollWait0(int, long, int, int) Native.java
> (native)
> io.netty.channel.epoll.Native.epollWait(int, EpollEventArray, int)
> Native.java:111
> io.netty.channel.epoll.EpollEventLoop.epollWait(boolean)
> EpollEventLoop.java:230
> io.netty.channel.epoll.EpollEventLoop.run() EpollEventLoop.java:254
> io.netty.util.concurrent.SingleThreadEventExecutor$5.run()
> SingleThreadEventExecutor.java:858
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run()
> DefaultThreadFactory.java:138
> java.lang.Thread.run() Thread.java:745
> {code}
> At fist I though that the profiler might not be able to profile native code
> properly, but I wen't further and I realized that most of the CPU was used by
> {{epoll_wait()}} calls with a timeout of zero.
> Here is the output of perf on this system, which confirms that most of the
> overhead was with timeout == 0.
> {code}
> Samples: 11M of event 'syscalls:sys_enter_epoll_wait', Event count (approx.):
> 11594448
> Overhead Trace output
>
> ◆
> 90.06% epfd: 0x0047, events: 0x7f5588c0c000, maxevents: 0x2000,
> timeout: 0x
> ▒
>5.77% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x
> ▒
>1.98% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x03e8
> ▒
>0.04% epfd: 0x0003, events: 0x2f6af77b9c00, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.04% epfd: 0x002b, events: 0x121ebf63ac00, maxevents: 0x0040,
> timeout: 0x
> ▒
>0.03% epfd: 0x0026, events: 0x7f51f80019c0, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.02% epfd: 0x0003, events: 0x7fe4d80019d0, maxevents: 0x0020,
> timeout: 0x
> {code}
> Running this time with perf record -ag for call traces:
> {code}
> # Children Self sys usr Trace output
>
> #
>
> #
> 8.61% 8.61% 0.00% 8.61% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x
> |
> ---0x1000200af313
>|
> --8.61%--0x7fca6117bdac
> 0x7fca60459804
> epoll_wait
> 2.98% 2.98% 0.00% 2.98% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x03e8
> |
> ---0x1000200af313
>
[jira] [Commented] (CASSANDRA-13651) Large amount of CPU used by epoll_wait(.., .., .., 0)
[
https://issues.apache.org/jira/browse/CASSANDRA-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110935#comment-16110935
]
Jeff Jirsa commented on CASSANDRA-13651:
[~iksaif] - this is not a review (and I think there are better people around to
review this than myself, like either Norman, Jason, Jake or Ariel), but I'm
unable to get a clean test run with your patch on trunk with either netty
4.0.44 or 4.1.13. You mention in the first post that you added some traces to
4.1 - can you confirm which version of netty you tested with? Can you also
confirm whether or not {{ant test -Dtest.name=NativeTransportServiceTest}}
passes cleanly for you?
> Large amount of CPU used by epoll_wait(.., .., .., 0)
> -
>
> Key: CASSANDRA-13651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13651
> Project: Cassandra
> Issue Type: Bug
>Reporter: Corentin Chary
> Fix For: 4.x
>
> Attachments: cpu-usage.png
>
>
> I was trying to profile Cassandra under my workload and I kept seeing this
> backtrace:
> {code}
> epollEventLoopGroup-2-3 State: RUNNABLE CPU usage on sample: 240ms
> io.netty.channel.epoll.Native.epollWait0(int, long, int, int) Native.java
> (native)
> io.netty.channel.epoll.Native.epollWait(int, EpollEventArray, int)
> Native.java:111
> io.netty.channel.epoll.EpollEventLoop.epollWait(boolean)
> EpollEventLoop.java:230
> io.netty.channel.epoll.EpollEventLoop.run() EpollEventLoop.java:254
> io.netty.util.concurrent.SingleThreadEventExecutor$5.run()
> SingleThreadEventExecutor.java:858
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run()
> DefaultThreadFactory.java:138
> java.lang.Thread.run() Thread.java:745
> {code}
> At fist I though that the profiler might not be able to profile native code
> properly, but I wen't further and I realized that most of the CPU was used by
> {{epoll_wait()}} calls with a timeout of zero.
> Here is the output of perf on this system, which confirms that most of the
> overhead was with timeout == 0.
> {code}
> Samples: 11M of event 'syscalls:sys_enter_epoll_wait', Event count (approx.):
> 11594448
> Overhead Trace output
>
> ◆
> 90.06% epfd: 0x0047, events: 0x7f5588c0c000, maxevents: 0x2000,
> timeout: 0x
> ▒
>5.77% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x
> ▒
>1.98% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x03e8
> ▒
>0.04% epfd: 0x0003, events: 0x2f6af77b9c00, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.04% epfd: 0x002b, events: 0x121ebf63ac00, maxevents: 0x0040,
> timeout: 0x
> ▒
>0.03% epfd: 0x0026, events: 0x7f51f80019c0, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.02% epfd: 0x0003, events: 0x7fe4d80019d0, maxevents: 0x0020,
> timeout: 0x
> {code}
> Running this time with perf record -ag for call traces:
> {code}
> # Children Self sys usr Trace output
>
> #
>
> #
> 8.61% 8.61% 0.00% 8.61% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x
> |
> ---0x1000200af313
>|
> --8.61%--0x7fca6117bdac
> 0x7fca60459804
> epoll_wait
> 2.98% 2.98% 0.00% 2.98% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x03e8
> |
> ---0x1000200af313
>0x7fca6117b830
>0x7fca60459804
>epoll_wait
> {code}
> That looks like a lot of CPU used to wait for nothing. I'm not sure if p
[jira] [Assigned] (CASSANDRA-13651) Large amount of CPU used by epoll_wait(.., .., .., 0)
[
https://issues.apache.org/jira/browse/CASSANDRA-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa reassigned CASSANDRA-13651:
--
Assignee: Corentin Chary
> Large amount of CPU used by epoll_wait(.., .., .., 0)
> -
>
> Key: CASSANDRA-13651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13651
> Project: Cassandra
> Issue Type: Bug
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 4.x
>
> Attachments: cpu-usage.png
>
>
> I was trying to profile Cassandra under my workload and I kept seeing this
> backtrace:
> {code}
> epollEventLoopGroup-2-3 State: RUNNABLE CPU usage on sample: 240ms
> io.netty.channel.epoll.Native.epollWait0(int, long, int, int) Native.java
> (native)
> io.netty.channel.epoll.Native.epollWait(int, EpollEventArray, int)
> Native.java:111
> io.netty.channel.epoll.EpollEventLoop.epollWait(boolean)
> EpollEventLoop.java:230
> io.netty.channel.epoll.EpollEventLoop.run() EpollEventLoop.java:254
> io.netty.util.concurrent.SingleThreadEventExecutor$5.run()
> SingleThreadEventExecutor.java:858
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run()
> DefaultThreadFactory.java:138
> java.lang.Thread.run() Thread.java:745
> {code}
> At fist I though that the profiler might not be able to profile native code
> properly, but I wen't further and I realized that most of the CPU was used by
> {{epoll_wait()}} calls with a timeout of zero.
> Here is the output of perf on this system, which confirms that most of the
> overhead was with timeout == 0.
> {code}
> Samples: 11M of event 'syscalls:sys_enter_epoll_wait', Event count (approx.):
> 11594448
> Overhead Trace output
>
> ◆
> 90.06% epfd: 0x0047, events: 0x7f5588c0c000, maxevents: 0x2000,
> timeout: 0x
> ▒
>5.77% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x
> ▒
>1.98% epfd: 0x00b5, events: 0x7fca419ef000, maxevents: 0x1000,
> timeout: 0x03e8
> ▒
>0.04% epfd: 0x0003, events: 0x2f6af77b9c00, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.04% epfd: 0x002b, events: 0x121ebf63ac00, maxevents: 0x0040,
> timeout: 0x
> ▒
>0.03% epfd: 0x0026, events: 0x7f51f80019c0, maxevents: 0x0020,
> timeout: 0x
> ▒
>0.02% epfd: 0x0003, events: 0x7fe4d80019d0, maxevents: 0x0020,
> timeout: 0x
> {code}
> Running this time with perf record -ag for call traces:
> {code}
> # Children Self sys usr Trace output
>
> #
>
> #
> 8.61% 8.61% 0.00% 8.61% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x
> |
> ---0x1000200af313
>|
> --8.61%--0x7fca6117bdac
> 0x7fca60459804
> epoll_wait
> 2.98% 2.98% 0.00% 2.98% epfd: 0x00a7, events:
> 0x7fca452d6000, maxevents: 0x1000, timeout: 0x03e8
> |
> ---0x1000200af313
>0x7fca6117b830
>0x7fca60459804
>epoll_wait
> {code}
> That looks like a lot of CPU used to wait for nothing. I'm not sure if pref
> reports a per-CPU percentage or a per-system percentage, but that would be
> still be 10% of the total CPU usage of Cassandra at the minimum.
> I went further and found the code of all that: We schedule a lot of
> {{Message::Flusher}} with a deadline of 10 usec (5 per messages I think) but
> netty+epoll only support timeouts above the milliseconds and will convert
> everything bellow to 0.
> I added some traces to netty (4.1):
> {code}
> diff --git
> a/tra
[jira] [Commented] (CASSANDRA-13738) Load is over calculated after each IndexSummaryRedistribution
[
https://issues.apache.org/jira/browse/CASSANDRA-13738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112060#comment-16112060
]
Jeff Jirsa commented on CASSANDRA-13738:
Are you aware yet if this is a new regression? If so, when was it introduced?
> Load is over calculated after each IndexSummaryRedistribution
> -
>
> Key: CASSANDRA-13738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13738
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: sizeIssue.png
>
>
> For example, here is one of our cluster with about 500GB per node, but
> {{nodetool status}} shows far more load than it actually is and keeps
> increasing, restarting the process will reset the load, but keeps increasing
> afterwards:
> {noformat}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN IP1* 13.52 TB 256 100.0%
> c4c31e0a-3f01-49f7-8a22-33043737975d rac1
> UN IP2* 14.25 TB 256 100.0%
> efec4980-ec9e-4424-8a21-ce7ddaf80aa0 rac1
> UN IP3* 13.52 TB 256 100.0%
> 7dbcfdfc-9c07-4b1a-a4b9-970b715ebed8 rac1
> UN IP4* 22.13 TB 256 100.0%
> 8879e6c4-93e3-4cc5-b957-f999c6b9b563 rac1
> UN IP5* 18.02 TB 256 100.0%
> 4a1eaf22-4a83-4736-9e1c-12f898d685fa rac1
> UN IP6* 11.68 TB 256 100.0%
> d633c591-28af-42cc-bc5e-47d1c8bcf50f rac1
> {noformat}
> !sizeIssue.png|test!
> The root cause is if the SSTable index summary is redistributed (typically
> executes hourly), the updated SSTable size is added again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13738) Load is over calculated after each IndexSummaryRedistribution
[
https://issues.apache.org/jira/browse/CASSANDRA-13738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113782#comment-16113782
]
Jeff Jirsa commented on CASSANDRA-13738:
I'll take review but I'm at least two weeks away from getting to it
If anyone else beats me to it I won't mind
> Load is over calculated after each IndexSummaryRedistribution
> -
>
> Key: CASSANDRA-13738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13738
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
> Attachments: sizeIssue.png
>
>
> For example, here is one of our cluster with about 500GB per node, but
> {{nodetool status}} shows far more load than it actually is and keeps
> increasing, restarting the process will reset the load, but keeps increasing
> afterwards:
> {noformat}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN IP1* 13.52 TB 256 100.0%
> c4c31e0a-3f01-49f7-8a22-33043737975d rac1
> UN IP2* 14.25 TB 256 100.0%
> efec4980-ec9e-4424-8a21-ce7ddaf80aa0 rac1
> UN IP3* 13.52 TB 256 100.0%
> 7dbcfdfc-9c07-4b1a-a4b9-970b715ebed8 rac1
> UN IP4* 22.13 TB 256 100.0%
> 8879e6c4-93e3-4cc5-b957-f999c6b9b563 rac1
> UN IP5* 18.02 TB 256 100.0%
> 4a1eaf22-4a83-4736-9e1c-12f898d685fa rac1
> UN IP6* 11.68 TB 256 100.0%
> d633c591-28af-42cc-bc5e-47d1c8bcf50f rac1
> {noformat}
> !sizeIssue.png|test!
> The root cause is if the SSTable index summary is redistributed (typically
> executes hourly), the updated SSTable size is added again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13738) Load is over calculated after each IndexSummaryRedistribution
[
https://issues.apache.org/jira/browse/CASSANDRA-13738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13738:
---
Flags: Patch
Reviewer: Jeff Jirsa
> Load is over calculated after each IndexSummaryRedistribution
> -
>
> Key: CASSANDRA-13738
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13738
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Jay Zhuang
>Assignee: Jay Zhuang
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
> Attachments: sizeIssue.png
>
>
> For example, here is one of our cluster with about 500GB per node, but
> {{nodetool status}} shows far more load than it actually is and keeps
> increasing, restarting the process will reset the load, but keeps increasing
> afterwards:
> {noformat}
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN IP1* 13.52 TB 256 100.0%
> c4c31e0a-3f01-49f7-8a22-33043737975d rac1
> UN IP2* 14.25 TB 256 100.0%
> efec4980-ec9e-4424-8a21-ce7ddaf80aa0 rac1
> UN IP3* 13.52 TB 256 100.0%
> 7dbcfdfc-9c07-4b1a-a4b9-970b715ebed8 rac1
> UN IP4* 22.13 TB 256 100.0%
> 8879e6c4-93e3-4cc5-b957-f999c6b9b563 rac1
> UN IP5* 18.02 TB 256 100.0%
> 4a1eaf22-4a83-4736-9e1c-12f898d685fa rac1
> UN IP6* 11.68 TB 256 100.0%
> d633c591-28af-42cc-bc5e-47d1c8bcf50f rac1
> {noformat}
> !sizeIssue.png|test!
> The root cause is if the SSTable index summary is redistributed (typically
> executes hourly), the updated SSTable size is added again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13741) Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113964#comment-16113964 ] Jeff Jirsa commented on CASSANDRA-13741: We don't typically update dependencies unless there's a reason. Is there a specific fix you're looking for? > Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar > - > > Key: CASSANDRA-13741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13741 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Amitkumar Ghatwal > Fix For: 4.0 > > > Hi All, > The latest lz4-java library has been released > (https://github.com/lz4/lz4-java/releases) and uploaded to maven central . > Please replace in mainline the current version ( 1.3.0) with the latest one ( > 1.4.0) from here - http://repo1.maven.org/maven2/org/lz4/lz4-java/1.4.0/ > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13741) Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar
[
https://issues.apache.org/jira/browse/CASSANDRA-13741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113964#comment-16113964
]
Jeff Jirsa edited comment on CASSANDRA-13741 at 8/4/17 5:39 AM:
We don't typically update dependencies unless there's a reason. Is there a
specific fix you're looking for?
This is also {{org.lz4}} rather than {{net.jpountz.lz4}} - what's going on
here?
was (Author: jjirsa):
We don't typically update dependencies unless there's a reason. Is there a
specific fix you're looking for?
> Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar
> -
>
> Key: CASSANDRA-13741
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13741
> Project: Cassandra
> Issue Type: Improvement
> Components: Libraries
>Reporter: Amitkumar Ghatwal
> Fix For: 4.0
>
>
> Hi All,
> The latest lz4-java library has been released
> (https://github.com/lz4/lz4-java/releases) and uploaded to maven central .
> Please replace in mainline the current version ( 1.3.0) with the latest one (
> 1.4.0) from here - http://repo1.maven.org/maven2/org/lz4/lz4-java/1.4.0/
> Regards,
> Amit
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13741) Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114423#comment-16114423 ] Jeff Jirsa commented on CASSANDRA-13741: Still needs a patch and a reviewer, and I don't have the personal bandwidth for either. I hope (expect) the reviewer to be very diligent in confirming that the upgrade dtests are run with compression enabled, and it'd be extra nice if we could confirm that the upgrade dtests use different lz4 compression levels to make sure that upgrading this library doesn't introduce data corrupting regressions for existing users > Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar > - > > Key: CASSANDRA-13741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13741 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Amitkumar Ghatwal > Fix For: 4.0 > > > Hi All, > The latest lz4-java library has been released > (https://github.com/lz4/lz4-java/releases) and uploaded to maven central . > Please replace in mainline the current version ( 1.3.0) with the latest one ( > 1.4.0) from here - http://repo1.maven.org/maven2/org/lz4/lz4-java/1.4.0/ > Adding : [~ReiOdaira]. > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13741) Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13741: --- Fix Version/s: (was: 4.0) 4.x > Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar > - > > Key: CASSANDRA-13741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13741 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Amitkumar Ghatwal > Fix For: 4.x > > > Hi All, > The latest lz4-java library has been released > (https://github.com/lz4/lz4-java/releases) and uploaded to maven central . > Please replace in mainline the current version ( 1.3.0) with the latest one ( > 1.4.0) from here - http://repo1.maven.org/maven2/org/lz4/lz4-java/1.4.0/ > Adding : [~ReiOdaira]. > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13744) Better bootstrap failure message when blocked by (potential) range movement
[
https://issues.apache.org/jira/browse/CASSANDRA-13744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114605#comment-16114605
]
Jeff Jirsa commented on CASSANDRA-13744:
Patch looks good to me, but before we commit, can you kick off a unit test run
with circleci or jenkins, and a dtest run using the ASF jenkins? Just to be
sure we don't
break any existing tests.
> Better bootstrap failure message when blocked by (potential) range movement
> ---
>
> Key: CASSANDRA-13744
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13744
> Project: Cassandra
> Issue Type: Bug
>Reporter: mck
>Assignee: mck
>Priority: Trivial
> Fix For: 4.0, 3.11.x
>
> Attachments: cassandra-3.11_13744.txt, trunk_13744.txt
>
>
> The UnsupportedOperationException thrown from
> {{StorageService.joinTokenRing(..)}} when it's detected that other nodes are
> bootstrapping|leaving|moving offers no information as to which are those
> other nodes.
> In a large cluster this might not be obvious nor easy to discover, gossipinfo
> can hold information that takes a bit of effort to uncover. Even when it is
> easily seen which nodes are in those states it's helpful to have it confirmed.
> Attached is the patch that provides a more thorough exception message to the
> failed bootstrap attempt.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13363) java.lang.ArrayIndexOutOfBoundsException: null
[
https://issues.apache.org/jira/browse/CASSANDRA-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115480#comment-16115480
]
Jeff Jirsa commented on CASSANDRA-13363:
Relevant code is:
{code}
public ClusteringIndexFilter deserialize(DataInputPlus in, int version,
CFMetaData metadata) throws IOException
{
Kind kind = Kind.values()[in.readUnsignedByte()]; // We read a
byte, and then try to find the kind, and we're way outside of the array
boolean reversed = in.readBoolean();
return kind.deserializer.deserialize(in, version, metadata,
reversed);
}
{code}
And
{code}
public Slice.Bound deserialize(DataInputPlus in, int version,
List> types) throws IOException
{
Kind kind = Kind.values()[in.readByte()]; // same thing, read a
byte, way outside of the array
return deserializeValues(in, kind, version, types);
}
{code}
> java.lang.ArrayIndexOutOfBoundsException: null
> --
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>Priority: Critical
>
> Constantly see this error in the log without any additional information or a
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13363) java.lang.ArrayIndexOutOfBoundsException: null
[
https://issues.apache.org/jira/browse/CASSANDRA-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115515#comment-16115515
]
Jeff Jirsa commented on CASSANDRA-13363:
{quote}
And worth to mention that 3 nodes Cassandra cluster becomes completely
unreposnsive after that exception.
Exception itself occures on all 3 nodes.
{quote}
Does a cluster restart help, or does it stay broken?
Did you recently do any changes? Changing schemas? Do you see any signs of
physical hardware errors (interface counters showing errors)?
> java.lang.ArrayIndexOutOfBoundsException: null
> --
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>Priority: Critical
>
> Constantly see this error in the log without any additional information or a
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13663) Cassandra 3.10 crashes without dump
[ https://issues.apache.org/jira/browse/CASSANDRA-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115628#comment-16115628 ] Jeff Jirsa commented on CASSANDRA-13663: It's likely being killed by the system on-killer - you'll probably see traces in smear Cassandra allocates a fixed amount of memory for the heap, and a variable amount of RAM offheap for things like bloom filters and compression offsets Both bloom filters and compression offsets scale linearly with disk space (and can be much higher with various table specific settings), and are allocated in chunks during compaction. It's very likely you're seeing a compaction start, and the bloom filter allocation triggers the Pom-killer How much ram is in the system? How big is the heap? How much data is on each node? > Cassandra 3.10 crashes without dump > --- > > Key: CASSANDRA-13663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13663 > Project: Cassandra > Issue Type: Bug >Reporter: Matthias Otto >Priority: Minor > Attachments: 2017-07-04 10_48_34-CloudWatch Management Console.png, > cassandra debug.log, cassandra system.log, RamUsageExamle1.png, > RamUsageExample2.png > > > Hello. My company runs a 5 node Cassandra cluster. For the last few weeks, we > have had a sporadic issue where one of the servers crashes without creating a > dump file and without any error messages in the logs. If one restarts the > service (which we have by now scripted to happen automatically), the servers > resumes work with no complaint. > Log files of the time of the last crash are attached, thou again they do not > log any crash happening. > Regarding out setup, we are running these servers on AMazon AWS, with 3 > volumes per server, one for the system, one for data and one for the > commitlog. When a crash happens, we can observe a sudden spike of read > activity on the commitlog volume. All of these have ample free space. > Aspecially the system volume has more then enough free space so that a dump > could be written. > The servers are Ubuntu 16.04 servers and Cassandra is installed from the > apt-get packet for version 3.10. > It is worth noting that these crashes happen more often when nodetool is > running either repair job or a backup job, but this is by no means always the > case. As for frequency, we have had about 1-2 crashes per week for the last > month. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13663) Cassandra 3.10 crashes without dump
[ https://issues.apache.org/jira/browse/CASSANDRA-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115628#comment-16115628 ] Jeff Jirsa edited comment on CASSANDRA-13663 at 8/6/17 4:44 AM: It's likely being killed by the system oom-killer - you'll probably see traces in smear Cassandra allocates a fixed amount of memory for the heap, and a variable amount of RAM offheap for things like bloom filters and compression offsets Both bloom filters and compression offsets scale linearly with disk space (and can be much higher with various table specific settings), and are allocated in chunks during compaction. It's very likely you're seeing a compaction start, and the bloom filter allocation triggers the oom-killer How much ram is in the system? How big is the heap? How much data is on each node? was (Author: jjirsa): It's likely being killed by the system on-killer - you'll probably see traces in smear Cassandra allocates a fixed amount of memory for the heap, and a variable amount of RAM offheap for things like bloom filters and compression offsets Both bloom filters and compression offsets scale linearly with disk space (and can be much higher with various table specific settings), and are allocated in chunks during compaction. It's very likely you're seeing a compaction start, and the bloom filter allocation triggers the Pom-killer How much ram is in the system? How big is the heap? How much data is on each node? > Cassandra 3.10 crashes without dump > --- > > Key: CASSANDRA-13663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13663 > Project: Cassandra > Issue Type: Bug >Reporter: Matthias Otto >Priority: Minor > Attachments: 2017-07-04 10_48_34-CloudWatch Management Console.png, > cassandra debug.log, cassandra system.log, RamUsageExamle1.png, > RamUsageExample2.png > > > Hello. My company runs a 5 node Cassandra cluster. For the last few weeks, we > have had a sporadic issue where one of the servers crashes without creating a > dump file and without any error messages in the logs. If one restarts the > service (which we have by now scripted to happen automatically), the servers > resumes work with no complaint. > Log files of the time of the last crash are attached, thou again they do not > log any crash happening. > Regarding out setup, we are running these servers on AMazon AWS, with 3 > volumes per server, one for the system, one for data and one for the > commitlog. When a crash happens, we can observe a sudden spike of read > activity on the commitlog volume. All of these have ample free space. > Aspecially the system volume has more then enough free space so that a dump > could be written. > The servers are Ubuntu 16.04 servers and Cassandra is installed from the > apt-get packet for version 3.10. > It is worth noting that these crashes happen more often when nodetool is > running either repair job or a backup job, but this is by no means always the > case. As for frequency, we have had about 1-2 crashes per week for the last > month. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9375) setting timeouts to 1ms prevents startup
[
https://issues.apache.org/jira/browse/CASSANDRA-9375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16115886#comment-16115886
]
Jeff Jirsa commented on CASSANDRA-9375:
---
Dispatching this check from the yaml configuration loader seems like a
suboptimal choice - we could do it from {{DatabaseDescriptor}} or
{{StartupChecks}}, that way we wouldn't have to worry about anyone who happens
to use one of the other implementations of {{ConfigurationLoader}}
> setting timeouts to 1ms prevents startup
>
>
> Key: CASSANDRA-9375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9375
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Brandon Williams
>Assignee: Varun Barala
>Priority: Trivial
> Labels: patch
> Fix For: 2.1.x
>
> Attachments: CASSANDRA-9375_after_review, CASSANDRA-9375.patch
>
>
> Granted, this is a nonsensical setting, but the error message makes it tough
> to discern what's wrong:
> {noformat}
> ERROR 17:13:28,726 Exception encountered during startup
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:310)
> at
> org.apache.cassandra.service.StorageService.(StorageService.java:233)
> at
> org.apache.cassandra.service.StorageService.(StorageService.java:141)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.(DynamicEndpointSnitch.java:87)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.(DynamicEndpointSnitch.java:63)
> at
> org.apache.cassandra.config.DatabaseDescriptor.createEndpointSnitch(DatabaseDescriptor.java:518)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:350)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:112)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:213)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:656)
> Caused by: java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:586)
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor.scheduleWithFixedDelay(DebuggableScheduledThreadPoolExecutor.java:64)
> at org.apache.cassandra.utils.ExpiringMap.(ExpiringMap.java:103)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:360)
> at org.apache.cassandra.net.MessagingService.(MessagingService.java:68)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:306)
> ... 11 more
> java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.net.MessagingService.instance(MessagingService.java:310)
> at
> org.apache.cassandra.service.StorageService.(StorageService.java:233)
> at
> org.apache.cassandra.service.StorageService.(StorageService.java:141)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.(DynamicEndpointSnitch.java:87)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.(DynamicEndpointSnitch.java:63)
> at
> org.apache.cassandra.config.DatabaseDescriptor.createEndpointSnitch(DatabaseDescriptor.java:518)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyConfig(DatabaseDescriptor.java:350)
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:112)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:213)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:656)
> Caused by: java.lang.IllegalArgumentException
> at
> java.util.concurrent.ScheduledThreadPoolExecutor.scheduleWithFixedDelay(ScheduledThreadPoolExecutor.java:586)
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor.scheduleWithFixedDelay(DebuggableScheduledThreadPoolExecutor.java:64)
> at org.apache.cassandra.utils.ExpiringMap.(ExpiringMap.java:103)
> at
> org.apache.cassandra.net.MessagingService.(MessagingService.java:360)
> at org.apache.cassandra.net.MessagingService.(MessagingService.java:68)
> at
> org.apache.cassandra.net.MessagingService$MSHandle.(MessagingService.java:306)
> ... 11 more
> Exception encountered during startup: null
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117297#comment-16117297
]
Jeff Jirsa commented on CASSANDRA-10786:
We shouldn't be committing anything into the database that relies on a
{{-SNAPSHOT}} of a third party library.
> Include hash of result set metadata in prepared statement id
>
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 4.x
>
>
> *_Initial description:_*
> This is a follow-up to CASSANDRA-7910, which was about invalidating a
> prepared statement when the table is altered, to force clients to update
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host.
> The first client to execute the query after the cache was invalidated will
> receive an UNPREPARED response, re-prepare, and update its local metadata.
> But other clients might miss it entirely (the MD5 hasn't changed), and they
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123,
> clientA and clientB both have a cache of the metadata (columns b and c)
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response,
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been
> populated again, the query succeeds. But clientB still has not updated its
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set
> metadata in the md5. This way the md5 would change at step 3, and any client
> using the old md5 would get an UNPREPARED, regardless of whether another
> client already reprepared.
> -
> *_Resolution (2017/02/13):_*
> The following changes were made to native protocol v5:
> - the PREPARED response includes {{result_metadata_id}}, a hash of the result
> set metadata.
> - every EXECUTE message must provide {{result_metadata_id}} in addition to
> the prepared statement id. If it doesn't match the current one on the server,
> it means the client is operating on a stale schema.
> - to notify the client, the server returns a ROWS response with a new
> {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated
> result metadata (this overrides the {{No_metadata}} flag, even if the client
> had requested it)
> - the client updates its copy of the result metadata before it decodes the
> results.
> So the scenario above would now look like:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and
> result set (b, c) that hashes to cde456
> # column a gets added to the table, C* does not invalidate its cache entry,
> but only updates the result set to (a, b, c) which hashes to fff789
> # client sends an EXECUTE request for (statementId=abc123, resultId=cde456)
> and skip_metadata flag
> # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false,
> metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c))
> # client updates its column specifications, and will send the next execute
> queries with (statementId=abc123, resultId=fff789)
> This works the same with multiple clients.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117297#comment-16117297
]
Jeff Jirsa edited comment on CASSANDRA-10786 at 8/7/17 9:10 PM:
We shouldn't be committing anything into the database that relies on a
{{-SNAPSHOT}} of a third party library.
I'm hard (binding) -1 on any patch that does so. It's one thing to rely on
third party drivers, it's quite a different thing to rely on a SNAPSHOT build.
was (Author: jjirsa):
We shouldn't be committing anything into the database that relies on a
{{-SNAPSHOT}} of a third party library.
> Include hash of result set metadata in prepared statement id
>
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 4.x
>
>
> *_Initial description:_*
> This is a follow-up to CASSANDRA-7910, which was about invalidating a
> prepared statement when the table is altered, to force clients to update
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host.
> The first client to execute the query after the cache was invalidated will
> receive an UNPREPARED response, re-prepare, and update its local metadata.
> But other clients might miss it entirely (the MD5 hasn't changed), and they
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123,
> clientA and clientB both have a cache of the metadata (columns b and c)
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response,
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been
> populated again, the query succeeds. But clientB still has not updated its
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set
> metadata in the md5. This way the md5 would change at step 3, and any client
> using the old md5 would get an UNPREPARED, regardless of whether another
> client already reprepared.
> -
> *_Resolution (2017/02/13):_*
> The following changes were made to native protocol v5:
> - the PREPARED response includes {{result_metadata_id}}, a hash of the result
> set metadata.
> - every EXECUTE message must provide {{result_metadata_id}} in addition to
> the prepared statement id. If it doesn't match the current one on the server,
> it means the client is operating on a stale schema.
> - to notify the client, the server returns a ROWS response with a new
> {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated
> result metadata (this overrides the {{No_metadata}} flag, even if the client
> had requested it)
> - the client updates its copy of the result metadata before it decodes the
> results.
> So the scenario above would now look like:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and
> result set (b, c) that hashes to cde456
> # column a gets added to the table, C* does not invalidate its cache entry,
> but only updates the result set to (a, b, c) which hashes to fff789
> # client sends an EXECUTE request for (statementId=abc123, resultId=cde456)
> and skip_metadata flag
> # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false,
> metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c))
> # client updates its column specifications, and will send the next execute
> queries with (statementId=abc123, resultId=fff789)
> This works the same with multiple clients.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-10786:
---
Status: In Progress (was: Ready to Commit)
> Include hash of result set metadata in prepared statement id
>
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 4.x
>
>
> *_Initial description:_*
> This is a follow-up to CASSANDRA-7910, which was about invalidating a
> prepared statement when the table is altered, to force clients to update
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host.
> The first client to execute the query after the cache was invalidated will
> receive an UNPREPARED response, re-prepare, and update its local metadata.
> But other clients might miss it entirely (the MD5 hasn't changed), and they
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123,
> clientA and clientB both have a cache of the metadata (columns b and c)
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response,
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been
> populated again, the query succeeds. But clientB still has not updated its
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set
> metadata in the md5. This way the md5 would change at step 3, and any client
> using the old md5 would get an UNPREPARED, regardless of whether another
> client already reprepared.
> -
> *_Resolution (2017/02/13):_*
> The following changes were made to native protocol v5:
> - the PREPARED response includes {{result_metadata_id}}, a hash of the result
> set metadata.
> - every EXECUTE message must provide {{result_metadata_id}} in addition to
> the prepared statement id. If it doesn't match the current one on the server,
> it means the client is operating on a stale schema.
> - to notify the client, the server returns a ROWS response with a new
> {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated
> result metadata (this overrides the {{No_metadata}} flag, even if the client
> had requested it)
> - the client updates its copy of the result metadata before it decodes the
> results.
> So the scenario above would now look like:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and
> result set (b, c) that hashes to cde456
> # column a gets added to the table, C* does not invalidate its cache entry,
> but only updates the result set to (a, b, c) which hashes to fff789
> # client sends an EXECUTE request for (statementId=abc123, resultId=cde456)
> and skip_metadata flag
> # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false,
> metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c))
> # client updates its column specifications, and will send the next execute
> queries with (statementId=abc123, resultId=fff789)
> This works the same with multiple clients.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117297#comment-16117297
]
Jeff Jirsa edited comment on CASSANDRA-10786 at 8/7/17 9:56 PM:
We shouldn't be committing anything into the database that relies on a
{{-SNAPSHOT}} of a third party library.
-I'm hard (binding)- -1- -on any patch that does so. It's one thing to rely on
third party drivers, it's quite a different thing to rely on a SNAPSHOT build.-
Please open an open "blocker" JIRA with fixver=4.0 to make sure this gets
reverted before release.
was (Author: jjirsa):
We shouldn't be committing anything into the database that relies on a
{{-SNAPSHOT}} of a third party library.
I'm hard (binding) -1 on any patch that does so. It's one thing to rely on
third party drivers, it's quite a different thing to rely on a SNAPSHOT build.
> Include hash of result set metadata in prepared statement id
>
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 4.x
>
>
> *_Initial description:_*
> This is a follow-up to CASSANDRA-7910, which was about invalidating a
> prepared statement when the table is altered, to force clients to update
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host.
> The first client to execute the query after the cache was invalidated will
> receive an UNPREPARED response, re-prepare, and update its local metadata.
> But other clients might miss it entirely (the MD5 hasn't changed), and they
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123,
> clientA and clientB both have a cache of the metadata (columns b and c)
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response,
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been
> populated again, the query succeeds. But clientB still has not updated its
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set
> metadata in the md5. This way the md5 would change at step 3, and any client
> using the old md5 would get an UNPREPARED, regardless of whether another
> client already reprepared.
> -
> *_Resolution (2017/02/13):_*
> The following changes were made to native protocol v5:
> - the PREPARED response includes {{result_metadata_id}}, a hash of the result
> set metadata.
> - every EXECUTE message must provide {{result_metadata_id}} in addition to
> the prepared statement id. If it doesn't match the current one on the server,
> it means the client is operating on a stale schema.
> - to notify the client, the server returns a ROWS response with a new
> {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated
> result metadata (this overrides the {{No_metadata}} flag, even if the client
> had requested it)
> - the client updates its copy of the result metadata before it decodes the
> results.
> So the scenario above would now look like:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and
> result set (b, c) that hashes to cde456
> # column a gets added to the table, C* does not invalidate its cache entry,
> but only updates the result set to (a, b, c) which hashes to fff789
> # client sends an EXECUTE request for (statementId=abc123, resultId=cde456)
> and skip_metadata flag
> # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false,
> metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c))
> # client updates its column specifications, and will send the next execute
> queries with (statementId=abc123, resultId=fff789)
> This works the same with multiple clients.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id
[
https://issues.apache.org/jira/browse/CASSANDRA-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117437#comment-16117437
]
Jeff Jirsa commented on CASSANDRA-10786:
Yep, I already struck out my hard objection when [~iamaleksey] noted that
there's precedent for it. Let the snapshot go in, but we should make sure we
get up to a hard release version before we cut 4.0 proper.
> Include hash of result set metadata in prepared statement id
>
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
> Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 4.x
>
>
> *_Initial description:_*
> This is a follow-up to CASSANDRA-7910, which was about invalidating a
> prepared statement when the table is altered, to force clients to update
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host.
> The first client to execute the query after the cache was invalidated will
> receive an UNPREPARED response, re-prepare, and update its local metadata.
> But other clients might miss it entirely (the MD5 hasn't changed), and they
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123,
> clientA and clientB both have a cache of the metadata (columns b and c)
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response,
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been
> populated again, the query succeeds. But clientB still has not updated its
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set
> metadata in the md5. This way the md5 would change at step 3, and any client
> using the old md5 would get an UNPREPARED, regardless of whether another
> client already reprepared.
> -
> *_Resolution (2017/02/13):_*
> The following changes were made to native protocol v5:
> - the PREPARED response includes {{result_metadata_id}}, a hash of the result
> set metadata.
> - every EXECUTE message must provide {{result_metadata_id}} in addition to
> the prepared statement id. If it doesn't match the current one on the server,
> it means the client is operating on a stale schema.
> - to notify the client, the server returns a ROWS response with a new
> {{Metadata_changed}} flag, the new {{result_metadata_id}} and the updated
> result metadata (this overrides the {{No_metadata}} flag, even if the client
> had requested it)
> - the client updates its copy of the result metadata before it decodes the
> results.
> So the scenario above would now look like:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, and
> result set (b, c) that hashes to cde456
> # column a gets added to the table, C* does not invalidate its cache entry,
> but only updates the result set to (a, b, c) which hashes to fff789
> # client sends an EXECUTE request for (statementId=abc123, resultId=cde456)
> and skip_metadata flag
> # cde456!=fff789, so C* responds with ROWS(..., no_metadata=false,
> metadata_changed=true, new_metadata_id=fff789,col specs for (a,b,c))
> # client updates its column specifications, and will send the next execute
> queries with (statementId=abc123, resultId=fff789)
> This works the same with multiple clients.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13733) nodetool toptables
[ https://issues.apache.org/jira/browse/CASSANDRA-13733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa reassigned CASSANDRA-13733: -- Assignee: Neil Patel > nodetool toptables > -- > > Key: CASSANDRA-13733 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13733 > Project: Cassandra > Issue Type: Improvement > Components: Metrics, Observability >Reporter: Jon Haddad >Assignee: Neil Patel > Labels: lhf, low-hanging-fruit > > In the same way toppartitions samples the activity on a table, toptables > should be able to report which tables are used the most. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13689) Update development docs with correct GH URL for new cassandra-dtest location
[ https://issues.apache.org/jira/browse/CASSANDRA-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13689: --- Status: Ready to Commit (was: Patch Available) > Update development docs with correct GH URL for new cassandra-dtest location > > > Key: CASSANDRA-13689 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13689 > Project: Cassandra > Issue Type: Sub-task > Components: Testing >Reporter: Nate McCall >Assignee: Roman Pogribnyi > Labels: docs-impacting, lhf > Attachments: 13689-3.11.txt > > > Specifically the URL on this page: > http://cassandra.apache.org/doc/latest/development/testing.html#dtests -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13689) Update development docs with correct GH URL for new cassandra-dtest location
[ https://issues.apache.org/jira/browse/CASSANDRA-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13689: --- Resolution: Fixed Reviewer: Jeff Jirsa Fix Version/s: 4.0 Status: Resolved (was: Ready to Commit) Committed to trunk as [6b302b600f327cc8d1781776423d9548658e6591|https://github.com/apache/cassandra/commit/6b302b600f327cc8d1781776423d9548658e6591] , thanks! (It'll take a while for the site to be rebuilt, but it's committed) > Update development docs with correct GH URL for new cassandra-dtest location > > > Key: CASSANDRA-13689 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13689 > Project: Cassandra > Issue Type: Sub-task > Components: Testing >Reporter: Nate McCall >Assignee: Roman Pogribnyi > Labels: docs-impacting, lhf > Fix For: 4.0 > > Attachments: 13689-3.11.txt > > > Specifically the URL on this page: > http://cassandra.apache.org/doc/latest/development/testing.html#dtests -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13683) sstabledump should not use tool initialization
[
https://issues.apache.org/jira/browse/CASSANDRA-13683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13683:
---
Resolution: Fixed
Fix Version/s: 4.0
Status: Resolved (was: Ready to Commit)
Thanks to both of you. Committed as {{9e3483f844d9db6fe2a6210550622fc2cd8aef72}}
> sstabledump should not use tool initialization
> --
>
> Key: CASSANDRA-13683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13683
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
> Fix For: 4.0
>
>
> The tool initialization is not necessary for the sstabledump utility and by
> using it we possibly introduce a unnecessary requirement of being on the same
> C* instance (since we may introduce changes that require it, UDT changes can
> lead to dangerous assumptions) that has the schema. This also does things
> like introduce possibly devastating issues from having the same
> commitlog/sstable locations.
> A good example is updating the sstable activity table, and having that
> flushed to commitlogs as an application outside the running C* service. This
> may not be on same user (ie root) which than when a postmemtable flusher
> after restart attempts to delete it will throw an exception and potentially
> kill that thread pool. One that happens commitlogs will cease to get recycled
> and will just burn disk space until we run out.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-12435) Cassandra timeout when using secondary index in cluster mode.
[
https://issues.apache.org/jira/browse/CASSANDRA-12435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa resolved CASSANDRA-12435.
Resolution: Duplicate
Apparently a dupe of CASSANDRA-13363 , which has a patch-available (though not
reviewed/tested).
> Cassandra timeout when using secondary index in cluster mode.
> -
>
> Key: CASSANDRA-12435
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12435
> Project: Cassandra
> Issue Type: Bug
> Components: Secondary Indexes
> Environment: C* 3.5 | java-driver|AWS g2.2xlarge|ubuntu 14.04
>Reporter: Shijian Liu
> Fix For: 3.11.x
>
>
> I have a 3-node cluster with a keyspace with RF=3, then I created a table
> like below and inserted some data(about 10MB).
> {code}
> CREATE TABLE vehicle_fuzzy_plate (
> day int,
> hour int,
> repo int,
> sensor_id int,
> ts timestamp,
> id timeuuid,
> plate_text_pattern_70 text,
> plate_text_pattern_10 text,
> plate_text_pattern_11 text,
> plate_text_pattern_12 text,
> plate_text_pattern_13 text,
> plate_text_pattern_14 text,
> plate_text_pattern_15 text,
> plate_text_pattern_16 text,
> plate_text_pattern_20 text,
> plate_text_pattern_21 text,
> plate_text_pattern_22 text,
> plate_text_pattern_23 text,
> plate_text_pattern_24 text,
> plate_text_pattern_25 text,
> plate_text_pattern_30 text,
> plate_text_pattern_31 text,
> plate_text_pattern_32 text,
> plate_text_pattern_33 text,
> plate_text_pattern_34 text,
> plate_text_pattern_40 text,
> plate_text_pattern_41 text,
> plate_text_pattern_42 text,
> plate_text_pattern_43 text,
> plate_text_pattern_50 text,
> plate_text_pattern_51 text,
> plate_text_pattern_52 text,
> plate_text_pattern_60 text,
> plate_text_pattern_61 text,
> PRIMARY KEY (day, repo, sensor_id, ts, id)
> ) WITH CLUSTERING ORDER BY (repo ASC, sensor_id ASC, ts ASC, id ASC);
> CREATE INDEX plate_text_pattern_10_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_10);
> CREATE INDEX plate_text_pattern_11_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_11);
> CREATE INDEX plate_text_pattern_12_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_12);
> CREATE INDEX plate_text_pattern_13_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_13);
> CREATE INDEX plate_text_pattern_14_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_14);
> CREATE INDEX plate_text_pattern_15_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_15);
> CREATE INDEX plate_text_pattern_16_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_16);
> CREATE INDEX plate_text_pattern_20_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_20);
> CREATE INDEX plate_text_pattern_21_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_21);
> CREATE INDEX plate_text_pattern_22_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_22);
> CREATE INDEX plate_text_pattern_23_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_23);
> CREATE INDEX plate_text_pattern_24_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_24);
> CREATE INDEX plate_text_pattern_25_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_25);
> CREATE INDEX plate_text_pattern_30_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_30);
> CREATE INDEX plate_text_pattern_31_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_31);
> CREATE INDEX plate_text_pattern_32_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_32);
> CREATE INDEX plate_text_pattern_33_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_33);
> CREATE INDEX plate_text_pattern_34_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_34);
> CREATE INDEX plate_text_pattern_40_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_40);
> CREATE INDEX plate_text_pattern_41_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_41);
> CREATE INDEX plate_text_pattern_42_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_42);
> CREATE INDEX plate_text_pattern_43_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_43);
> CREATE INDEX plate_text_pattern_50_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_50);
> CREATE INDEX plate_text_pattern_51_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_51);
> CREATE INDEX plate_text_pattern_52_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_52);
> CREATE INDEX plate_text_pattern_60_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_60);
> CREATE INDEX plate_text_pattern_61_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_61);
> CREATE INDEX plate_text_pattern_70_idx ON vehicle_fuzzy_plate
> (plate_text_pattern_70);
> {code}
> After that, I send some queries through Java driver with Consistency=Quorum
> one by one, for example,
> {code}
> SELECT id,sensor_id,ts FROM vehicle_fuzzy_plate WHERE day IN
> (16993,16994,16995,16996,16997,16998,16999,17000,17001,17002
[jira] [Assigned] (CASSANDRA-13363) java.lang.ArrayIndexOutOfBoundsException: null
[
https://issues.apache.org/jira/browse/CASSANDRA-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa reassigned CASSANDRA-13363:
--
Assignee: zhaoyan
> java.lang.ArrayIndexOutOfBoundsException: null
> --
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>Assignee: zhaoyan
>Priority: Critical
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Constantly see this error in the log without any additional information or a
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13363) java.lang.ArrayIndexOutOfBoundsException: null
[
https://issues.apache.org/jira/browse/CASSANDRA-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13363:
---
Fix Version/s: 4.x
3.11.x
3.0.x
> java.lang.ArrayIndexOutOfBoundsException: null
> --
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>Priority: Critical
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Constantly see this error in the log without any additional information or a
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13363) java.lang.ArrayIndexOutOfBoundsException: null
[
https://issues.apache.org/jira/browse/CASSANDRA-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13363:
---
Status: Patch Available (was: Open)
Marking patch available
> java.lang.ArrayIndexOutOfBoundsException: null
> --
>
> Key: CASSANDRA-13363
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13363
> Project: Cassandra
> Issue Type: Bug
> Environment: CentOS 6, Cassandra 3.10
>Reporter: Artem Rokhin
>Assignee: zhaoyan
>Priority: Critical
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Constantly see this error in the log without any additional information or a
> stack trace.
> {code}
> Exception in thread Thread[MessagingService-Incoming-/10.0.1.26,5,main]
> {code}
> {code}
> java.lang.ArrayIndexOutOfBoundsException: null
> {code}
> Logger: org.apache.cassandra.service.CassandraDaemon
> Thrdead: MessagingService-Incoming-/10.0.1.12
> Method: uncaughtException
> File: CassandraDaemon.java
> Line: 229
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13615) Include 'ppc64le' library for sigar-1.6.4.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13615: --- Status: Ready to Commit (was: Patch Available) > Include 'ppc64le' library for sigar-1.6.4.jar > - > > Key: CASSANDRA-13615 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13615 > Project: Cassandra > Issue Type: Improvement > Components: Libraries > Environment: # arch > ppc64le >Reporter: Amitkumar Ghatwal >Assignee: Michael Shuler > Labels: easyfix > Fix For: 3.0.x, 3.11.x, 4.x > > Attachments: libsigar-ppc64le-linux.so > > > Hi All, > sigar-1.6.4.jar does not include a ppc64le library, so we had to install > libsigar-ppc64le-linux.so.As the community has been inactive for long > (https://github.com/hyperic/sigar), requesting the community to include the > ppc64le library directly here. > Attaching the ppc64le library ( *.so) file to be included under > "/lib/sigar-bin". let me know of issues/dependency if any. > FYI - [~ReiOdaira],[~jjirsa], [~mshuler] > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13615) Include 'ppc64le' library for sigar-1.6.4.jar
[
https://issues.apache.org/jira/browse/CASSANDRA-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120685#comment-16120685
]
Jeff Jirsa commented on CASSANDRA-13615:
+1 for {{libsigar-ppc64le-linux.so}} with hash
{{f00a2dc54f7f163ce1dbfa3268e4452a}} , thanks for following up on that infra
ticket [~mshuler]
> Include 'ppc64le' library for sigar-1.6.4.jar
> -
>
> Key: CASSANDRA-13615
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13615
> Project: Cassandra
> Issue Type: Improvement
> Components: Libraries
> Environment: # arch
> ppc64le
>Reporter: Amitkumar Ghatwal
>Assignee: Michael Shuler
> Labels: easyfix
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: libsigar-ppc64le-linux.so
>
>
> Hi All,
> sigar-1.6.4.jar does not include a ppc64le library, so we had to install
> libsigar-ppc64le-linux.so.As the community has been inactive for long
> (https://github.com/hyperic/sigar), requesting the community to include the
> ppc64le library directly here.
> Attaching the ppc64le library ( *.so) file to be included under
> "/lib/sigar-bin". let me know of issues/dependency if any.
> FYI - [~ReiOdaira],[~jjirsa], [~mshuler]
> Regards,
> Amit
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order
[
https://issues.apache.org/jira/browse/CASSANDRA-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa reassigned CASSANDRA-13717:
--
Assignee: Stavros Kontopoulos
> INSERT statement fails when Tuple type is used as clustering column with
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
> Attachments: example_queries.cql
>
>
> When a column family is created and a Tuple is used on clustering column with
> default clustering order DESC, then the INSERT statement fails.
> For example, the following table will make the INSERT statement fail with
> error message "Invalid tuple type literal for tdemo of type
> frozen>" , although the INSERT statement is correct
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
> id int,
> tdemo tuple,
> primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order
[
https://issues.apache.org/jira/browse/CASSANDRA-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13717:
---
Status: Patch Available (was: Open)
> INSERT statement fails when Tuple type is used as clustering column with
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
> Attachments: example_queries.cql
>
>
> When a column family is created and a Tuple is used on clustering column with
> default clustering order DESC, then the INSERT statement fails.
> For example, the following table will make the INSERT statement fail with
> error message "Invalid tuple type literal for tdemo of type
> frozen>" , although the INSERT statement is correct
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
> id int,
> tdemo tuple,
> primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order
[
https://issues.apache.org/jira/browse/CASSANDRA-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13717:
---
Attachment: fix_13717
> INSERT statement fails when Tuple type is used as clustering column with
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
> Attachments: example_queries.cql, fix_13717
>
>
> When a column family is created and a Tuple is used on clustering column with
> default clustering order DESC, then the INSERT statement fails.
> For example, the following table will make the INSERT statement fail with
> error message "Invalid tuple type literal for tdemo of type
> frozen>" , although the INSERT statement is correct
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
> id int,
> tdemo tuple,
> primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order
[
https://issues.apache.org/jira/browse/CASSANDRA-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120932#comment-16120932
]
Jeff Jirsa commented on CASSANDRA-13717:
Welcome [~skonto] ! Next step would be to assign yourself (I've done that for
you), and then hit 'submit patch' to mark the issue as patch available (I've
done that for you again).
We typically ask either the contributor (you) or the reviewer (someone who will
volunteer, hopefully soon) to push the patch to a github branch and kick off CI
(we have it setup to use circleci for unit tests, and a committer can kick off
dtests). We typically ask that your patch includes a test case that fails
before your patch and succeeds after it's applied, so while this is not a
review, I will say that any reviewer should ask you to do that.
> INSERT statement fails when Tuple type is used as clustering column with
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
> Attachments: example_queries.cql, fix_13717
>
>
> When a column family is created and a Tuple is used on clustering column with
> default clustering order DESC, then the INSERT statement fails.
> For example, the following table will make the INSERT statement fail with
> error message "Invalid tuple type literal for tdemo of type
> frozen>" , although the INSERT statement is correct
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
> id int,
> tdemo tuple,
> primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order
[
https://issues.apache.org/jira/browse/CASSANDRA-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13717:
---
Priority: Critical (was: Major)
> INSERT statement fails when Tuple type is used as clustering column with
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
>Priority: Critical
> Attachments: example_queries.cql, fix_13717
>
>
> When a column family is created and a Tuple is used on clustering column with
> default clustering order DESC, then the INSERT statement fails.
> For example, the following table will make the INSERT statement fail with
> error message "Invalid tuple type literal for tdemo of type
> frozen>" , although the INSERT statement is correct
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
> id int,
> tdemo tuple,
> primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order
[
https://issues.apache.org/jira/browse/CASSANDRA-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120965#comment-16120965
]
Jeff Jirsa commented on CASSANDRA-13717:
I typically prefer keeping them in unit tests (junit tests in the same repo,
check out the test/ directory). There should be a section for cql3 tests, and
almost certainly a TupleTest within it that you can add a function or two to.
> INSERT statement fails when Tuple type is used as clustering column with
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
>Priority: Critical
> Attachments: example_queries.cql, fix_13717
>
>
> When a column family is created and a Tuple is used on clustering column with
> default clustering order DESC, then the INSERT statement fails.
> For example, the following table will make the INSERT statement fail with
> error message "Invalid tuple type literal for tdemo of type
> frozen>" , although the INSERT statement is correct
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
> id int,
> tdemo tuple,
> primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13717) INSERT statement fails when Tuple type is used as clustering column with default DESC order
[
https://issues.apache.org/jira/browse/CASSANDRA-13717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16121048#comment-16121048
]
Jeff Jirsa commented on CASSANDRA-13717:
[~skonto] - do you know which versions need to be fixed? 3.0? 3.11? trunk?
I've kicked off some test builds [here (unit
tests)|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13717] and
[here
(dtest)|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/173]
- we'll want to do that for each branch that needs this fix (and of course,
we'll want to add tests to this fix as well).
> INSERT statement fails when Tuple type is used as clustering column with
> default DESC order
> ---
>
> Key: CASSANDRA-13717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13717
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.11
>Reporter: Anastasios Kichidis
>Assignee: Stavros Kontopoulos
>Priority: Critical
> Attachments: example_queries.cql, fix_13717
>
>
> When a column family is created and a Tuple is used on clustering column with
> default clustering order DESC, then the INSERT statement fails.
> For example, the following table will make the INSERT statement fail with
> error message "Invalid tuple type literal for tdemo of type
> frozen>" , although the INSERT statement is correct
> (works as expected when the default order is ASC)
> {noformat}
> create table test_table (
> id int,
> tdemo tuple,
> primary key (id, tdemo)
> ) with clustering order by (tdemo desc);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13754) FastThreadLocal leaks memory
[
https://issues.apache.org/jira/browse/CASSANDRA-13754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122012#comment-16122012
]
Jeff Jirsa commented on CASSANDRA-13754:
What version are you on [~urandom] (or really, which version of netty is in the
classpath) ?
> FastThreadLocal leaks memory
>
>
> Key: CASSANDRA-13754
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13754
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: OpenJDK 8u141-b15
>Reporter: Eric Evans
> Fix For: 3.11.1
>
>
> After a chronic bout of {{OutOfMemoryError}} in our development environment,
> a heap analysis is showing that more than 10G of our 12G heaps are consumed
> by the {{threadLocals}} members (instances of {{java.lang.ThreadLocalMap}})
> of various {{io.netty.util.concurrent.FastThreadLocalThread}} instances.
> Reverting
> [cecbe17|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=cecbe17e3eafc052acc13950494f7dddf026aa54]
> fixes the issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13752) Corrupted SSTables created in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-13752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122020#comment-16122020
]
Jeff Jirsa commented on CASSANDRA-13752:
Any additional context you can provide - how old is the cluster? Have you
changed anything recently? When did you upgrade to 3.11.0? How long before you
saw those errors? Do you run repairs? Incremental repairs or full? Anything
else in the logs that looks atypical?
> Corrupted SSTables created in 3.11
> --
>
> Key: CASSANDRA-13752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13752
> Project: Cassandra
> Issue Type: Bug
>Reporter: Hannu Kröger
>Priority: Blocker
>
> We have discovered issues with corrupted SSTables.
> {code}
> ERROR [SSTableBatchOpen:22] 2017-08-03 20:19:53,195 SSTableReader.java:577 -
> Cannot read sstable
> /cassandra/data/mykeyspace/mytable-7a4992800d5611e7b782cb90016f2d17/mc-35556-big=[Data.db,
> Statistics.db, Summary.db, Digest.crc32, CompressionInfo.db, TOC.txt,
> Index.db, Filter.db]; other IO error, skipping table
> java.io.EOFException: EOF after 1898 bytes out of 21093
> at
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:68)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.io.util.RebufferingInputStream.readFully(RebufferingInputStream.java:60)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:402)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:377)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:325)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.io.sstable.metadata.StatsMetadata$StatsMetadataSerializer.deserialize(StatsMetadata.java:231)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:122)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:93)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:488)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:396)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> org.apache.cassandra.io.sstable.format.SSTableReader$5.run(SSTableReader.java:561)
> ~[apache-cassandra-3.11.0.jar:3.11.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [na:1.8.0_111]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_111]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_111]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> [apache-cassandra-3.11.0.jar:3.11.0]
> {code}
> Files look like this:
> {code}
> -rw-r--r--. 1 cassandra cassandra 3899251 Aug 7 08:37
> mc-6166-big-CompressionInfo.db
> -rw-r--r--. 1 cassandra cassandra 16874421686 Aug 7 08:37 mc-6166-big-Data.db
> -rw-r--r--. 1 cassandra cassandra 10 Aug 7 08:37
> mc-6166-big-Digest.crc32
> -rw-r--r--. 1 cassandra cassandra 2930904 Aug 7 08:37
> mc-6166-big-Filter.db
> -rw-r--r--. 1 cassandra cassandra 75880 Aug 7 08:37
> mc-6166-big-Index.db
> -rw-r--r--. 1 cassandra cassandra 13762 Aug 7 08:37
> mc-6166-big-Statistics.db
> -rw-r--r--. 1 cassandra cassandra 882008 Aug 7 08:37
> mc-6166-big-Summary.db
> -rw-r--r--. 1 cassandra cassandra 92 Aug 7 08:37 mc-6166-big-TOC.txt
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12884) Batch logic can lead to unbalanced use of system.batches
[
https://issues.apache.org/jira/browse/CASSANDRA-12884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1614#comment-1614
]
Jeff Jirsa commented on CASSANDRA-12884:
[~iamaleksey] will have a more comprehensive review, I'm sure, but a few notes
from a very cursory glance:
1) I don't see the purpose of stubbing out {{BatchlogManager::shuffle}} as a
helper function here.
2) In the case where {{validated.keySet().size() == 1}} , shuffling all of the
IPs in a given rack may not be all that efficient - may be quicker to just pick
2 random ints, and grab the IPs at those offsets (like we do for the case where
we have more than 2 racks,
{{result.add(rackMembers.get(getRandomInt(rackMembers.size(;}} )
> Batch logic can lead to unbalanced use of system.batches
>
>
> Key: CASSANDRA-12884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12884
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Adam Hattrell
>Assignee: Daniel Cranford
> Fix For: 3.0.x, 3.11.x
>
> Attachments: 0001-CASSANDRA-12884.patch
>
>
> It looks as though there are some odd edge cases in how we distribute the
> copies in system.batches.
> The main issue is in the filter method for
> org.apache.cassandra.batchlog.BatchlogManager
> {code:java}
> if (validated.size() - validated.get(localRack).size() >= 2)
> {
> // we have enough endpoints in other racks
> validated.removeAll(localRack);
> }
> if (validated.keySet().size() == 1)
> {
>// we have only 1 `other` rack
>Collection otherRack =
> Iterables.getOnlyElement(validated.asMap().values());
>
> return Lists.newArrayList(Iterables.limit(otherRack, 2));
> }
> {code}
> So with one or two racks we just return the first 2 entries in the list.
> There's no shuffle or randomisation here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12884) Batch logic can lead to unbalanced use of system.batches
[
https://issues.apache.org/jira/browse/CASSANDRA-12884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1614#comment-1614
]
Jeff Jirsa edited comment on CASSANDRA-12884 at 8/10/17 8:34 PM:
-
[~iamaleksey] will have a more comprehensive review, I'm sure, but a few notes
from a very cursory glance:
-1) I don't see the purpose of stubbing out {{BatchlogManager::shuffle}} as a
helper function here.- (You're overriding it for deterministic testing)
2) In the case where {{validated.keySet().size() == 1}} , shuffling all of the
IPs in a given rack may not be all that efficient - may be quicker to just pick
2 random ints, and grab the IPs at those offsets (like we do for the case where
we have more than 2 racks,
{{result.add(rackMembers.get(getRandomInt(rackMembers.size(;}} )
was (Author: jjirsa):
[~iamaleksey] will have a more comprehensive review, I'm sure, but a few notes
from a very cursory glance:
1) I don't see the purpose of stubbing out {{BatchlogManager::shuffle}} as a
helper function here.
2) In the case where {{validated.keySet().size() == 1}} , shuffling all of the
IPs in a given rack may not be all that efficient - may be quicker to just pick
2 random ints, and grab the IPs at those offsets (like we do for the case where
we have more than 2 racks,
{{result.add(rackMembers.get(getRandomInt(rackMembers.size(;}} )
> Batch logic can lead to unbalanced use of system.batches
>
>
> Key: CASSANDRA-12884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12884
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Adam Hattrell
>Assignee: Daniel Cranford
> Fix For: 3.0.x, 3.11.x
>
> Attachments: 0001-CASSANDRA-12884.patch
>
>
> It looks as though there are some odd edge cases in how we distribute the
> copies in system.batches.
> The main issue is in the filter method for
> org.apache.cassandra.batchlog.BatchlogManager
> {code:java}
> if (validated.size() - validated.get(localRack).size() >= 2)
> {
> // we have enough endpoints in other racks
> validated.removeAll(localRack);
> }
> if (validated.keySet().size() == 1)
> {
>// we have only 1 `other` rack
>Collection otherRack =
> Iterables.getOnlyElement(validated.asMap().values());
>
> return Lists.newArrayList(Iterables.limit(otherRack, 2));
> }
> {code}
> So with one or two racks we just return the first 2 entries in the list.
> There's no shuffle or randomisation here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13744) Better bootstrap failure message when blocked by (potential) range movement
[
https://issues.apache.org/jira/browse/CASSANDRA-13744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13744:
---
Reviewer: Jeff Jirsa
> Better bootstrap failure message when blocked by (potential) range movement
> ---
>
> Key: CASSANDRA-13744
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13744
> Project: Cassandra
> Issue Type: Bug
>Reporter: mck
>Assignee: mck
>Priority: Trivial
> Fix For: 3.11.x, 4.x
>
>
> The UnsupportedOperationException thrown from
> {{StorageService.joinTokenRing(..)}} when it's detected that other nodes are
> bootstrapping|leaving|moving offers no information as to which are those
> other nodes.
> In a large cluster this might not be obvious nor easy to discover, gossipinfo
> can hold information that takes a bit of effort to uncover. Even when it is
> easily seen it's helpful to have it confirmed.
> Attached is the patch that provides a more thorough exception message to the
> failed bootstrap attempt.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13744) Better bootstrap failure message when blocked by (potential) range movement
[
https://issues.apache.org/jira/browse/CASSANDRA-13744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122628#comment-16122628
]
Jeff Jirsa commented on CASSANDRA-13744:
I'll claim it, not only because I'm first, but because I'm not sure if Jason's
+1 carries through on the new tests.
> Better bootstrap failure message when blocked by (potential) range movement
> ---
>
> Key: CASSANDRA-13744
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13744
> Project: Cassandra
> Issue Type: Bug
>Reporter: mck
>Assignee: mck
>Priority: Trivial
> Fix For: 3.11.x, 4.x
>
>
> The UnsupportedOperationException thrown from
> {{StorageService.joinTokenRing(..)}} when it's detected that other nodes are
> bootstrapping|leaving|moving offers no information as to which are those
> other nodes.
> In a large cluster this might not be obvious nor easy to discover, gossipinfo
> can hold information that takes a bit of effort to uncover. Even when it is
> easily seen it's helpful to have it confirmed.
> Attached is the patch that provides a more thorough exception message to the
> failed bootstrap attempt.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13743) CAPTURE not easilly usable with PAGING
[ https://issues.apache.org/jira/browse/CASSANDRA-13743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa reassigned CASSANDRA-13743: -- Assignee: Corentin Chary > CAPTURE not easilly usable with PAGING > -- > > Key: CASSANDRA-13743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13743 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Corentin Chary >Assignee: Corentin Chary > Fix For: 4.x > > > See > https://github.com/iksaif/cassandra/commit/7ed56966a7150ced44c375af307685517d7e09a3 > for a patch fixing that. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13743) CAPTURE not easilly usable with PAGING
[ https://issues.apache.org/jira/browse/CASSANDRA-13743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13743: --- Status: Ready to Commit (was: Patch Available) > CAPTURE not easilly usable with PAGING > -- > > Key: CASSANDRA-13743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13743 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Corentin Chary >Assignee: Corentin Chary > Fix For: 4.x > > > See > https://github.com/iksaif/cassandra/commit/7ed56966a7150ced44c375af307685517d7e09a3 > for a patch fixing that. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13743) CAPTURE not easilly usable with PAGING
[
https://issues.apache.org/jira/browse/CASSANDRA-13743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13743:
---
Resolution: Fixed
Reviewer: Chris Lohfink
Fix Version/s: (was: 4.x)
4.0
Status: Resolved (was: Ready to Commit)
Thanks guys, committed as {{ed0243954f9ab9c5c68a4516a836ab3710891d5b}}
> CAPTURE not easilly usable with PAGING
> --
>
> Key: CASSANDRA-13743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13743
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Corentin Chary
>Assignee: Corentin Chary
> Fix For: 4.0
>
>
> See
> https://github.com/iksaif/cassandra/commit/7ed56966a7150ced44c375af307685517d7e09a3
> for a patch fixing that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13664) RangeFetchMapCalculator should not try to optimise 'trivial' ranges
[ https://issues.apache.org/jira/browse/CASSANDRA-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122640#comment-16122640 ] Jeff Jirsa commented on CASSANDRA-13664: This is marked ready to commit - is it good to go? That dtest run has already expired. > RangeFetchMapCalculator should not try to optimise 'trivial' ranges > --- > > Key: CASSANDRA-13664 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13664 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 4.x > > > RangeFetchMapCalculator (CASSANDRA-4650) tries to make the number of streams > out of each node as even as possible. > In a typical multi-dc ring the nodes in the dcs are setup using token + 1, > creating many tiny ranges. If we only try to optimise over the number of > streams, it is likely that the amount of data streamed out of each node is > unbalanced. > We should ignore those trivial ranges and only optimise the big ones, then > share the tiny ones over the nodes. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13532) sstabledump reports incorrect usage for argument order
[
https://issues.apache.org/jira/browse/CASSANDRA-13532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13532:
---
Resolution: Fixed
Fix Version/s: 4.0
3.11.1
3.0.15
Status: Resolved (was: Ready to Commit)
Thanks all! Committed as {{fab384560311ec1f3043fbf6137093ea129afa68}}
> sstabledump reports incorrect usage for argument order
> --
>
> Key: CASSANDRA-13532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13532
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Ian Ilsley
>Assignee: Varun Barala
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.15, 3.11.1, 4.0
>
> Attachments: sstabledump#printUsage.patch
>
>
> sstabledump usage reports
> {{usage: sstabledump }}
> However the actual usage is
> {{sstabledump }}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13655) Range deletes in a CAS batch are ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-13655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13655: --- Priority: Blocker (was: Critical) > Range deletes in a CAS batch are ignored > > > Key: CASSANDRA-13655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13655 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Blocker > Fix For: 3.0.x, 3.11.x, 4.x > > > Range deletes in a CAS batch are ignored -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13760) presize collections
[ https://issues.apache.org/jira/browse/CASSANDRA-13760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13760: --- Reviewer: Jeff Jirsa > presize collections > --- > > Key: CASSANDRA-13760 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13760 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 4.x > > Attachments: 13760.txt > > > presize collections where sane, to avoid reallocs, or excess garbage -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13760) presize collections
[ https://issues.apache.org/jira/browse/CASSANDRA-13760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13760: --- Status: Patch Available (was: Open) > presize collections > --- > > Key: CASSANDRA-13760 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13760 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 4.x > > Attachments: 13760.txt > > > presize collections where sane, to avoid reallocs, or excess garbage -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13760) presize collections
[ https://issues.apache.org/jira/browse/CASSANDRA-13760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124793#comment-16124793 ] Jeff Jirsa commented on CASSANDRA-13760: Pushing to CI while I review: [utest|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13760] [dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/179/] > presize collections > --- > > Key: CASSANDRA-13760 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13760 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 4.x > > Attachments: 13760.txt > > > presize collections where sane, to avoid reallocs, or excess garbage -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13759) remove collection creating on normal pending repair check
[ https://issues.apache.org/jira/browse/CASSANDRA-13759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13759: --- Reviewer: Jeff Jirsa Status: Patch Available (was: Open) Pushing to CI while I review: [utests|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-13759] [dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/180/] > remove collection creating on normal pending repair check > - > > Key: CASSANDRA-13759 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13759 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Dave Brosius >Assignee: Dave Brosius >Priority: Trivial > Fix For: 4.x > > Attachments: 13759.txt > > > in normal case where there's only 1 sstable for repair, don't build id > collection just used for error logging -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13759) remove collection creating on normal pending repair check
[
https://issues.apache.org/jira/browse/CASSANDRA-13759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124797#comment-16124797
]
Jeff Jirsa commented on CASSANDRA-13759:
I suspect you've dropped the {{if}} clause that checks for multiple ids among
the set of sstables, and I'm not sure we need to use a {{Set}} at all here.
Will push up a proposed change in the morning when I'm at a real laptop.
> remove collection creating on normal pending repair check
> -
>
> Key: CASSANDRA-13759
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13759
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Dave Brosius
>Assignee: Dave Brosius
>Priority: Trivial
> Fix For: 4.x
>
> Attachments: 13759.txt
>
>
> in normal case where there's only 1 sstable for repair, don't build id
> collection just used for error logging
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13745) Compaction History would be beneficial to include completion timestamp
[ https://issues.apache.org/jira/browse/CASSANDRA-13745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa reassigned CASSANDRA-13745: -- Assignee: Ihar Kukharchuk > Compaction History would be beneficial to include completion timestamp > --- > > Key: CASSANDRA-13745 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13745 > Project: Cassandra > Issue Type: Improvement > Components: Compaction, Core >Reporter: Richard Andersen >Assignee: Ihar Kukharchuk >Priority: Minor > Labels: lhf > Attachments: 13745-trunk.txt > > > Compaction history does not currently contain the completion time stamp which > can be beneficial in determining performance and event tracing. I would like > to use this information also in our Health Check process to trace event > timelines. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13741) Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127531#comment-16127531 ] Jeff Jirsa commented on CASSANDRA-13741: Folks, This is only going into 4.0, which is (at least) months away. Please be patient. It'll be reviewed when folks have bandwidth. > Replace Cassandra's lz4-1.3.0.jar with lz4-java-1.4.0.jar > - > > Key: CASSANDRA-13741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13741 > Project: Cassandra > Issue Type: Improvement > Components: Libraries >Reporter: Amitkumar Ghatwal >Assignee: Michael Kjellman > Fix For: 4.x > > > Hi All, > The latest lz4-java library has been released > (https://github.com/lz4/lz4-java/releases) and uploaded to maven central . > Please replace in mainline the current version ( 1.3.0) with the latest one ( > 1.4.0) from here - http://repo1.maven.org/maven2/org/lz4/lz4-java/1.4.0/ > Adding : [~ReiOdaira]. > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12676) Message coalescing regression
[ https://issues.apache.org/jira/browse/CASSANDRA-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-12676: --- Fix Version/s: (was: 3.0.12) > Message coalescing regression > - > > Key: CASSANDRA-12676 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12676 > Project: Cassandra > Issue Type: Bug >Reporter: T Jake Luciani >Assignee: Jeff Jirsa > Labels: docs-impacting > Fix For: 3.11.0, 4.0 > > Attachments: 12676.diff, coalescing_disabled.png, result.html > > > The default in 2.2+ was to enable TIMEHORIZON message coalescing. After > reports of performance regressions after upgrading from 2.1 to 2.2/3.0 we > have discovered the issue to be this default. > We need to re-test our assumptions on this feature but in the meantime we > should default back to disabled. > Here is a performance run [with and without message > coalescing|http://cstar.datastax.com/graph?command=one_job&stats=9a26b5f2-7f48-11e6-92e7-0256e416528f&metric=op_rate&operation=2_user&smoothing=1&show_aggregates=true&xmin=0&xmax=508.86&ymin=0&ymax=91223] > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13743) CAPTURE not easilly usable with PAGING
[ https://issues.apache.org/jira/browse/CASSANDRA-13743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131011#comment-16131011 ] Jeff Jirsa commented on CASSANDRA-13743: Thanks [~rgerard] - I've updated the [CHANGES log|https://github.com/apache/cassandra/commit/c0dc77ed4fa3b16558ce6f92c4ff076b890afc49] appropriately (but I'm not going to back out the commit to fix it there). - Jeff > CAPTURE not easilly usable with PAGING > -- > > Key: CASSANDRA-13743 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13743 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Corentin Chary >Assignee: Corentin Chary > Fix For: 4.0 > > > See > https://github.com/iksaif/cassandra/commit/7ed56966a7150ced44c375af307685517d7e09a3 > for a patch fixing that. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-12390) Make SASI work with partitioners that have variable-size tokens
[ https://issues.apache.org/jira/browse/CASSANDRA-12390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa reassigned CASSANDRA-12390: -- Assignee: Abhish Agarwal > Make SASI work with partitioners that have variable-size tokens > --- > > Key: CASSANDRA-12390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12390 > Project: Cassandra > Issue Type: Improvement > Components: sasi >Reporter: Alex Petrov >Assignee: Abhish Agarwal > > At the moment, SASI indexed can work only with Murmu3Partitioner. > [CASSANDRA-12389] was created to enable support of one more partitioner with > fixed-size tokens, although enabling variable-size tokens will need more > work, namely skipping tokens, since we can't rely on fixed-size > multiplication for calculating offsets in that case anymore. > This change won't require bytecode format changes, although supporting > ByteOrderedPartitioner is not a very high priority, and performance will be > worse because of "manual" skipping. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13756) StreamingHistogram is not thread safe
[ https://issues.apache.org/jira/browse/CASSANDRA-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13756: --- Fix Version/s: 3.11.x 3.0.x > StreamingHistogram is not thread safe > - > > Key: CASSANDRA-13756 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13756 > Project: Cassandra > Issue Type: Bug >Reporter: xiangzhou xia > Fix For: 3.0.x, 3.11.x > > > When we test C*3 in shadow cluster, we notice after a period of time, several > data node suddenly run into 100% cpu and stop process query anymore. > After investigation, we found that threads are stuck on the sum() in > streaminghistogram class. Those are jmx threads that working on expose > getTombStoneRatio metrics (since jmx is kicked off every 3 seconds, there is > a chance that multiple jmx thread is access streaminghistogram at the same > time). > After further investigation, we find that the optimization in CASSANDRA-13038 > led to a spool flush every time when we call sum(). Since TreeMap is not > thread safe, threads will be stuck when multiple threads visit sum() at the > same time. > There are two approaches to solve this issue. > The first one is to add a lock to the flush in sum() which will introduce > some extra overhead to streaminghistogram. > The second one is to avoid streaminghistogram to be access by multiple > threads. For our specific case, is to remove the metrics we added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13756) StreamingHistogram is not thread safe
[ https://issues.apache.org/jira/browse/CASSANDRA-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa reassigned CASSANDRA-13756: -- Assignee: Jeff Jirsa > StreamingHistogram is not thread safe > - > > Key: CASSANDRA-13756 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13756 > Project: Cassandra > Issue Type: Bug >Reporter: xiangzhou xia >Assignee: Jeff Jirsa > Fix For: 3.0.x, 3.11.x > > > When we test C*3 in shadow cluster, we notice after a period of time, several > data node suddenly run into 100% cpu and stop process query anymore. > After investigation, we found that threads are stuck on the sum() in > streaminghistogram class. Those are jmx threads that working on expose > getTombStoneRatio metrics (since jmx is kicked off every 3 seconds, there is > a chance that multiple jmx thread is access streaminghistogram at the same > time). > After further investigation, we find that the optimization in CASSANDRA-13038 > led to a spool flush every time when we call sum(). Since TreeMap is not > thread safe, threads will be stuck when multiple threads visit sum() at the > same time. > There are two approaches to solve this issue. > The first one is to add a lock to the flush in sum() which will introduce > some extra overhead to streaminghistogram. > The second one is to avoid streaminghistogram to be access by multiple > threads. For our specific case, is to remove the metrics we added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13756) StreamingHistogram is not thread safe
[ https://issues.apache.org/jira/browse/CASSANDRA-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa updated CASSANDRA-13756: --- Reviewer: Jason Brown > StreamingHistogram is not thread safe > - > > Key: CASSANDRA-13756 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13756 > Project: Cassandra > Issue Type: Bug >Reporter: xiangzhou xia >Assignee: Jeff Jirsa > Fix For: 3.0.x, 3.11.x > > > When we test C*3 in shadow cluster, we notice after a period of time, several > data node suddenly run into 100% cpu and stop process query anymore. > After investigation, we found that threads are stuck on the sum() in > streaminghistogram class. Those are jmx threads that working on expose > getTombStoneRatio metrics (since jmx is kicked off every 3 seconds, there is > a chance that multiple jmx thread is access streaminghistogram at the same > time). > After further investigation, we find that the optimization in CASSANDRA-13038 > led to a spool flush every time when we call sum(). Since TreeMap is not > thread safe, threads will be stuck when multiple threads visit sum() at the > same time. > There are two approaches to solve this issue. > The first one is to add a lock to the flush in sum() which will introduce > some extra overhead to streaminghistogram. > The second one is to avoid streaminghistogram to be access by multiple > threads. For our specific case, is to remove the metrics we added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13756) StreamingHistogram is not thread safe
[ https://issues.apache.org/jira/browse/CASSANDRA-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131453#comment-16131453 ] Jeff Jirsa commented on CASSANDRA-13756: Shouldn't need a version for trunk, but [~jasobrown] if you can check me there to be sure that'd be nice (I think in the faster rewrite for trunk, we now [build|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/streamhist/StreamingTombstoneHistogramBuilder.java#L182-L186] a snapshot that is no longer modified on read). || branch || utest || dtest || | [3.0|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.0-13756] | [3.0 circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.0-13756] | [3.0 dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/189/] | | [3.11|https://github.com/jeffjirsa/cassandra/tree/cassandra-3.11-13756] | [3.11 circle|https://circleci.com/gh/jeffjirsa/cassandra/tree/cassandra-3.11-13756] | [3.11 dtest|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/190/] | > StreamingHistogram is not thread safe > - > > Key: CASSANDRA-13756 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13756 > Project: Cassandra > Issue Type: Bug >Reporter: xiangzhou xia >Assignee: Jeff Jirsa > Fix For: 3.0.x, 3.11.x > > > When we test C*3 in shadow cluster, we notice after a period of time, several > data node suddenly run into 100% cpu and stop process query anymore. > After investigation, we found that threads are stuck on the sum() in > streaminghistogram class. Those are jmx threads that working on expose > getTombStoneRatio metrics (since jmx is kicked off every 3 seconds, there is > a chance that multiple jmx thread is access streaminghistogram at the same > time). > After further investigation, we find that the optimization in CASSANDRA-13038 > led to a spool flush every time when we call sum(). Since TreeMap is not > thread safe, threads will be stuck when multiple threads visit sum() at the > same time. > There are two approaches to solve this issue. > The first one is to add a lock to the flush in sum() which will introduce > some extra overhead to streaminghistogram. > The second one is to avoid streaminghistogram to be access by multiple > threads. For our specific case, is to remove the metrics we added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-13718) ConcurrentModificationException in nodetool upgradesstables
[
https://issues.apache.org/jira/browse/CASSANDRA-13718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa resolved CASSANDRA-13718.
Resolution: Fixed
Assignee: Jeff Jirsa
Resolving this as a dupe of CASSANDRA-13756 , you reported it first, but I
arbitrarily chose that one for my github branch name, so going with that.
Thanks for the report!
> ConcurrentModificationException in nodetool upgradesstables
> ---
>
> Key: CASSANDRA-13718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13718
> Project: Cassandra
> Issue Type: Bug
> Environment: Cassandra 3.11 on Linux
>Reporter: Hannu Kröger
>Assignee: Jeff Jirsa
>
> When upgrading from 2.2.8 to Cassandra 3.11 we were able to upgrade all other
> sstables except 1 file on 3 nodes (out of 4). Those are related to 2
> different tables.
> Upgrading sstables fails with ConcurrentModificationException.
> {code}
> $ nodetool upgradesstables
> error: null
> -- StackTrace --
> java.util.ConcurrentModificationException
> at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
> at java.util.TreeMap$KeyIterator.next(TreeMap.java:1265)
> at
> org.apache.cassandra.utils.StreamingHistogram.flushHistogram(StreamingHistogram.java:168)
> at
> org.apache.cassandra.utils.StreamingHistogram.update(StreamingHistogram.java:124)
> at
> org.apache.cassandra.utils.StreamingHistogram.update(StreamingHistogram.java:96)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataCollector.updateLocalDeletionTime(MetadataCollector.java:209)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataCollector.update(MetadataCollector.java:182)
> at org.apache.cassandra.db.rows.Cells.collectStats(Cells.java:44)
> at
> org.apache.cassandra.db.rows.Rows.lambda$collectStats$0(Rows.java:102)
> at org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
> at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
> at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
> at org.apache.cassandra.db.rows.Rows.collectStats(Rows.java:97)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter$StatsCollector.applyToRow(BigTableWriter.java:237)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:141)
> at
> org.apache.cassandra.db.ColumnIndex.buildRowIndex(ColumnIndex.java:110)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:173)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:135)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.realAppend(DefaultCompactionWriter.java:65)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.append(CompactionAwareWriter.java:141)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:201)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:428)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:315)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa reassigned CASSANDRA-13728:
--
Assignee: Varun Gupta
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.15, 3.11.1
>
> Attachments: display-max-hint-handoff-period.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131474#comment-16131474
]
Jeff Jirsa commented on CASSANDRA-13728:
I'm not [~jasobrown] , but I do have an opinion that we shouldn't change output
of existing JMX endpoints in minor versions, as people may be parsing it with
tools and relying on its output not changing. We should treat it as a public
API, and not break it on a minor.
Would be better (in my opinion) to use {{spProxy.getMaxHintWindow()}} to add a
new nodetool command (such as {{nodetool handoffwindow}} or similar) instead.
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.15, 3.11.1
>
> Attachments: display-max-hint-handoff-period.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131479#comment-16131479
]
Jeff Jirsa commented on CASSANDRA-13728:
If you change that, and you undo the changes to imports that your IDE probably
did on your behalf, I'll be happy to +1 it for you (talked to Jason and he says
he doesnt mind)
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.15, 3.11.1
>
> Attachments: display-max-hint-handoff-period.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13728:
---
Fix Version/s: (was: 3.11.1)
(was: 3.0.15)
4.x
3.11.x
3.0.x
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: display-max-hint-handoff-period.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13756) StreamingHistogram is not thread safe
[ https://issues.apache.org/jira/browse/CASSANDRA-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16131721#comment-16131721 ] Jeff Jirsa commented on CASSANDRA-13756: utests are clean, waiting on dtests. Apparently ~8 of the jenkins slaves are offline, so little bit delayed. > StreamingHistogram is not thread safe > - > > Key: CASSANDRA-13756 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13756 > Project: Cassandra > Issue Type: Bug >Reporter: xiangzhou xia >Assignee: Jeff Jirsa > Fix For: 3.0.x, 3.11.x > > > When we test C*3 in shadow cluster, we notice after a period of time, several > data node suddenly run into 100% cpu and stop process query anymore. > After investigation, we found that threads are stuck on the sum() in > streaminghistogram class. Those are jmx threads that working on expose > getTombStoneRatio metrics (since jmx is kicked off every 3 seconds, there is > a chance that multiple jmx thread is access streaminghistogram at the same > time). > After further investigation, we find that the optimization in CASSANDRA-13038 > led to a spool flush every time when we call sum(). Since TreeMap is not > thread safe, threads will be stuck when multiple threads visit sum() at the > same time. > There are two approaches to solve this issue. > The first one is to add a lock to the flush in sum() which will introduce > some extra overhead to streaminghistogram. > The second one is to avoid streaminghistogram to be access by multiple > threads. For our specific case, is to remove the metrics we added. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13728:
---
Status: Patch Available (was: Open)
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Add-nodetool-cmd-to-print-hinted-handoff-window.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13728:
---
Reviewer: Jeff Jirsa
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Minor
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Attachments: Add-nodetool-cmd-to-print-hinted-handoff-window.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12701) Repair history tables should have TTL and TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554246#comment-15554246 ] Jeff Jirsa commented on CASSANDRA-12701: Thanks for the patch [~bradfordcp]. Haven't yet reviewed, but pushing to CI and will review shortly. | [Trunk|https://github.com/jeffjirsa/cassandra/tree/cassandra-12701] | [utest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-testall/] | [dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-dtest/] | | [3.X|https://github.com/jeffjirsa/cassandra/tree/cassandra-12701-3.X] | [utest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-3.X-testall/] | [dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-3.X-dtest/] | > Repair history tables should have TTL and TWCS > -- > > Key: CASSANDRA-12701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12701 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink > Labels: lhf > Attachments: CASSANDRA-12701.txt > > > Some tools schedule a lot of small subrange repairs which can lead to a lot > of repairs constantly being run. These partitions can grow pretty big in > theory. I dont think much reads from them which might help but its still > kinda wasted disk space. I think a month TTL (longer than gc grace) and maybe > a 1 day twcs window makes sense to me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-12701) Repair history tables should have TTL and TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554246#comment-15554246 ] Jeff Jirsa edited comment on CASSANDRA-12701 at 10/7/16 6:10 AM: - Thanks for the patch [~bradfordcp]. Haven't reviewed, but pushing to CI | [Trunk|https://github.com/jeffjirsa/cassandra/tree/cassandra-12701] | [utest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-testall/] | [dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-dtest/] | | [3.X|https://github.com/jeffjirsa/cassandra/tree/cassandra-12701-3.X] | [utest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-3.X-testall/] | [dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-3.X-dtest/] | was (Author: jjirsa): Thanks for the patch [~bradfordcp]. Haven't yet reviewed, but pushing to CI and will review shortly. | [Trunk|https://github.com/jeffjirsa/cassandra/tree/cassandra-12701] | [utest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-testall/] | [dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-dtest/] | | [3.X|https://github.com/jeffjirsa/cassandra/tree/cassandra-12701-3.X] | [utest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-3.X-testall/] | [dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-12701-3.X-dtest/] | > Repair history tables should have TTL and TWCS > -- > > Key: CASSANDRA-12701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12701 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink > Labels: lhf > Attachments: CASSANDRA-12701.txt > > > Some tools schedule a lot of small subrange repairs which can lead to a lot > of repairs constantly being run. These partitions can grow pretty big in > theory. I dont think much reads from them which might help but its still > kinda wasted disk space. I think a month TTL (longer than gc grace) and maybe > a 1 day twcs window makes sense to me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12701) Repair history tables should have TTL and TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1464#comment-1464 ] Jeff Jirsa commented on CASSANDRA-12701: Patch is fine. If you do a PR on Github, the committer is going to need to turn it into a patch, anyway, to merge it to the appropriate branch(es), because github is read-only (writable repo is at ASF not github). I've only pushed it to my github so I could kick off tests (which look good). > Repair history tables should have TTL and TWCS > -- > > Key: CASSANDRA-12701 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12701 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Chris Lohfink > Labels: lhf > Attachments: CASSANDRA-12701.txt > > > Some tools schedule a lot of small subrange repairs which can lead to a lot > of repairs constantly being run. These partitions can grow pretty big in > theory. I dont think much reads from them which might help but its still > kinda wasted disk space. I think a month TTL (longer than gc grace) and maybe > a 1 day twcs window makes sense to me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11218) Prioritize Secondary Index rebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-11218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1530#comment-1530 ] Jeff Jirsa commented on CASSANDRA-11218: [~beobal] - skip review on the 3.0 branch, probably a big enough change we shouldn't push it to 3.0 at this point. However, here's 3.X: | [3.X|https://github.com/jeffjirsa/cassandra/tree/cassandra-11218-3.X] | [utest|http://cassci.datastax.com/job/jeffjirsa-cassandra-11218-3.X-testall/] | [dtest|http://cassci.datastax.com/job/jeffjirsa-cassandra-11218-3.X-dtest/] | > Prioritize Secondary Index rebuild > -- > > Key: CASSANDRA-11218 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11218 > Project: Cassandra > Issue Type: Improvement > Components: Compaction >Reporter: sankalp kohli >Assignee: Jeff Jirsa >Priority: Minor > > We have seen that secondary index rebuild get stuck behind other compaction > during a bootstrap and other operations. This causes things to not finish. We > should prioritize index rebuild via a separate thread pool or using a > priority queue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12763) Compaction performance issues when a table has a lot of sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-12763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15560791#comment-15560791
]
Jeff Jirsa commented on CASSANDRA-12763:
As mentioned in IRC, I *THINK* that ultimately the problem is that this loop:
https://github.com/jeffjirsa/cassandra/blob/trunk/src/java/org/apache/cassandra/db/lifecycle/Helpers.java#L130
Calls {{listFiles()}} for each sstablereader in the transaction. Since
{{listFiles}} is notoriously slow when there are a ton of files in the
directory, and you call it N times, you end up waiting at the end of the
compaction preparing to commit/marking files for deletion. It may be worth
someone investigating whether or not we can avoid the full directory scan N
times - due to nature of that code, it may not be safe to cache the directory
listing, but it's worth looking into.
> Compaction performance issues when a table has a lot of sstables
>
>
> Key: CASSANDRA-12763
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12763
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Tom van der Woerdt
>
> An issue with a script flooded my cluster with sstables. There is now a table
> with 100k sstables, all on the order of KBytes, and it's taking a long time
> (ETA 20 days) to compact, even though the table is only ~30GB.
> Stack trace :
> {noformat}
> "CompactionExecutor:269" #7536 daemon prio=1 os_prio=4 tid=0x7f4acd40fc00
> nid=0x14f8 runnable [0x7f4798436000]
>java.lang.Thread.State: RUNNABLE
> at java.io.UnixFileSystem.list(Native Method)
> at java.io.File.list(File.java:1122)
> at java.io.File.listFiles(File.java:1248)
> at
> org.apache.cassandra.db.lifecycle.LogRecord.getExistingFiles(LogRecord.java:268)
> at org.apache.cassandra.db.lifecycle.LogRecord.make(LogRecord.java:150)
> at
> org.apache.cassandra.db.lifecycle.LogFile.makeRecord(LogFile.java:293)
> at org.apache.cassandra.db.lifecycle.LogFile.add(LogFile.java:283)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.obsoleted(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.Helpers.prepareForObsoletion(Helpers.java:134)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.doPrepare(LifecycleTransaction.java:193)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.doPrepare(SSTableRewriter.java:376)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.doPrepare(CompactionAwareWriter.java:84)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.prepareToCommit(Transactional.java:173)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.finish(Transactional.java:184)
> at
> org.apache.cassandra.db.compaction.writers.CompactionAwareWriter.finish(CompactionAwareWriter.java:94)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:194)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:78)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:263)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> listFiles is being called over and over, apparently scaling with the number
> of files in the compaction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7296) Add CL.COORDINATOR_ONLY
[
https://issues.apache.org/jira/browse/CASSANDRA-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15562632#comment-15562632
]
Jeff Jirsa commented on CASSANDRA-7296:
---
{quote}
First, I'm not even entirely sure than letting the dynamic snitch bypass the
coordinator if it's a replica is a good idea in the first place. Everyone more
or less agree that doing token-aware routing is a good thing nowadays, and it's
certainly confusing that the dynamic snitch may screw that up. If the dynamic
snitch was a perfect and instantaneous view of latencies, then that could make
sense, but it's not. Anyway, I think it's worth at least evaluating making even
the dynamic snitch always pick the local node if it's a replica, as I'm not
sure the benefit of not doing so outweigh the confusion it creates.
{quote}
Emotionally, I want this to be the right answer (principle of least
astonishment), but I don't think it is. I'm concerned it will prove to be a
step backwards in real clusters, where coordinator disk latencies may truly
jump up up significantly (imagine all compaction threads running scrub/cleanup,
where not only is the disk likely completely utilized, but the # of sstables on
disk grows because all compaction threads are in use, so reads are more
expensive than normal - in this case, dsnitch DOES save us, and implementing
this type of change would be very hard to work around in production with most
drivers).
> Add CL.COORDINATOR_ONLY
> ---
>
> Key: CASSANDRA-7296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7296
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tupshin Harper
>
> For reasons such as CASSANDRA-6340 and similar, it would be nice to have a
> read that never gets distributed, and only works if the coordinator you are
> talking to is an owner of the row.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7296) Add CL.COORDINATOR_ONLY
[ https://issues.apache.org/jira/browse/CASSANDRA-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15562814#comment-15562814 ] Jeff Jirsa commented on CASSANDRA-7296: --- +1 in favor of protocol option, so users can apply it to other CLs as desired. > Add CL.COORDINATOR_ONLY > --- > > Key: CASSANDRA-7296 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7296 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper > > For reasons such as CASSANDRA-6340 and similar, it would be nice to have a > read that never gets distributed, and only works if the coordinator you are > talking to is an owner of the row. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12014) IndexSummary > 2G causes an assertion error
[
https://issues.apache.org/jira/browse/CASSANDRA-12014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-12014:
---
Reviewer: Jeff Jirsa
> IndexSummary > 2G causes an assertion error
> ---
>
> Key: CASSANDRA-12014
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12014
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Brandon Williams
>Assignee: Stefania
>Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> {noformat}
> ERROR [CompactionExecutor:1546280] 2016-06-01 13:21:00,444
> CassandraDaemon.java:229 - Exception in thread
> Thread[CompactionExecutor:1546280,1,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.io.sstable.IndexSummaryBuilder.maybeAddEntry(IndexSummaryBuilder.java:171)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.io.sstable.SSTableWriter$IndexWriter.append(SSTableWriter.java:634)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.afterAppend(SSTableWriter.java:179)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:205)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:126)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:197)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:73)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:263)
> ~[cassandra-all-2.1.12.1046.jar:2.1.12.1046]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> {noformat}
> I believe this can be fixed by raising the min_index_interval, but we should
> have a better method of coping with this than throwing the AE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa reassigned CASSANDRA-7622: - Assignee: Jeff Jirsa > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement >Reporter: Tupshin Harper >Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12296) system_auth can't be rebuilt by default
[
https://issues.apache.org/jira/browse/CASSANDRA-12296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15567411#comment-15567411
]
Jeff Jirsa commented on CASSANDRA-12296:
[~KurtG] - If you're running NTS with only one replica, the patch will advise
you to consider {{NetworkTopologyStrategy}}. Further, {{SimpleStrategy}} with a
higher RF would also be adequate to find a second replica for streaming - the
datastax docs recommending {{NetworkTopologyStrategy}} before {{nodetool
rebuild}} are specifically referencing adding a new DC. The error message above
is not limited to ONLY adding a new DC, and could be hit in a number of other
ways, where the recommendation to switch to NTS isn't necessary.
I agree the message is difficult to understand now, but "please switch to NTS"
isn't the right fix here, either.
> system_auth can't be rebuilt by default
> ---
>
> Key: CASSANDRA-12296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12296
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jim Witschey
>Priority: Minor
> Labels: lhf
> Attachments: 12296.patch
>
>
> This came up in discussion of CASSANDRA-11687. {{nodetool rebuild}} was
> failing in a dtest. [~pauloricardomg] explained:
> bq. before [CASSANDRA-11848] the local node could be considered a source,
> while now sources are restricted only to dc2, so since {{system_auth}} uses
> {{SimpleStrategy}} depending on the token arrangement there could or not be
> sources from dc2. Fix is to either use
> {{-Dcassandra.consistent.rangemovement=false}} or update {{system_auth}} to
> use {{NetworkTopologyStrategy}} with 2 dcs..
> This is, at the very least, a UX bug. When {{rebuild}} fails, it fails with
> {code}
> nodetool: Unable to find sufficient sources for streaming range
> (-3287869951390391138,-1624006824486474209] in keyspace system_auth with
> RF=1.If you want to ignore this, consider using system property
> -Dcassandra.consistent.rangemovement=false.
> {code}
> which suggests that a user should give up consistency guarantees when it's
> not necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
