[jira] [Updated] (CASSANDRA-15070) coredump in cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-15070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chakravarthi Manepalli updated CASSANDRA-15070: --- Severity: Low Discovered By: User Report Bug Category: Parent values: Availability(12983)Level 1 values: Response Crash(12991) Status: Open (was: Triage Needed) > coredump in cqlsh > - > > Key: CASSANDRA-15070 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15070 > Project: Cassandra > Issue Type: Bug > Components: Tool/cqlsh >Reporter: Chakravarthi Manepalli >Priority: Normal > Labels: easyfix > > Cqlsh crashes with coredump when given ctrl+| or ctrl+\ or ctrl+4. > Moreover it becomes unresponsive if ctrl+s is given. > It is observed in apache cassandra 3.11 and dse 6.7.2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13357) A possible NPE in nodetool getendpoints
[
https://issues.apache.org/jira/browse/CASSANDRA-13357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807413#comment-16807413
]
Hao Zhong commented on CASSANDRA-13357:
---
The patch looks good to me.
> A possible NPE in nodetool getendpoints
> ---
>
> Key: CASSANDRA-13357
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13357
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Hao Zhong
>Assignee: Hao Zhong
>Priority: Normal
> Fix For: 4.x
>
> Attachments: cassandra.patch
>
>
> The GetEndpoints.execute method has the following code:
> {code:title=GetEndpoints.java|borderStyle=solid}
>List endpoints = probe.getEndpoints(ks, table, key);
> for (InetAddress endpoint : endpoints)
> {
> System.out.println(endpoint.getHostAddress());
> }
> {code}
> This code can throw NPE. A similar bug is fixed in CASSANDRA-8950. The buggy
> code is
> {code:title=NodeCmd.java|borderStyle=solid}
> List endpoints = this.probe.getEndpoints(keySpace, cf, key);
> for (InetAddress anEndpoint : endpoints)
> {
>output.println(anEndpoint.getHostAddress());
> }
> {code}
> The fixed code is:
> {code:title=NodeCmd.java|borderStyle=solid}
> try
> {
> List endpoints = probe.getEndpoints(keySpace, cf,
> key);
> for (InetAddress anEndpoint : endpoints)
>output.println(anEndpoint.getHostAddress());
> }
> catch (IllegalArgumentException ex)
> {
> output.println(ex.getMessage());
> probe.failed();
> }
> {code}
> The GetEndpoints.execute method shall be modified as CASSANDRA-8950 does.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13357) A possible NPE in nodetool getendpoints
[
https://issues.apache.org/jira/browse/CASSANDRA-13357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807407#comment-16807407
]
mck edited comment on CASSANDRA-13357 at 4/2/19 5:07 AM:
-
[~eduard.tudenhoefner] (and [~haozhong]),
the code in `GetEndpoints` in trunk has changed a little since this. I've
redone the patch, can you let me know if it's ok by you?
|| branch || circleci || asf jenkins ||
|
[CASSANDRA-13357|https://github.com/thelastpickle/cassandra/commit/6a44f1202dfa37f2b190bc3c02de83e65922706d]
|
[circleci|https://circleci.com/workflow-run/9532cd94-8123-4cab-9c29-deaa52b3c372]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/37//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/37/]
|
was (Author: michaelsembwever):
[~eduard.tudenhoefner] (and [~haozhong]),
the code in `GetEndpoints` in trunk has changed a little since this. I've
redone the patch, can you let me know if it's ok by you?
|| branch || circleci || asf jenkins ||
|
[CASSANDRA-13357|https://github.com/thelastpickle/cassandra/commit/6a44f1202dfa37f2b190bc3c02de83e65922706d]
|
[!https://circleci.com/workflow-run/9532cd94-8123-4cab-9c29-deaa52b3c372.svg?style=svg!|https://circleci.com/workflow-run/9532cd94-8123-4cab-9c29-deaa52b3c372]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/37//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/37/]
|
> A possible NPE in nodetool getendpoints
> ---
>
> Key: CASSANDRA-13357
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13357
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Hao Zhong
>Assignee: Hao Zhong
>Priority: Normal
> Fix For: 4.x
>
> Attachments: cassandra.patch
>
>
> The GetEndpoints.execute method has the following code:
> {code:title=GetEndpoints.java|borderStyle=solid}
>List endpoints = probe.getEndpoints(ks, table, key);
> for (InetAddress endpoint : endpoints)
> {
> System.out.println(endpoint.getHostAddress());
> }
> {code}
> This code can throw NPE. A similar bug is fixed in CASSANDRA-8950. The buggy
> code is
> {code:title=NodeCmd.java|borderStyle=solid}
> List endpoints = this.probe.getEndpoints(keySpace, cf, key);
> for (InetAddress anEndpoint : endpoints)
> {
>output.println(anEndpoint.getHostAddress());
> }
> {code}
> The fixed code is:
> {code:title=NodeCmd.java|borderStyle=solid}
> try
> {
> List endpoints = probe.getEndpoints(keySpace, cf,
> key);
> for (InetAddress anEndpoint : endpoints)
>output.println(anEndpoint.getHostAddress());
> }
> catch (IllegalArgumentException ex)
> {
> output.println(ex.getMessage());
> probe.failed();
> }
> {code}
> The GetEndpoints.execute method shall be modified as CASSANDRA-8950 does.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13357) A possible NPE in nodetool getendpoints
[
https://issues.apache.org/jira/browse/CASSANDRA-13357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807407#comment-16807407
]
mck commented on CASSANDRA-13357:
-
[~eduard.tudenhoefner] (and [~haozhong]),
the code in `GetEndpoints` in trunk has changed a little since this. I've
redone the patch, can you let me know if it's ok by you?
|| branch || circleci || asf jenkins ||
|
[CASSANDRA-13357|https://github.com/thelastpickle/cassandra/commit/6a44f1202dfa37f2b190bc3c02de83e65922706d]
|
[!https://circleci.com/workflow-run/9532cd94-8123-4cab-9c29-deaa52b3c372.svg?style=svg!|https://circleci.com/workflow-run/9532cd94-8123-4cab-9c29-deaa52b3c372]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/37//badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/37/]
|
> A possible NPE in nodetool getendpoints
> ---
>
> Key: CASSANDRA-13357
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13357
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Hao Zhong
>Assignee: Hao Zhong
>Priority: Normal
> Fix For: 4.x
>
> Attachments: cassandra.patch
>
>
> The GetEndpoints.execute method has the following code:
> {code:title=GetEndpoints.java|borderStyle=solid}
>List endpoints = probe.getEndpoints(ks, table, key);
> for (InetAddress endpoint : endpoints)
> {
> System.out.println(endpoint.getHostAddress());
> }
> {code}
> This code can throw NPE. A similar bug is fixed in CASSANDRA-8950. The buggy
> code is
> {code:title=NodeCmd.java|borderStyle=solid}
> List endpoints = this.probe.getEndpoints(keySpace, cf, key);
> for (InetAddress anEndpoint : endpoints)
> {
>output.println(anEndpoint.getHostAddress());
> }
> {code}
> The fixed code is:
> {code:title=NodeCmd.java|borderStyle=solid}
> try
> {
> List endpoints = probe.getEndpoints(keySpace, cf,
> key);
> for (InetAddress anEndpoint : endpoints)
>output.println(anEndpoint.getHostAddress());
> }
> catch (IllegalArgumentException ex)
> {
> output.println(ex.getMessage());
> probe.failed();
> }
> {code}
> The GetEndpoints.execute method shall be modified as CASSANDRA-8950 does.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13940) Fix stress seed multiplier
[
https://issues.apache.org/jira/browse/CASSANDRA-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807367#comment-16807367
]
mck commented on CASSANDRA-13940:
-
[~tjake] ?
> Fix stress seed multiplier
> --
>
> Key: CASSANDRA-13940
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13940
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Daniel Cranford
>Assignee: Daniel Cranford
>Priority: Normal
> Attachments: 0001-Fixing-seed-multiplier.patch
>
>
> CASSANDRA-12744 attempted to fix a problem with partition key generation, but
> is generally broken. E.G.
> {noformat}
> cassandra-stress -insert visits=fixed\(100\) revisit=uniform\(1..100\) ...
> {noformat}
> sends cassandra-stress into an infinite loop. Here's a better fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13940) Fix stress seed multiplier
[
https://issues.apache.org/jira/browse/CASSANDRA-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-13940:
Fix Version/s: 4.x
> Fix stress seed multiplier
> --
>
> Key: CASSANDRA-13940
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13940
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Daniel Cranford
>Assignee: Daniel Cranford
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 0001-Fixing-seed-multiplier.patch
>
>
> CASSANDRA-12744 attempted to fix a problem with partition key generation, but
> is generally broken. E.G.
> {noformat}
> cassandra-stress -insert visits=fixed\(100\) revisit=uniform\(1..100\) ...
> {noformat}
> sends cassandra-stress into an infinite loop. Here's a better fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13940) Fix stress seed multiplier
[
https://issues.apache.org/jira/browse/CASSANDRA-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-13940:
Reviewers: Ben Slater
> Fix stress seed multiplier
> --
>
> Key: CASSANDRA-13940
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13940
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Daniel Cranford
>Assignee: Daniel Cranford
>Priority: Normal
> Attachments: 0001-Fixing-seed-multiplier.patch
>
>
> CASSANDRA-12744 attempted to fix a problem with partition key generation, but
> is generally broken. E.G.
> {noformat}
> cassandra-stress -insert visits=fixed\(100\) revisit=uniform\(1..100\) ...
> {noformat}
> sends cassandra-stress into an infinite loop. Here's a better fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13940) Fix stress seed multiplier
[
https://issues.apache.org/jira/browse/CASSANDRA-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-13940:
Test and Documentation Plan: against 4.0
Status: Patch Available (was: Open)
> Fix stress seed multiplier
> --
>
> Key: CASSANDRA-13940
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13940
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Daniel Cranford
>Priority: Normal
> Attachments: 0001-Fixing-seed-multiplier.patch
>
>
> CASSANDRA-12744 attempted to fix a problem with partition key generation, but
> is generally broken. E.G.
> {noformat}
> cassandra-stress -insert visits=fixed\(100\) revisit=uniform\(1..100\) ...
> {noformat}
> sends cassandra-stress into an infinite loop. Here's a better fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13940) Fix stress seed multiplier
[
https://issues.apache.org/jira/browse/CASSANDRA-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck reassigned CASSANDRA-13940:
---
Assignee: Daniel Cranford
> Fix stress seed multiplier
> --
>
> Key: CASSANDRA-13940
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13940
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Daniel Cranford
>Assignee: Daniel Cranford
>Priority: Normal
> Attachments: 0001-Fixing-seed-multiplier.patch
>
>
> CASSANDRA-12744 attempted to fix a problem with partition key generation, but
> is generally broken. E.G.
> {noformat}
> cassandra-stress -insert visits=fixed\(100\) revisit=uniform\(1..100\) ...
> {noformat}
> sends cassandra-stress into an infinite loop. Here's a better fix.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807354#comment-16807354
]
Erik Swanson commented on CASSANDRA-15072:
--
Please see the attached [^eriksw-repro.sh], which includes aggressive flushing,
draining, and deleting commit logs when stopped to ensure they play no part.
With these steps, the truncated results behavior when querying node2 (the
un-upgraded node) is 100% reproducible for me for an unlimited number of
queries with CONSISTENCY ALL.
{quote}do you mean data you'd inserted before the upgrade reappeared?
{quote}
Yes. After the last node was upgraded to Cassandra 3.11.4, we no longer saw
truncated results regardless of which node we queried. All data that should
have been in the results was correctly returned for all queries after that
point.
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Assignee: Blake Eggleston
>Priority: High
> Attachments: eriksw-repro.sh
>
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 < CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Swanson updated CASSANDRA-15072:
-
Attachment: eriksw-repro.sh
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Assignee: Blake Eggleston
>Priority: High
> Attachments: eriksw-repro.sh
>
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 < CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807327#comment-16807327
]
Blake Eggleston commented on CASSANDRA-15072:
-
Ok, I can repro your issue with the updated script. It looks like you’re
hitting a commit log bug that was introduced in 2.1 and fixed in 3.0
(CASSANDRA-13987) If you drain node 1 & 2 before shutting them down, this
should stop happening.
I’d also expected putting a sleep larger than the commit log sync interval
before shutting down node 1 would fix the problem, but it didn’t. I’m still
looking at why that is.
When you say:
{quote}When all nodes were upgraded (before upgrading sstables), we stopped
getting incomplete results
{quote}
do you mean data you'd inserted before the upgrade reappeared?
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 < CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston reassigned CASSANDRA-15072:
---
Assignee: Blake Eggleston
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Assignee: Blake Eggleston
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 < CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807315#comment-16807315
]
Erik Swanson commented on CASSANDRA-15072:
--
Muir's colleague here:
I get 100% reproducibility for repeated queries with the following changes:
# Create the keyspace with replication_factor 2
# Do the inserts with CONSISTENCY ALL
# Upgrade the two nodes that contain data (node1, node3); keep the node that
does not contain any sstables for test.test (node2) back at 2.1.17
After those steps, I get full results 100% of the time when querying node1 and
node3, and truncated results 100% of the time when querying node2.
This is using cqlsh as packaged with 3.11.4.
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 < CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15052) Dtests: Add acceptable warnings to offline tool tests in order to pass them
[ https://issues.apache.org/jira/browse/CASSANDRA-15052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15052: -- Status: Triage Needed (was: Awaiting Feedback) replied > Dtests: Add acceptable warnings to offline tool tests in order to pass them > --- > > Key: CASSANDRA-15052 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15052 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Labels: pull-request-available > Attachments: SPICE-15052.txt > > Time Spent: 50m > Remaining Estimate: 0h > > I run all dtest suite and test > offline_tools_test.py::TestOfflineTools::test_sstablelevelreset has failed > because of additional warning logs which were not added into acceptable ones. > After adding them, test passed fine. I believe added warning messages have > nothing to do with test itself, it was reproduced on c5.9xlarge as well as no > "regular" notebook. > > https://github.com/apache/cassandra-dtest/pull/47 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15066) Improvements to Internode Messaging
[
https://issues.apache.org/jira/browse/CASSANDRA-15066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807254#comment-16807254
]
Jason Brown commented on CASSANDRA-15066:
-
I believe many of these changes indeed improve the quality of the code and
long-term strengthen the system, but seem best targetted at 4.NEXT. I and
others would like to collaborate on this effort going forward.
The introduction of a slew of new features (checksumming, reimplementing parts
of netty (AsyncPromise, LZ4 compression, replacing netty’s ByteBufAllocator
with c*’s)) and major reimplementations (droppable verbs/verb priority,
semantic changes to connection types) seven months after the community declared
a feature freeze for 4.0 seems ill-advised, at best. The size, scope, and depth
of this patch, which touches many vital components, invalidates most 4.0
testing hitherto.
In my estimation, a fair and thorough review of the current patch alone, by
myself and others, would be at least 2 solid months, as there is a lot of new
complexity introduced. Significant additional time would be required for
integration testing. At the barest minimum, this patch should be broken up into
separate tickets, review them indivdidually, and merge them incrementally.
Additionaly, I think having a discussion on dev@, as you proposed, would be
highly beneficial.
Further, CASSANDRA-14503 was posted for REVIEW, in the hopes that we could have
a discussion around the current state of trunk and the patch I submitted. I
appreciate the reporting of the bugs you found and work you invested. Beyond
that, however, there has not been any meaningful discussion or engagement. I
would have appreciated the opportunity to collaborate on this effort,
especially as I have personally invested much time and effort into this work.
To sum up, I am -1 on this work in it's current form *for 4.0* as the new
features violate the freeze, and many of the new implementations violate
principle of reducing risk and increase stability as we run up to 4.0.
> Improvements to Internode Messaging
> ---
>
> Key: CASSANDRA-15066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15066
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Benedict
>Assignee: Benedict
>Priority: Normal
> Fix For: 4.0
>
>
> CASSANDRA-8457 introduced asynchronous networking to internode messaging, but
> there have been several follow-up endeavours to improve some semantic issues.
> CASSANDRA-14503 and CASSANDRA-13630 are the latest such efforts, and were
> combined some months ago into a single overarching refactor of the original
> work, to address some of the issues that have been discovered. Given the
> criticality of this work to the project, we wanted to bring some more eyes to
> bear to ensure the release goes ahead smoothly. In doing so, we uncovered a
> number of issues with messaging, some of which long standing, that we felt
> needed to be addressed. This patch widens the scope of CASSANDRA-14503 and
> CASSANDRA-13630 in an effort to close the book on the messaging service, at
> least for the foreseeable future.
> The patch includes a number of clarifying refactors that touch outside of the
> {{net.async}} package, and a number of semantic changes to the {{net.async}}
> packages itself. We believe it clarifies the intent and behaviour of the
> code while improving system stability, which we will outline in comments
> below.
> https://github.com/belliottsmith/cassandra/tree/messaging-improvements
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14108) Improve commit log chain marker updating
[
https://issues.apache.org/jira/browse/CASSANDRA-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807242#comment-16807242
]
C. Scott Andreas commented on CASSANDRA-14108:
--
[~jasobrown] Sorry for the assignment change; I hit the key combo by mistake
while viewing this issue.
> Improve commit log chain marker updating
>
>
> Key: CASSANDRA-14108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14108
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Normal
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> CASSANDRA-13987 addressed the commit log behavior change that was introduced
> with CASSANDRA-3578. After that patch was committed, [~aweisberg] did his own
> review and found a bug as well as having some concerns about the
> configuration. He and I discussed offline, and agreed on some improvements.
> Instead of requiring users to configure a deep, dark implementation detail
> like the commit log chained markers (via {{commitlog_marker_period_in_ms}} in
> the yaml), we decided it is best to eliminate thew configuration and always
> update the chained markers (when in periodic mode).
> The bug [~aweisberg] found was when the chained marker update is not a value
> that evenly divides into the periodic sync mode value, we would not sync in
> an expected manner. For example if the marker interval is 9 seconds, and the
> sync interval is 10 seconds, we would update the markers at time9, but we
> would then sleep for another 9 seconds, and when we wake up at time18, it is
> then that we flush - 8 seconds later than we should have.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14108) Improve commit log chain marker updating
[
https://issues.apache.org/jira/browse/CASSANDRA-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas reassigned CASSANDRA-14108:
Assignee: Jason Brown (was: C. Scott Andreas)
> Improve commit log chain marker updating
>
>
> Key: CASSANDRA-14108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14108
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jason Brown
>Assignee: Jason Brown
>Priority: Normal
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> CASSANDRA-13987 addressed the commit log behavior change that was introduced
> with CASSANDRA-3578. After that patch was committed, [~aweisberg] did his own
> review and found a bug as well as having some concerns about the
> configuration. He and I discussed offline, and agreed on some improvements.
> Instead of requiring users to configure a deep, dark implementation detail
> like the commit log chained markers (via {{commitlog_marker_period_in_ms}} in
> the yaml), we decided it is best to eliminate thew configuration and always
> update the chained markers (when in periodic mode).
> The bug [~aweisberg] found was when the chained marker update is not a value
> that evenly divides into the periodic sync mode value, we would not sync in
> an expected manner. For example if the marker interval is 9 seconds, and the
> sync interval is 10 seconds, we would update the markers at time9, but we
> would then sleep for another 9 seconds, and when we wake up at time18, it is
> then that we flush - 8 seconds later than we should have.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14108) Improve commit log chain marker updating
[
https://issues.apache.org/jira/browse/CASSANDRA-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas reassigned CASSANDRA-14108:
Assignee: C. Scott Andreas (was: Jason Brown)
> Improve commit log chain marker updating
>
>
> Key: CASSANDRA-14108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14108
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jason Brown
>Assignee: C. Scott Andreas
>Priority: Normal
> Fix For: 3.0.16, 3.11.2, 4.0
>
>
> CASSANDRA-13987 addressed the commit log behavior change that was introduced
> with CASSANDRA-3578. After that patch was committed, [~aweisberg] did his own
> review and found a bug as well as having some concerns about the
> configuration. He and I discussed offline, and agreed on some improvements.
> Instead of requiring users to configure a deep, dark implementation detail
> like the commit log chained markers (via {{commitlog_marker_period_in_ms}} in
> the yaml), we decided it is best to eliminate thew configuration and always
> update the chained markers (when in periodic mode).
> The bug [~aweisberg] found was when the chained marker update is not a value
> that evenly divides into the periodic sync mode value, we would not sync in
> an expected manner. For example if the marker interval is 9 seconds, and the
> sync interval is 10 seconds, we would update the markers at time9, but we
> would then sleep for another 9 seconds, and when we wake up at time18, it is
> then that we flush - 8 seconds later than we should have.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807227#comment-16807227
]
Muir Manders commented on CASSANDRA-15072:
--
It seems with my updated steps that only the first query against node3
reproduces it. After that it returns both rows. If you restart node3, it
reproduces it again for one query. This is not the behavior we experienced in
production (i.e. the problem did not go away). I wonder if I have actually
reproduced our issue or not...
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 < CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807221#comment-16807221
]
Muir Manders commented on CASSANDRA-15072:
--
Yes, we saw a lot of incomplete results in a real cluster. We read and write at
quorum.
Oops, you are right about my repro. I modified the steps to reproduce it at
quorum (I upgraded two out of three nodes instead of just one, changed the
reads/writes to be quorum, and connected to node 3 to perform the reproduction
query).
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 < CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Muir Manders updated CASSANDRA-15072:
-
Description:
Hello
During an upgrade from 2.1.17 to 3.11.4, our application starting getting back
incomplete results for range queries. When all nodes were upgraded (before
upgrading sstables), we stopped getting incomplete results. I was able to
reproduce it and listed steps below. It seems to require the random partitioner
and compact storage to reproduce reliably. It also reproduces coming from
2.1.21 and 2.2.14. You seem to get the bad behavior when an old node is your
coordinator and it has to talk to an upgraded replica.
{noformat}
ccm create test -v 2.1.17 -n 3
ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
ccm node1 updateconf 'initial_token: 0'
ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
ccm start
ccm node1 cqlsh < Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 < CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Muir Manders updated CASSANDRA-15072:
-
Description:
Hello
During an upgrade from 2.1.17 to 3.11.4, our application starting getting back
incomplete results for range queries. When all nodes were upgraded (before
upgrading sstables), we stopped getting incomplete results. I was able to
reproduce it and listed steps below. It seems to require the random partitioner
and compact storage to reproduce reliably. It also reproduces coming from
2.1.21 and 2.2.14. You seem to get the bad behavior when an old node is your
coordinator and it has to talk to an upgraded replica.
{noformat}
ccm create test -v 2.1.17 -n 3
ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
ccm node1 updateconf 'initial_token: 0'
ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
ccm start
ccm node1 cqlsh < Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.2 < PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11479) BatchlogManager unit tests failing on truncate race condition
[ https://issues.apache.org/jira/browse/CASSANDRA-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-11479: Reviewers: Joel Knighton, mck (was: Joel Knighton) > BatchlogManager unit tests failing on truncate race condition > - > > Key: CASSANDRA-11479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11479 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Joel Knighton >Assignee: Yuki Morishita >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x > > Attachments: > TEST-org.apache.cassandra.batchlog.BatchlogManagerTest.log > > > Example on CI > [here|http://cassci.datastax.com/job/trunk_testall/818/testReport/junit/org.apache.cassandra.batchlog/BatchlogManagerTest/testLegacyReplay_compression/]. > This seems to have only started happening relatively recently (within the > last month or two). > As far as I can tell, this is only showing up on BatchlogManagerTests purely > because it is an aggressive user of truncate. The assertion is hit in the > setUp method, so it can happen before any of the test methods. The assertion > occurs because a compaction is happening when truncate wants to discard > SSTables; trace level logs suggest that this compaction is submitted after > the pause on the CompactionStrategyManager. > This should be reproducible by running BatchlogManagerTest in a loop - it > takes up to half an hour in my experience. A trace-level log from such a run > is attached - grep for my added log message "SSTABLES COMPACTING WHEN > DISCARDING" to find when the assert is hit. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11479) BatchlogManager unit tests failing on truncate race condition
[
https://issues.apache.org/jira/browse/CASSANDRA-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807202#comment-16807202
]
mck commented on CASSANDRA-11479:
-
[~yukim] and [~jkni], is this still a problem?
I ran the following over 12 hours without a single failure on the
{{cassandra-2.2}} branch.
{code}while : ; do ant test -Dtest.name=BatchlogManagerTest ; [[ "$?" -eq 0 ]]
|| break ; done{code}
> BatchlogManager unit tests failing on truncate race condition
> -
>
> Key: CASSANDRA-11479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11479
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Joel Knighton
>Assignee: Yuki Morishita
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
> Attachments:
> TEST-org.apache.cassandra.batchlog.BatchlogManagerTest.log
>
>
> Example on CI
> [here|http://cassci.datastax.com/job/trunk_testall/818/testReport/junit/org.apache.cassandra.batchlog/BatchlogManagerTest/testLegacyReplay_compression/].
> This seems to have only started happening relatively recently (within the
> last month or two).
> As far as I can tell, this is only showing up on BatchlogManagerTests purely
> because it is an aggressive user of truncate. The assertion is hit in the
> setUp method, so it can happen before any of the test methods. The assertion
> occurs because a compaction is happening when truncate wants to discard
> SSTables; trace level logs suggest that this compaction is submitted after
> the pause on the CompactionStrategyManager.
> This should be reproducible by running BatchlogManagerTest in a loop - it
> takes up to half an hour in my experience. A trace-level log from such a run
> is attached - grep for my added log message "SSTABLES COMPACTING WHEN
> DISCARDING" to find when the assert is hit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807185#comment-16807185
]
Blake Eggleston commented on CASSANDRA-15072:
-
Are you seeing incomplete results like this in a real cluster? If so, what
consistency level are you reading and writing at?
The ccm script you have here _does_ return incomplete results, but it’s also
writing and reading at CL ONE (the cqlsh default), so that’s not unexpected. I
modified the script here to read and write at QUORUM, and haven't gotten any
incomplete results.
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> # need to use new cqlsh so we can configure page size
> cqlsh 127.0.0.2 < PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas updated CASSANDRA-15072:
-
Discovered By: User Report
Bug Category: Parent values: Correctness(12982)Level 1 values: Response
Corruption / Loss(12987)
Priority: High (was: Normal)
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
>Reporter: Muir Manders
>Priority: High
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh < CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> # need to use new cqlsh so we can configure page size
> cqlsh 127.0.0.2 < PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> +---+-
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15005) Configurable whilelist for UDFs
[
https://issues.apache.org/jira/browse/CASSANDRA-15005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807101#comment-16807101
]
A. Soroka commented on CASSANDRA-15005:
---
[~jmeredithco], I finally had a chance to start on this. I've got a branch at
[https://github.com/apache/cassandra/compare/trunk...ajs6f:CASSANDRA-15005-trunk?expand=1]
and it currently is different from yours only a little bit: it is based off
{{trunk}}, I modified your code just a bit to differentiate another error
condition and used the Stream API a little more than did you, I added a simple
unit test and a bit of text for {{doc/source/cql/functions.rst}}.
I hope this is useful-- this is my first attempt to contribute, so please do
correct me when you have time! I look forward to learning.
> Configurable whilelist for UDFs
> ---
>
> Key: CASSANDRA-15005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15005
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: A. Soroka
>Priority: Low
>
> I would like to use the UDF system to distribute some simple calculations on
> values. For some use cases, this would require access only to some Java API
> classes that aren't on the (hardcoded) whitelist (e.g.
> {{java.security.MessageDigest}}). In other cases, it would require access to
> a little non-C* library code, pre-distributed to nodes by out-of-band means.
> As I understand the situation now, the whitelist for types UDFs can use is
> hardcoded in java in
> [UDFunction|[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/UDFunction.java#L99].]
> This ticket, then, is a request for a facility that would allow that list to
> be extended via some kind of deployment-time configuration. I realize that
> serious security concerns immediately arise for this kind of functionality,
> but I hope that by restricting it (only used during startup, no exposing the
> whitelist for introspection, etc.) it could be quite practical.
> I'd like very much to assist with this ticket if it is accepted. (I believe I
> have sufficient Java skill to do that, but no real familiarity with C*'s
> codebase, yet. :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-13451) add gossip documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-13451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elijah Augustin reassigned CASSANDRA-13451: --- Assignee: Elijah Augustin > add gossip documentation > > > Key: CASSANDRA-13451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13451 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Jon Haddad >Assignee: Elijah Augustin >Priority: Normal > > There's a decent amount of valid info here: > https://wiki.apache.org/cassandra/ArchitectureGossip and we have basically > nothing in the official docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15072) Incomplete range results during 2.X -> 3.11.4 upgrade
Muir Manders created CASSANDRA-15072:
Summary: Incomplete range results during 2.X -> 3.11.4 upgrade
Key: CASSANDRA-15072
URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
Project: Cassandra
Issue Type: Bug
Reporter: Muir Manders
Hello
During an upgrade from 2.1.17 to 3.11.4, our application starting getting back
incomplete results for range queries. When all nodes were upgraded (before
upgrading sstables), we stopped getting incomplete results. I was able to
reproduce it and listed steps below. It seems to require the random partitioner
and compact storage to reproduce reliably. It also reproduces coming from
2.1.21 and 2.2.14.
{noformat}
ccm create test -v 2.1.17 -n 3
ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
ccm node1 updateconf 'initial_token: 0'
ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
ccm start
ccm node1 cqlsh <
[jira] [Commented] (CASSANDRA-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[
https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806963#comment-16806963
]
Benedict commented on CASSANDRA-15013:
--
Thanks [~sumanth.pasupuleti] for the patch. I've only taken a quick glance at
it so far, but it looks pretty good, and I'm looking forward to integrating it.
There's only one substantive comment I have for the moment, which is that I
think when we {{setAutoread(false)}}, we need to not discard the message. We
should perform only one of the two options; if we ever discard, I think we
should always let the user know by throwing {{OverloadedException}}.
If we want to use back pressure without throwing away any messages that are
over our limit, I can think of two fairly straight forward mechanisms, with the
best being unfortunately quite difficult given our current Netty pipeline.
# Like we have done for CASSANDRA-15066, we would ideally leave the message
unparsed in the buffer until we have capacity to process it.
# Alternatively, as an easier solution, we can unconditionally enqueue the
message to the executor, assuming that we must have a fairly limited quantity
of bytes we can overshoot by
Also, as a point of consideration only, we _might_ also want to limit the
number of bytes we have in-flight per-endpoint, rather than per-channel, to
avoid a given host spamming the database with many connections. It's perhaps
not a very good unit to limit by, either, since an IP address may host many
applications, but an application can also open an arbitrary number of
connections, and crowd out all other hosts...
Just something to consider, I'm not sure what the best constraints are here.
Perhaps, similar to CASSANDRA-15066, a very small per-connection limit that can
always be consumed, to ensure progress on any given channel, with per-endpoint
and global limits for when these are exceeded (though this is less obvious than
for internode, as there could be many more clients connected, so it would be
plausible for these low limits to consume a great deal in combination).
It might be that we want to introduce the concept of an application identifier,
so that users who want to run multiple applications per host can do so, while
still ensuring QoS to other applications if one goes awry.
> Message Flusher queue can grow unbounded, potentially running JVM out of
> memory
> ---
>
> Key: CASSANDRA-15013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15013
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0, 3.0.x, 3.11.x
>
> Attachments: BlockedEpollEventLoopFromHeapDump.png,
> BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap
> dump showing each ImmediateFlusher taking upto 600MB.png
>
>
> This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue
> bounded, since, in the current state, items get added to the queue without
> any checks on queue size, nor with any checks on netty outbound buffer to
> check the isWritable state.
> We are seeing this issue hit our production 3.0 clusters quite often.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15059) Gossiper#markAlive can race with Gossiper#markDead
[ https://issues.apache.org/jira/browse/CASSANDRA-15059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-15059: - Reviewers: Ariel Weisberg, Jordan West (was: Ariel Weisberg) > Gossiper#markAlive can race with Gossiper#markDead > -- > > Key: CASSANDRA-15059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15059 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > > The Gossiper class is not threadsafe and assumes all state changes happen in > a single thread (the gossip stage). Gossiper#convict, however, can be called > from the GossipTasks thread. This creates a race where calls to > Gossiper#markAlive and Gossiper#markDead can interleave, corrupting gossip > state. Gossiper#assassinateEndpoint has a similar problem, being called from > the mbean server thread. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14771) Transient Replication: Writes at CL.ALL should block on all full replicas, but not transients
[
https://issues.apache.org/jira/browse/CASSANDRA-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16622772#comment-16622772
]
Benedict edited comment on CASSANDRA-14771 at 4/1/19 2:18 PM:
--
Just for clarity of future readers, per CASSANDRA-14768, we might still want to
*write* to transient nodes if we would fail to reach QUORUM in any DC; this
will only be necessary in configurations where full replicas do not constitute
a QUORUM. These transient writes might themselves be protected by further
transient writes if any fail, though writes to full replicas will not be
protected in this way.
(edited, to fix nonsensical content)
was (Author: benedict):
Just for clarity of future readers, per CASSANDRA-14768, we might still want to
*write* to transient nodes if, due to timeouts on writes to full nodes, we fail
to reach {{QUORUM}} in any given DC. But we wouldn't pick any upfront since
we'd fail with unavailable if we can't find enough full to write to, would not
*rapid write protection* to them, and would not block our response on them.
Probably this can fairly easily be implemented by narrowing the candidates set
to only the full replicas to prevent speculation, and using a simple
{{AbstractWriteResponseHandler}} with {{blockFor}} set to the full node count.
Note, this is an aside for understanding some of the complexities here. This
won't be addressed in this ticket, but in CASSANDRA-14768 (or a related
followup).
> Transient Replication: Writes at CL.ALL should block on all full replicas,
> but not transients
> --
>
> Key: CASSANDRA-14771
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14771
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Transient Replication
>Reporter: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0
>
>
> Reading at ONE will still be safe because ONE only selects full replicas.
> There is no reason to write to transients if we are going to block on all
> full replicas.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14771) Transient Replication: Writes at CL.ALL should block on all full replicas, but not transients
[ https://issues.apache.org/jira/browse/CASSANDRA-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806807#comment-16806807 ] Benedict edited comment on CASSANDRA-14771 at 4/1/19 2:16 PM: -- That's what we agreed, as far as I recall, and continues to make sense to me. (edit: Hmm, I see my earlier comment doesn't make much sense, so yeah ignore that - your summary works) was (Author: benedict): That's what we agreed, as far as I recall, and continues to make sense to me. > Transient Replication: Writes at CL.ALL should block on all full replicas, > but not transients > -- > > Key: CASSANDRA-14771 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14771 > Project: Cassandra > Issue Type: Bug > Components: Feature/Transient Replication >Reporter: Ariel Weisberg >Priority: Normal > Fix For: 4.0 > > > Reading at ONE will still be safe because ONE only selects full replicas. > There is no reason to write to transients if we are going to block on all > full replicas. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14771) Transient Replication: Writes at CL.ALL should block on all full replicas, but not transients
[ https://issues.apache.org/jira/browse/CASSANDRA-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806807#comment-16806807 ] Benedict commented on CASSANDRA-14771: -- That's what we agreed, as far as I recall, and continues to make sense to me. > Transient Replication: Writes at CL.ALL should block on all full replicas, > but not transients > -- > > Key: CASSANDRA-14771 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14771 > Project: Cassandra > Issue Type: Bug > Components: Feature/Transient Replication >Reporter: Ariel Weisberg >Priority: Normal > Fix For: 4.0 > > > Reading at ONE will still be safe because ONE only selects full replicas. > There is no reason to write to transients if we are going to block on all > full replicas. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14771) Transient Replication: Writes at CL.ALL should block on all full replicas, but not transients
[ https://issues.apache.org/jira/browse/CASSANDRA-14771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806796#comment-16806796 ] Ariel Weisberg commented on CASSANDRA-14771: Noting this here so I don't forget. I think we need to preserve the property that if you wrote at ALL you will see the result of the write at ONE. So we can't acknowledge without writing to all full replicas. On top of that do we also want to not acknowledge a write at ALL unless we achieve QUORUM in each DC? > Transient Replication: Writes at CL.ALL should block on all full replicas, > but not transients > -- > > Key: CASSANDRA-14771 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14771 > Project: Cassandra > Issue Type: Bug > Components: Feature/Transient Replication >Reporter: Ariel Weisberg >Priority: Normal > Fix For: 4.0 > > > Reading at ONE will still be safe because ONE only selects full replicas. > There is no reason to write to transients if we are going to block on all > full replicas. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15071) Materialized View Inconsistent With Base Table Update After Migrating To New DC
Avraham Kalvo created CASSANDRA-15071: - Summary: Materialized View Inconsistent With Base Table Update After Migrating To New DC Key: CASSANDRA-15071 URL: https://issues.apache.org/jira/browse/CASSANDRA-15071 Project: Cassandra Issue Type: Bug Components: Consistency/Bootstrap and Decommission Reporter: Avraham Kalvo We've recently completed a successful migration between two data centers in our Cassandra cluster. After adding the new DC nodes onto the existing cluster, and setting the keyspaces to replicate to both DCs and rebuilding the new DC nodes from the old one, we've cut-over the applications using those keyspaces o start using the new DC exclusively by connecting to its end-points and performing `LOCAL_` consistency level requests there (DCAwareRoundRobinPolicy on LOCAL DC). We noticed that once the apps started to read data from the materialized views in the new DC, that an inconsistency emerged, which wasn't there in the original DC from which we've migrated. I.e - source/old DC had the materialized view reflecting the column update on the base table, while target/new DC didn't (the column value in the MV remained the same as it was in the base table, prior to the update). We only found out about it being logged with a support ticket, and for now, mitigated it by simply recreating the materialized view. Looking for a root cause for such behavior, is this expected, is this somewhat of a requirement which wasn't fulfilled yet for the MV mechanism, such as the ones mentioned in https://issues.apache.org/jira/browse/CASSANDRA-13826? Thanks, Avi K -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13357) A possible NPE in nodetool getendpoints
[
https://issues.apache.org/jira/browse/CASSANDRA-13357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-13357:
Reviewers: Eduard Tudenhoefner, mck
Status: Review In Progress (was: Patch Available)
> A possible NPE in nodetool getendpoints
> ---
>
> Key: CASSANDRA-13357
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13357
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Hao Zhong
>Assignee: Hao Zhong
>Priority: Normal
> Fix For: 4.x
>
> Attachments: cassandra.patch
>
>
> The GetEndpoints.execute method has the following code:
> {code:title=GetEndpoints.java|borderStyle=solid}
>List endpoints = probe.getEndpoints(ks, table, key);
> for (InetAddress endpoint : endpoints)
> {
> System.out.println(endpoint.getHostAddress());
> }
> {code}
> This code can throw NPE. A similar bug is fixed in CASSANDRA-8950. The buggy
> code is
> {code:title=NodeCmd.java|borderStyle=solid}
> List endpoints = this.probe.getEndpoints(keySpace, cf, key);
> for (InetAddress anEndpoint : endpoints)
> {
>output.println(anEndpoint.getHostAddress());
> }
> {code}
> The fixed code is:
> {code:title=NodeCmd.java|borderStyle=solid}
> try
> {
> List endpoints = probe.getEndpoints(keySpace, cf,
> key);
> for (InetAddress anEndpoint : endpoints)
>output.println(anEndpoint.getHostAddress());
> }
> catch (IllegalArgumentException ex)
> {
> output.println(ex.getMessage());
> probe.failed();
> }
> {code}
> The GetEndpoints.execute method shall be modified as CASSANDRA-8950 does.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15064) Wrong ordering for timeuuid fields
[
https://issues.apache.org/jira/browse/CASSANDRA-15064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806602#comment-16806602
]
Andreas Andersen commented on CASSANDRA-15064:
--
As for our use case we can simply use the gocql.TimeUUIDWith function
([https://github.com/gocql/gocql/blob/master/uuid.go#L132]) and supply our own
clock sequence. We will never have more than 2^14 images created on a single
second.
When it comes to the cassandra part, simply changing the underlying field from
a timeuuid to a uuid will solve all of our problems. It sorts in the way we
expect it to.
Having the behavior for timeuuid fields mentioned in the cassandra
documentation would have been sufficient for solving our problems - we would
simply have gone with the uuid datatype from the start. So simply adding more
information to the docs seems like a good solution to this issue :)
> Wrong ordering for timeuuid fields
> --
>
> Key: CASSANDRA-15064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15064
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Andreas Andersen
>Assignee: Jon Meredith
>Priority: Normal
> Attachments: example.cql
>
>
> Hi!
> We're seeing some strange behavior for the ordering of timeuuid fields. They
> seem to be sorted in the wrong order when the clock_seq_low field in a
> timeuuid goes from 7f to 80. Consider the following example:
> {noformat}
> cqlsh:test> show version;
> [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4]
> cqlsh:test> CREATE TABLE t (
> ... partition int,
> ... t timeuuid,
> ... i int,
> ...
> ... PRIMARY KEY(partition, t)
> ... )
> ... WITH CLUSTERING ORDER BY(t ASC);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57e-f0def1d0755e, 1);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57f-f0def1d0755e, 2);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b580-f0def1d0755e, 3);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b581-f0def1d0755e, 4);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b582-f0def1d0755e, 5);
> cqlsh:test> SELECT * FROM t WHERE partition = 1 ORDER BY t ASC;
>
> partition | t | i
> ---+--+---
> 1 | 84e2c963-4ef9-11e9-b580-f0def1d0755e | 3
> 1 | 84e2c963-4ef9-11e9-b581-f0def1d0755e | 4
> 1 | 84e2c963-4ef9-11e9-b582-f0def1d0755e | 5
> 1 | 84e2c963-4ef9-11e9-b57e-f0def1d0755e | 1
> 1 | 84e2c963-4ef9-11e9-b57f-f0def1d0755e | 2
>
> (5 rows)
> cqlsh:test>
> {noformat}
> The expected behavior is that the rows are returned in the same order as they
> were inserted (we inserted them with their clustering key in an ascending
> order). Instead, the order "wraps" in the middle.
> This issue only arises when the 9th octet (clock_seq_low) in the uuid goes
> from 7f to 80. A guess would be that the comparison is implemented as a
> signed integer instead of an unsigned integer, as 0x7f = 127 and 0x80 = -128.
> According to the RFC, the field should be treated as an unsigned integer:
> [https://tools.ietf.org/html/rfc4122#section-4.1.2]
> Changing the field from a timeuuid to a uuid gives the expected correct
> behavior:
> {noformat}
> cqlsh:test> CREATE TABLE t (
> ... partition int,
> ... t uuid,
> ... i int,
> ...
> ... PRIMARY KEY(partition, t)
> ... )
> ... WITH CLUSTERING ORDER BY(t ASC);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57e-f0def1d0755e, 1);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b57f-f0def1d0755e, 2);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b580-f0def1d0755e, 3);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b581-f0def1d0755e, 4);
> cqlsh:test> INSERT INTO t(partition, t, i) VALUES(1,
> 84e2c963-4ef9-11e9-b582-f0def1d0755e, 5);
> cqlsh:test> SELECT * FROM t WHERE partition = 1 ORDER BY t ASC;
>
> partition | t | i
> ---+--+---
> 1 | 84e2c963-4ef9-11e9-b57e-f0def1d0755e | 1
> 1 | 84e2c963-4ef9-11e9-b57f-f0def1d0755e | 2
> 1 | 84e2c963-4ef9-11e9-b580-f0def1d0755e | 3
> 1 | 84e2c963-4ef9-11e9-b581-f0def1d0755e | 4
> 1 | 84e2c963-4ef9-11e9-b582-f0def1d0755e | 5
>
> (5 rows)
> cqlsh:test>{noformat}
>
>
--
[jira] [Updated] (CASSANDRA-14950) Update comment link to mx4j in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14950: Fix Version/s: (was: 3.11.x) (was: 4.x) (was: 3.0.x) (was: 2.2.x) 4.0 3.11.5 3.0.19 2.2.15 Status: Resolved (was: Ready to Commit) Resolution: Fixed Committed as 6fc3df93b833c10128c976184add8d16f7aeec2e > Update comment link to mx4j in cassandra-env.sh > > > Key: CASSANDRA-14950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14950 > Project: Cassandra > Issue Type: Task > Components: Documentation/Javadoc >Reporter: Jearvon Dharrie >Assignee: Jearvon Dharrie >Priority: Low > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: 0001-Update-mx4j-url.patch > > > Seems this > [http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J] > has moved to http://cassandra.apache.org/doc/latest/operating/metrics.html#jmx > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 47910df834367e366528a5bcd186b291a409ef99 Merge: ba32595 6fc3df9 Author: Mick Semb Wever AuthorDate: Mon Apr 1 20:45:51 2019 +1100 Merge branch 'cassandra-2.2' into cassandra-3.0 conf/cassandra-env.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated: Update comment link to mx4j in cassandra-env.sh
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-2.2 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-2.2 by this push: new 6fc3df9 Update comment link to mx4j in cassandra-env.sh 6fc3df9 is described below commit 6fc3df93b833c10128c976184add8d16f7aeec2e Author: Mick Semb Wever AuthorDate: Mon Apr 1 20:40:19 2019 +1100 Update comment link to mx4j in cassandra-env.sh patch by Jearvon Dharrie; reviewed by Mick Semb Wever for CASSANDRA-14950 --- conf/cassandra-env.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh index 7b1b8d3..b394d5f 100644 --- a/conf/cassandra-env.sh +++ b/conf/cassandra-env.sh @@ -310,7 +310,7 @@ fi # To use mx4j, an HTML interface for JMX, add mx4j-tools.jar to the lib/ # directory. -# See http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J +# See http://cassandra.apache.org/doc/3.11/operating/metrics.html#jmx # By default mx4j listens on 0.0.0.0:8081. Uncomment the following lines # to control its listen address and port. #MX4J_ADDRESS="-Dmx4jaddress=127.0.0.1" - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 439c8278f00d0b571f66190e5572371f6e8e4e59 Merge: e49b25c 8ac2e42 Author: Mick Semb Wever AuthorDate: Mon Apr 1 20:50:02 2019 +1100 Merge branch 'cassandra-3.11' into trunk conf/cassandra-env.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --cc conf/cassandra-env.sh index dc30437,7f7081b..5c9844c --- a/conf/cassandra-env.sh +++ b/conf/cassandra-env.sh @@@ -263,11 -291,11 +263,11 @@@ JVM_OPTS="$JVM_OPTS -Dcom.sun.managemen # To use mx4j, an HTML interface for JMX, add mx4j-tools.jar to the lib/ # directory. - # See http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J -# See http://cassandra.apache.org/doc/3.11/operating/metrics.html#jmx ++# See http://cassandra.apache.org/doc/latest/operating/metrics.html#jmx # By default mx4j listens on 0.0.0.0:8081. Uncomment the following lines # to control its listen address and port. -#MX4J_ADDRESS="-Dmx4jaddress=127.0.0.1" -#MX4J_PORT="-Dmx4jport=8081" +#MX4J_ADDRESS="127.0.0.1" +#MX4J_PORT="8081" # Cassandra uses SIGAR to capture OS metrics CASSANDRA-7838 # for SIGAR we have to set the java.library.path - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (1152417 -> 8ac2e42)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 1152417 Merge branch 'cassandra-3.0' into cassandra-3.11 new 6fc3df9 Update comment link to mx4j in cassandra-env.sh new 47910df Merge branch 'cassandra-2.2' into cassandra-3.0 new 8ac2e42 Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: conf/cassandra-env.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 8ac2e4244dfd392fa1dab204ebea7f0c883d8e25 Merge: 1152417 47910df Author: Mick Semb Wever AuthorDate: Mon Apr 1 20:46:53 2019 +1100 Merge branch 'cassandra-3.0' into cassandra-3.11 conf/cassandra-env.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --cc conf/cassandra-env.sh index 8932985,43f4566..7f7081b --- a/conf/cassandra-env.sh +++ b/conf/cassandra-env.sh @@@ -250,48 -295,26 +250,48 @@@ f JMX_PORT="7199" if [ "$LOCAL_JMX" = "yes" ]; then - JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.local.port=$JMX_PORT -XX:+DisableExplicitGC" + JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.local.port=$JMX_PORT" + JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=false" else - JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.port=$JMX_PORT" + JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.remote.port=$JMX_PORT" + # if ssl is enabled the same port cannot be used for both jmx and rmi so either + # pick another value for this property or comment out to use a random port (though see CASSANDRA-7087 for origins) JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.rmi.port=$JMX_PORT" - JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl=false" + + # turn on JMX authentication. See below for further options JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=true" - JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password" -# JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/path/to/keystore" -# JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=" -# JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.trustStore=/path/to/truststore" -# JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.trustStorePassword=" -# JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl.need.client.auth=true" -# JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true" -# JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl.enabled.protocols=" -# JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl.enabled.cipher.suites=" + + # jmx ssl options + #JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl=true" + #JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl.need.client.auth=true" + #JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl.enabled.protocols=" + #JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl.enabled.cipher.suites=" + #JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/path/to/keystore" + #JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=" + #JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.trustStore=/path/to/truststore" + #JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.trustStorePassword=" fi +# jmx authentication and authorization options. By default, auth is only +# activated for remote connections but they can also be enabled for local only JMX +## Basic file based authn & authz +JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password" +#JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access" +## Custom auth settings which can be used as alternatives to JMX's out of the box auth utilities. +## JAAS login modules can be used for authentication by uncommenting these two properties. +## Cassandra ships with a LoginModule implementation - org.apache.cassandra.auth.CassandraLoginModule - +## which delegates to the IAuthenticator configured in cassandra.yaml. See the sample JAAS configuration +## file cassandra-jaas.config +#JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.remote.login.config=CassandraLogin" +#JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config=$CASSANDRA_HOME/conf/cassandra-jaas.config" + +## Cassandra also ships with a helper for delegating JMX authz calls to the configured IAuthorizer, +## uncomment this to use it. Requires one of the two authentication options to be enabled +#JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.authorizer=org.apache.cassandra.auth.jmx.AuthorizationProxy" + # To use mx4j, an HTML interface for JMX, add mx4j-tools.jar to the lib/ # directory. - # See http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J + # See http://cassandra.apache.org/doc/3.11/operating/metrics.html#jmx # By default mx4j listens on 0.0.0.0:8081. Uncomment the following lines # to control its listen address and port. #MX4J_ADDRESS="-Dmx4jaddress=127.0.0.1" - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (ba32595 -> 47910df)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ba32595 Fix handling FS errors on writing and reading flat files - LogTransaction and hints new 6fc3df9 Update comment link to mx4j in cassandra-env.sh new 47910df Merge branch 'cassandra-2.2' into cassandra-3.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: conf/cassandra-env.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (e49b25c -> 439c827)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e49b25c Documentation fix for Hint_delays metrics new 6fc3df9 Update comment link to mx4j in cassandra-env.sh new 47910df Merge branch 'cassandra-2.2' into cassandra-3.0 new 8ac2e42 Merge branch 'cassandra-3.0' into cassandra-3.11 new 439c827 Merge branch 'cassandra-3.11' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: conf/cassandra-env.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14950) Update comment link to mx4j in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14950: Status: Ready to Commit (was: Review In Progress) Will link to http://cassandra.apache.org/doc/3.11/operating/metrics.html#jmx for pre-trunk commits. > Update comment link to mx4j in cassandra-env.sh > > > Key: CASSANDRA-14950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14950 > Project: Cassandra > Issue Type: Task > Components: Documentation/Javadoc >Reporter: Jearvon Dharrie >Assignee: Jearvon Dharrie >Priority: Low > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > Attachments: 0001-Update-mx4j-url.patch > > > Seems this > [http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J] > has moved to http://cassandra.apache.org/doc/latest/operating/metrics.html#jmx > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14950) Update comment link to mx4j in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14950: Summary: Update comment link to mx4j in cassandra-env.sh (was: Update link to mx4j in cassandra-env.sh) > Update comment link to mx4j in cassandra-env.sh > > > Key: CASSANDRA-14950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14950 > Project: Cassandra > Issue Type: Task > Components: Documentation/Javadoc >Reporter: Jearvon Dharrie >Assignee: Jearvon Dharrie >Priority: Low > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > Attachments: 0001-Update-mx4j-url.patch > > > Seems this > [http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J] > has moved to http://cassandra.apache.org/doc/latest/operating/metrics.html#jmx > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Documentation fix for Hint_delays metrics
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new e49b25c Documentation fix for Hint_delays metrics e49b25c is described below commit e49b25c29faf7b83fe7c566d7b1657d9f599d750 Author: anupshirolkar AuthorDate: Thu Feb 21 12:57:41 2019 +1100 Documentation fix for Hint_delays metrics patch by Anup Shirolkar; reviewed by Dinesh Joshi and Mick Semb Wever for CASSANDRA-15015 --- doc/source/operating/metrics.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/source/operating/metrics.rst b/doc/source/operating/metrics.rst index 4f61bf2..e87bd5a 100644 --- a/doc/source/operating/metrics.rst +++ b/doc/source/operating/metrics.rst @@ -577,8 +577,8 @@ NameType Description HintsSucceeded Meter A meter of the hints successfully delivered HintsFailed Meter A meter of the hints that failed deliver HintsTimedOutMeter A meter of the hints that timed out -Hints_delays Histogram Histogram of hint delivery delays (in milliseconds) -Hints_delays-Histogram Histogram of hint delivery delays (in milliseconds) per peer +Hint_delays Histogram Histogram of hint delivery delays (in milliseconds) +Hint_delays-Histogram Histogram of hint delivery delays (in milliseconds) per peer === == === SSTable Index Metrics - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14950) Update link to mx4j in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14950: Fix Version/s: 4.x 3.11.x 3.0.x 2.2.x Component/s: Documentation/Javadoc > Update link to mx4j in cassandra-env.sh > --- > > Key: CASSANDRA-14950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14950 > Project: Cassandra > Issue Type: Task > Components: Documentation/Javadoc >Reporter: Jearvon Dharrie >Assignee: Jearvon Dharrie >Priority: Low > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > Attachments: 0001-Update-mx4j-url.patch > > > Seems this > [http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J] > has moved to http://cassandra.apache.org/doc/latest/operating/metrics.html#jmx > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14950) Update link to mx4j in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck reassigned CASSANDRA-14950: --- Assignee: Jearvon Dharrie > Update link to mx4j in cassandra-env.sh > --- > > Key: CASSANDRA-14950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14950 > Project: Cassandra > Issue Type: Task >Reporter: Jearvon Dharrie >Assignee: Jearvon Dharrie >Priority: Low > Attachments: 0001-Update-mx4j-url.patch > > > Seems this > [http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J] > has moved to http://cassandra.apache.org/doc/latest/operating/metrics.html#jmx > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14950) Update link to mx4j in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14950: Reviewers: mck Status: Review In Progress (was: Patch Available) > Update link to mx4j in cassandra-env.sh > --- > > Key: CASSANDRA-14950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14950 > Project: Cassandra > Issue Type: Task >Reporter: Jearvon Dharrie >Priority: Low > Attachments: 0001-Update-mx4j-url.patch > > > Seems this > [http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J] > has moved to http://cassandra.apache.org/doc/latest/operating/metrics.html#jmx > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-15015: Since Version: 4.0 Status: Resolved (was: Ready to Commit) Resolution: Fixed Committed as e49b25c29faf7b83fe7c566d7b1657d9f599d750 > Cassandra metrics documentation is not correct for Hint_delays metric > - > > Key: CASSANDRA-15015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15015 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Anup Shirolkar >Assignee: Anup Shirolkar >Priority: Low > Labels: documentation, easyfix, low-hanging-fruit > Fix For: 4.0 > > Attachments: 150150-trunk.txt > > > The Cassandra metrics for hint delays are not correctly referred on the > documentation web page: > [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics] > > The metrics are defined in the > [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52] > as 'Hint_delays' and 'Hint_delays-' but those are listed on the > website as 'Hints_delays' and 'Hints_delays-'. > The documentation should be fixed by removing the extra 's' in Hints to match > it with code. > The Jira for adding hint_delays: CASSANDRA-13234 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-15015: Status: Ready to Commit (was: Review In Progress) > Cassandra metrics documentation is not correct for Hint_delays metric > - > > Key: CASSANDRA-15015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15015 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Anup Shirolkar >Assignee: Anup Shirolkar >Priority: Low > Labels: documentation, easyfix, low-hanging-fruit > Fix For: 4.0 > > Attachments: 150150-trunk.txt > > > The Cassandra metrics for hint delays are not correctly referred on the > documentation web page: > [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics] > > The metrics are defined in the > [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52] > as 'Hint_delays' and 'Hint_delays-' but those are listed on the > website as 'Hints_delays' and 'Hints_delays-'. > The documentation should be fixed by removing the extra 's' in Hints to match > it with code. > The Jira for adding hint_delays: CASSANDRA-13234 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-15015: Status: Review In Progress (was: Patch Available) > Cassandra metrics documentation is not correct for Hint_delays metric > - > > Key: CASSANDRA-15015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15015 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Anup Shirolkar >Assignee: Anup Shirolkar >Priority: Low > Labels: documentation, easyfix, low-hanging-fruit > Fix For: 4.0 > > Attachments: 150150-trunk.txt > > > The Cassandra metrics for hint delays are not correctly referred on the > documentation web page: > [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics] > > The metrics are defined in the > [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52] > as 'Hint_delays' and 'Hint_delays-' but those are listed on the > website as 'Hints_delays' and 'Hints_delays-'. > The documentation should be fixed by removing the extra 's' in Hints to match > it with code. > The Jira for adding hint_delays: CASSANDRA-13234 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-15015: Reviewers: Dinesh Joshi, mck (was: mck) > Cassandra metrics documentation is not correct for Hint_delays metric > - > > Key: CASSANDRA-15015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15015 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Anup Shirolkar >Assignee: Anup Shirolkar >Priority: Low > Labels: documentation, easyfix, low-hanging-fruit > Fix For: 4.0 > > Attachments: 150150-trunk.txt > > > The Cassandra metrics for hint delays are not correctly referred on the > documentation web page: > [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics] > > The metrics are defined in the > [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52] > as 'Hint_delays' and 'Hint_delays-' but those are listed on the > website as 'Hints_delays' and 'Hints_delays-'. > The documentation should be fixed by removing the extra 's' in Hints to match > it with code. > The Jira for adding hint_delays: CASSANDRA-13234 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-15015: Fix Version/s: (was: 3.11.5) (was: 3.0.19) > Cassandra metrics documentation is not correct for Hint_delays metric > - > > Key: CASSANDRA-15015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15015 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Anup Shirolkar >Assignee: Anup Shirolkar >Priority: Low > Labels: documentation, easyfix, low-hanging-fruit > Fix For: 4.0 > > Attachments: 150150-trunk.txt > > > The Cassandra metrics for hint delays are not correctly referred on the > documentation web page: > [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics] > > The metrics are defined in the > [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52] > as 'Hint_delays' and 'Hint_delays-' but those are listed on the > website as 'Hints_delays' and 'Hints_delays-'. > The documentation should be fixed by removing the extra 's' in Hints to match > it with code. > The Jira for adding hint_delays: CASSANDRA-13234 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806547#comment-16806547 ] mck commented on CASSANDRA-15015: - LGTM. Only needs `Fix Version: 4.0`. And no need for the CHANGES entry (it's a small doc fix from the same version changelog). > Cassandra metrics documentation is not correct for Hint_delays metric > - > > Key: CASSANDRA-15015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15015 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Anup Shirolkar >Assignee: Anup Shirolkar >Priority: Low > Labels: documentation, easyfix, low-hanging-fruit > Fix For: 3.0.19, 3.11.5, 4.0 > > Attachments: 150150-trunk.txt > > > The Cassandra metrics for hint delays are not correctly referred on the > documentation web page: > [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics] > > The metrics are defined in the > [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52] > as 'Hint_delays' and 'Hint_delays-' but those are listed on the > website as 'Hints_delays' and 'Hints_delays-'. > The documentation should be fixed by removing the extra 's' in Hints to match > it with code. > The Jira for adding hint_delays: CASSANDRA-13234 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15015) Cassandra metrics documentation is not correct for Hint_delays metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-15015: Complexity: Low Hanging Fruit Reviewers: mck > Cassandra metrics documentation is not correct for Hint_delays metric > - > > Key: CASSANDRA-15015 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15015 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Anup Shirolkar >Assignee: Anup Shirolkar >Priority: Low > Labels: documentation, easyfix, low-hanging-fruit > Fix For: 3.0.19, 3.11.5, 4.0 > > Attachments: 150150-trunk.txt > > > The Cassandra metrics for hint delays are not correctly referred on the > documentation web page: > [http://cassandra.apache.org/doc/latest/operating/metrics.html#hintsservice-metrics] > > The metrics are defined in the > [code|https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/src/java/org/apache/cassandra/metrics/HintsServiceMetrics.java#L45-L52] > as 'Hint_delays' and 'Hint_delays-' but those are listed on the > website as 'Hints_delays' and 'Hints_delays-'. > The documentation should be fixed by removing the extra 's' in Hints to match > it with code. > The Jira for adding hint_delays: CASSANDRA-13234 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15070) coredump in cqlsh
Chakravarthi Manepalli created CASSANDRA-15070: -- Summary: coredump in cqlsh Key: CASSANDRA-15070 URL: https://issues.apache.org/jira/browse/CASSANDRA-15070 Project: Cassandra Issue Type: Bug Components: Tool/cqlsh Reporter: Chakravarthi Manepalli Cqlsh crashes with coredump when given ctrl+| or ctrl+\ or ctrl+4. Moreover it becomes unresponsive if ctrl+s is given. It is observed in apache cassandra 3.11 and dse 6.7.2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15049) Requests blocked at NTR stage should be rejected
[
https://issues.apache.org/jira/browse/CASSANDRA-15049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806417#comment-16806417
]
Sumanth Pasupuleti commented on CASSANDRA-15049:
FYI, I have submitted a patch on CASSANDRA-15013.
> Requests blocked at NTR stage should be rejected
>
>
> Key: CASSANDRA-15049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15049
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michaël Figuière
>Priority: Normal
>
> CASSANDRA-11363 has emphasized that if the NTR stage's thread pool and queue
> are full, the Netty Event Loops may block waiting on the NTR queue. The
> solution that was brought in CASSANDRA-11363 was to increase the default
> queue size from 128 to 1024. This significantly reduced the number of blocked
> requests observed but hasn't removed the problem entirely. Whenever a Netty
> Event Loop is blocked, the responsiveness of Cassandra is significantly
> impacted so it seems inappropriate to rely solely on increasing this queue
> size until everything looks fine... at the time the tuning was done.
> In fact, this situation looks exactly like the definition of the
> {{Overloaded}} error of the CQL Protocol:
> {code:java}
> 0x1001 Overloaded: the request cannot be processed because the
> coordinator node is overloaded{code}
> Therefore, whenever a request can't make it to the NTR stage, it should be
> rejected with an {{Overloaded}} error to the client. This can be done at low
> cost as we're already in the Netty Event Loop owning the channel to that
> client.
> It would then be the client responsibility to retry with another coordinator,
> which is likely to lead to a better P99 latency than blocking on an already
> too long queue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[ https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumanth Pasupuleti updated CASSANDRA-15013: --- Test and Documentation Plan: Pull Request: https://github.com/apache/cassandra/pull/308 Passing UTs: https://circleci.com/gh/sumanth-pasupuleti/cassandra/261 Passing JVM DTests: https://circleci.com/gh/sumanth-pasupuleti/cassandra/260 Passing DTests with vnodes: https://circleci.com/gh/sumanth-pasupuleti/cassandra/262 DTests without vnodes with two failures: https://circleci.com/gh/sumanth-pasupuleti/cassandra/263 (looking into the two failures) Status: Patch Available (was: In Progress) > Message Flusher queue can grow unbounded, potentially running JVM out of > memory > --- > > Key: CASSANDRA-15013 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15013 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 3.0.x, 3.11.x > > Attachments: BlockedEpollEventLoopFromHeapDump.png, > BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap > dump showing each ImmediateFlusher taking upto 600MB.png > > > This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue > bounded, since, in the current state, items get added to the queue without > any checks on queue size, nor with any checks on netty outbound buffer to > check the isWritable state. > We are seeing this issue hit our production 3.0 clusters quite often. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[ https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumanth Pasupuleti updated CASSANDRA-15013: --- Reviewers: Benedict Labels: pull-request-available (was: ) > Message Flusher queue can grow unbounded, potentially running JVM out of > memory > --- > > Key: CASSANDRA-15013 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15013 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Labels: pull-request-available > Fix For: 4.0, 3.0.x, 3.11.x > > Attachments: BlockedEpollEventLoopFromHeapDump.png, > BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap > dump showing each ImmediateFlusher taking upto 600MB.png > > > This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue > bounded, since, in the current state, items get added to the queue without > any checks on queue size, nor with any checks on netty outbound buffer to > check the isWritable state. > We are seeing this issue hit our production 3.0 clusters quite often. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15013) Message Flusher queue can grow unbounded, potentially running JVM out of memory
[ https://issues.apache.org/jira/browse/CASSANDRA-15013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806412#comment-16806412 ] Sumanth Pasupuleti commented on CASSANDRA-15013: [~benedict] Pull Request: https://github.com/apache/cassandra/pull/308 Passing UTs: https://circleci.com/gh/sumanth-pasupuleti/cassandra/261 Passing JVM DTests: https://circleci.com/gh/sumanth-pasupuleti/cassandra/260 Passing DTests with vnodes: https://circleci.com/gh/sumanth-pasupuleti/cassandra/262 DTests without vnodes with two failures: https://circleci.com/gh/sumanth-pasupuleti/cassandra/263 (looking into the two failures) > Message Flusher queue can grow unbounded, potentially running JVM out of > memory > --- > > Key: CASSANDRA-15013 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15013 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > Attachments: BlockedEpollEventLoopFromHeapDump.png, > BlockedEpollEventLoopFromThreadDump.png, RequestExecutorQueueFull.png, heap > dump showing each ImmediateFlusher taking upto 600MB.png > > > This is a follow-up ticket out of CASSANDRA-14855, to make the Flusher queue > bounded, since, in the current state, items get added to the queue without > any checks on queue size, nor with any checks on netty outbound buffer to > check the isWritable state. > We are seeing this issue hit our production 3.0 clusters quite often. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
