[jira] [Updated] (CASSANDRA-14073) Prevent replacement nodes from skipping bootstrapping without allow_unsafe_replace:true
[ https://issues.apache.org/jira/browse/CASSANDRA-14073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kurt Greaves updated CASSANDRA-14073: - Labels: bootstrap patch (was: patch) > Prevent replacement nodes from skipping bootstrapping without > allow_unsafe_replace:true > --- > > Key: CASSANDRA-14073 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14073 > Project: Cassandra > Issue Type: Bug > Components: Configuration >Reporter: Vincent White >Assignee: Vincent White >Priority: Minor > Labels: bootstrap, patch > Fix For: 3.11.x > > > I've noticed that when replacing a node with replace_address it can skip > bootstrapping if it is listed in its own seed list. This probably shouldn't > be allowed without the allow_unsafe_replace option set to true as is required > when using auto_bootstrap: false in combination with replace_address. Patch > [here|https://github.com/vincewhite/cassandra/commits/replace_address_seed_list] > and an attempt at a dtest > [here|https://github.com/vincewhite/cassandra-dtest/commits/unsafe_replace]. -- 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-14415) Performance regression in queries for distinct keys
[
https://issues.apache.org/jira/browse/CASSANDRA-14415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473681#comment-16473681
]
Kurt Greaves commented on CASSANDRA-14415:
--
[~sklock] responding as per your request on the ML:
{quote}Can someone please take a look at CASSANDRA-14415 when you have chance?
Getting a fix into a Cassandra release is not especially urgent for us,
but in lieu of that we would like to know whether it's safe to include
in our local build of Cassandra before attempting to deploy it.
{quote}
Seems to me that it would be fine. If you want to be sure (and this is probably
a good idea w.r.t patching 3.11 anyway) you could write a test that ensures the
behaviour of {{RAR.skipBytes()}} is always what you'd expect from
{{RIS.skipBytes()}}.
Only thing I didn't fully understand w.r.t patch is
{code}
if (n < 0 || buffer == null)
return super.skipBytes(n);
{code}
In the case that n < 0, delegating back to {{RIS.skipBytes()}} will return the
same thing, and in the case that buffer == null, {{RIS.skipBytes()}} will NPE.
If the extra check is necessary seems to me it should apply to both methods,
but all you can do is return 0. Might be better to just leave the extra check
out...?
> Performance regression in queries for distinct keys
> ---
>
> Key: CASSANDRA-14415
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14415
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Samuel Klock
>Assignee: Samuel Klock
>Priority: Major
> Labels: performance
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Running Cassandra 3.0.16, we observed a major performance regression
> affecting {{SELECT DISTINCT keys}}-style queries against certain tables.
> Based on some investigation (guided by some helpful feedback from Benjamin on
> the dev list), we tracked the regression down to two problems.
> * One is that Cassandra was reading more data from disk than was necessary
> to satisfy the query. This was fixed under CASSANDRA-10657 in a later 3.x
> release.
> * If the fix for CASSANDRA-10657 is incorporated, the other is this code
> snippet in {{RebufferingInputStream}}:
> {code:java}
> @Override
> public int skipBytes(int n) throws IOException
> {
> if (n < 0)
> return 0;
> int requested = n;
> int position = buffer.position(), limit = buffer.limit(), remaining;
> while ((remaining = limit - position) < n)
> {
> n -= remaining;
> buffer.position(limit);
> reBuffer();
> position = buffer.position();
> limit = buffer.limit();
> if (position == limit)
> return requested - n;
> }
> buffer.position(position + n);
> return requested;
> }
> {code}
> The gist of it is that to skip bytes, the stream needs to read those bytes
> into memory then throw them away. In our tests, we were spending a lot of
> time in this method, so it looked like the chief drag on performance.
> We noticed that the subclass of {{RebufferingInputStream}} in use for our
> queries, {{RandomAccessReader}} (over compressed sstables), implements a
> {{seek()}} method. Overriding {{skipBytes()}} in it to use {{seek()}}
> instead was sufficient to fix the performance regression.
> The performance difference is significant for tables with large values. It's
> straightforward to evaluate with very simple key-value tables, e.g.:
> {{CREATE TABLE testtable (key TEXT PRIMARY KEY, value BLOB);}}
> We did some basic experimentation with the following variations (all in a
> single-node 3.11.2 cluster with off-the-shelf settings running on a dev
> workstation):
> * small values (1 KB, 100,000 entries), somewhat larger values (25 KB,
> 10,000 entries), and much larger values (1 MB, 10,000 entries);
> * compressible data (a single byte repeated) and uncompressible data (output
> from {{openssl rand $bytes}}); and
> * with and without sstable compression. (With compression, we use
> Cassandra's defaults.)
> The difference is most conspicuous for tables with large, uncompressible data
> and sstable decompression (which happens to describe the use case that
> triggered our investigation). It is smaller but still readily apparent for
> tables with effective compression. For uncompressible data without
> compression enabled, there is no appreciable difference.
> Here's what the performance looks like without our patch for the 1-MB entries
> (times in seconds, five consecutive runs for each data set, all exhausting
> the results from a {{SELECT DISTINCT key FROM ...}} query with a page size of
> 24):
> {noformat}
> working on compressible
> 5.21180510521
> 5.10270500183
>
[jira] [Assigned] (CASSANDRA-13960) update cassandra.yaml links to point to new docs instead of the wiki
[
https://issues.apache.org/jira/browse/CASSANDRA-13960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murukesh Mohanan reassigned CASSANDRA-13960:
Assignee: Gabriel Nobrega
> update cassandra.yaml links to point to new docs instead of the wiki
>
>
> Key: CASSANDRA-13960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13960
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jon Haddad
>Assignee: Gabriel Nobrega
>Priority: Minor
> Labels: lhf
>
> The wiki is dead, let's clean up the links and be sure we have the right into
> on cassandra.apache.org.
> {code}
> # NOTE:
> # See http://wiki.apache.org/cassandra/StorageConfiguration for
> # full explanations of configuration directives
> # /NOTE
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13960) update cassandra.yaml links to point to new docs instead of the wiki
[
https://issues.apache.org/jira/browse/CASSANDRA-13960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473678#comment-16473678
]
Gabriel Nobrega commented on CASSANDRA-13960:
-
Hi, I'm looking for contribute to cassandra project and this task apparently is
simple for first contributors. Can you assign the task to me?
> update cassandra.yaml links to point to new docs instead of the wiki
>
>
> Key: CASSANDRA-13960
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13960
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jon Haddad
>Priority: Minor
> Labels: lhf
>
> The wiki is dead, let's clean up the links and be sure we have the right into
> on cassandra.apache.org.
> {code}
> # NOTE:
> # See http://wiki.apache.org/cassandra/StorageConfiguration for
> # full explanations of configuration directives
> # /NOTE
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14051) Many materialized_views_test are busted
[
https://issues.apache.org/jira/browse/CASSANDRA-14051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473675#comment-16473675
]
Kurt Greaves commented on CASSANDRA-14051:
--
Ran {{add_node_after_very_wide_mv_test}} around 300 times over the weekend with
no failures, so pretty sure the AE has been fixed since November.
> Many materialized_views_test are busted
> ---
>
> Key: CASSANDRA-14051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14051
> Project: Cassandra
> Issue Type: Bug
> Components: Testing
>Reporter: Michael Kjellman
>Assignee: Kurt Greaves
>Priority: Major
>
> Many materialized_views_test are busted... For now we should disable the
> entire MV test suite until effort is put into making these test usable and
> helpful. Currently they aren't helpful and almost all fail.
> test_base_column_in_view_pk_commutative_tombstone_without_flush -
> materialized_views_test.TestMaterializedViews
> test_base_column_in_view_pk_complex_timestamp_with_flush -
> materialized_views_test.TestMaterializedViews
> add_dc_after_mv_network_replication_test -
> materialized_views_test.TestMaterializedViews
> add_dc_after_mv_simple_replication_test -
> materialized_views_test.TestMaterializedViews
> add_node_after_mv_test - materialized_views_test.TestMaterializedViews
> add_node_after_very_wide_mv_test -
> materialized_views_test.TestMaterializedViews
> add_node_after_wide_mv_with_range_deletions_test -
> materialized_views_test.TestMaterializedViews
--
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-13121) repair progress message breaks legacy JMX support
[
https://issues.apache.org/jira/browse/CASSANDRA-13121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16473335#comment-16473335
]
mck edited comment on CASSANDRA-13121 at 5/13/18 10:58 PM:
---
[~ptbannister], i've put in your patches for testing (including your dtest
change).
I'll take a closer look at the code and can commit if all looks ok.
|| Branch || uTest || aTest || dTest ||
|
[cassandra-3.0_13121|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-3.0_13121]|[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.0_13121.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.0_13121]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/29/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/29]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/556/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/556]
|
|
[cassandra-3.11_13121|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-3.11_13121]
|[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_13121.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_13121
]|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/30/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/30]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/557/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/557]
|
|
[dtest_13121|https://github.com/thelastpickle/cassandra-dtest/tree/mck/CASSANDRA-13121]
|[!https://travis-ci.org/thelastpickle/cassandra-dtest.svg?branch=mck%2FCASSANDRA-13121!|https://travis-ci.org/thelastpickle/cassandra-dtest/builds/378499306]|
| |
was (Author: michaelsembwever):
[~ptbannister], i've put in your patches for testing (including your dtest
change).
I'll take a closer look at the code and can commit if all looks ok.
|| Branch || uTest || aTest || dTest ||
|
[cassandra-3.0_13121|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-3.0_13121]|[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.0_13121.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.0_13121]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/29/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/29]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/556/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/556]
|
|
[cassandra-3.11_13121|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-3.11_13121]
|[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_13121.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_13121
]|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/30/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/30]
|
[!https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/557/badge/icon!|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/557]
|
|
[dtest_13121|https://github.com/thelastpickle/cassandra-dtest/tree/mck/CASSANDRA-13121]
|[!https://circleci.com/gh/thelastpickle/workflows/cassandra-dtest/tree/mck%2FCASSANDRA-13121.svg?style=svg!|https://circleci.com/gh/thelastpickle/workflows/cassandra-dtest/tree/mck%2FCASSANDRA-13121]|
| |
> repair progress message breaks legacy JMX support
> -
>
> Key: CASSANDRA-13121
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13121
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
>Reporter: Scott Bale
>Assignee: Patrick Bannister
>Priority: Minor
> Labels: jmx, lhf, notifications, repair
> Fix For: 3.0.x, 3.11.x
>
> Attachments: 13121-3.0.txt
>
>
> The error progress message in {{RepairRunnable}} is not compliant with the
> {{LegacyJMXProgressSupport}} class, which uses a regex to match on the text
> of a progress event. Therefore, actual failures slip through as successes if
> using legacy JMX for repairs.
> In {{RepairRunnable}}
> {code}
> protected void fireErrorAndComplete(String tag, int progressCount, int
> totalProgress, String message)
> {
> fireProgressEvent(tag, new ProgressEvent(ProgressEventType.ERROR,
> progressCount, totalProgress, message));
>
