[jira] [Commented] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.
[ https://issues.apache.org/jira/browse/CASSANDRA-15319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937275#comment-16937275 ] Jon Meredith commented on CASSANDRA-15319: -- [2.2|https://circleci.com/workflow-run/b10df64e-eb8c-43e4-81d6-cea5f8afda8c] [3.0|https://circleci.com/workflow-run/3f31614b-dbeb-4f18-8995-dd8deb3b47ce] [3.11|https://circleci.com/workflow-run/6e9c2cff-901e-4e74-a9a6-225d80ba510f] [trunk|https://circleci.com/workflow-run/cb161886-9ce3-4d08-aa19-111f1ebce953] > Add support for network topology and tracing to in-JVM dtests. > -- > > Key: CASSANDRA-15319 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15319 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > While working on CASSANDRA-15318, testing it properly with an in-JVM test > requires setting up the network topology and tracing requests to check which > nodes performed forwarding. > > In support of testing, make it possible to create in-JVM clusters with nodes > appearing in different datacenter/racks and add support for executing queries > with tracing enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.
[ https://issues.apache.org/jira/browse/CASSANDRA-15319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937273#comment-16937273 ] Jon Meredith commented on CASSANDRA-15319: -- Thanks for the feedback from both of you. I've merged in Dinesh's suggestions which clean things up nicely and in the process discovered some places where Instances were being called before they had run startup() by calling IInstance.getMessageVersion/IInstance.getSchemaVersion. With all that fixed, the in-jvm single version and upgrade version tests now pass on my local machine on all supported versions (no 2.2 upgrade tests). Branches pushed up to let CircleCI have another swing at it. > Add support for network topology and tracing to in-JVM dtests. > -- > > Key: CASSANDRA-15319 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15319 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > While working on CASSANDRA-15318, testing it properly with an in-JVM test > requires setting up the network topology and tracing requests to check which > nodes performed forwarding. > > In support of testing, make it possible to create in-JVM clusters with nodes > appearing in different datacenter/racks and add support for executing queries > with tracing enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14683) Pagestate is null after 2^31 rows
[
https://issues.apache.org/jira/browse/CASSANDRA-14683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937268#comment-16937268
]
Jeremiah Jordan commented on CASSANDRA-14683:
-
+1 for interpreting MAX as “all the rows”. Someone sending that value in the
limit is most likely trying to get everything.
> Pagestate is null after 2^31 rows
> -
>
> Key: CASSANDRA-14683
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14683
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Abhishek
>Priority: Normal
>
> I am using the nodejs driver to take a dump of my table via
> [pagination|http://datastax.github.io/nodejs-driver/features/paging/#manual-paging]
> for a simple query.
> My query is \{{select * from mytable}}
> The table has close to 4 billion rows and cassandra stops returning results
> exactly after 2147483647 rows. The pagestate is not returned after this.
> Cassandra version - 3.0.9
> Nodejs cassandra driver version - 3.5.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15335) Node can corrupt gossip state and become unreplaceable
[
https://issues.apache.org/jira/browse/CASSANDRA-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-15335:
Bug Category: Parent values: Correctness(12982)Level 1 values:
Consistency(12989)
Complexity: Normal
Component/s: Cluster/Gossip
Discovered By: User Report
Fix Version/s: 4.0
3.11.5
3.0.19
Severity: Low
Assignee: Blake Eggleston
Status: Open (was: Triage Needed)
> Node can corrupt gossip state and become unreplaceable
> --
>
> Key: CASSANDRA-15335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15335
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 3.0.19, 3.11.5, 4.0
>
>
> In {{StorageService#prepareToJoin}}, a starting node first sends out an
> endpoint state without any tokens. Later, in
> {{StorageService#finishJoiningRing}} it sends out an endpoint state _with_
> it’s tokens. If that node dies between these 2 events and cannot be restarted
> due to some unrecoverable error, the ring’s gossip state will be missing
> tokens for that node. This won’t cause any immediate data loss since TMD is
> populated from system.peers, but it will prevent a replacement node from
> associating that address with it’s tokens and replacing it. It could also
> cause data loss if other nodes are added to the ring and don’t see an owned
> token where there should be one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15296:
-
Fix Version/s: 4.0-alpha
Since Version: 4.0
Source Control Link:
https://github.com/apache/cassandra/commit/a7f89688e5b4fdc2f8990fc42cb593da4f6a923f
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed. Thanks for the report [~dvohra] and patch [~rha].
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Fix For: 4.0-alpha
>
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix Zstd compression level documentation
This is an automated email from the ASF dual-hosted git repository. djoshi 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 a7f8968 Fix Zstd compression level documentation a7f8968 is described below commit a7f89688e5b4fdc2f8990fc42cb593da4f6a923f Author: Romain Hardouin AuthorDate: Tue Sep 24 11:20:54 2019 -0700 Fix Zstd compression level documentation Patch by Romain Hardouin; Reviewed by Dinesh Joshi for CASSANDRA-15296 --- doc/source/operating/compression.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/source/operating/compression.rst b/doc/source/operating/compression.rst index 42a057b..b4308b3 100644 --- a/doc/source/operating/compression.rst +++ b/doc/source/operating/compression.rst @@ -38,7 +38,9 @@ default, three options are relevant: - ``chunk_length_in_kb`` specifies the number of kilobytes of data per compression chunk. The default is 64KB. - ``crc_check_chance`` determines how likely Cassandra is to verify the checksum on each compression chunk during reads. The default is 1.0. -- ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts values between ``-131072`` and ``2``. +- ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts values between ``-131072`` and ``22``. +The lower the level, the faster the speed (at the cost of compression). Values from 20 to 22 are called +"ultra levels" and should be used with caution, as they require more memory. The default is 3. Users can set compression using the following syntax: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15296:
-
Reviewers: Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi)
Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi)
Status: Review In Progress (was: Patch Available)
+1 LGTM
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15296:
-
Status: Ready to Commit (was: Review In Progress)
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15335) Node can corrupt gossip state and become unreplaceable
[
https://issues.apache.org/jira/browse/CASSANDRA-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937077#comment-16937077
]
Brandon Williams commented on CASSANDRA-15335:
--
I _think_ that's just an artifact of how the code is organized. I can't think
of a reason not to advertise them if we know they are set.
> Node can corrupt gossip state and become unreplaceable
> --
>
> Key: CASSANDRA-15335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15335
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Priority: Normal
>
> In {{StorageService#prepareToJoin}}, a starting node first sends out an
> endpoint state without any tokens. Later, in
> {{StorageService#finishJoiningRing}} it sends out an endpoint state _with_
> it’s tokens. If that node dies between these 2 events and cannot be restarted
> due to some unrecoverable error, the ring’s gossip state will be missing
> tokens for that node. This won’t cause any immediate data loss since TMD is
> populated from system.peers, but it will prevent a replacement node from
> associating that address with it’s tokens and replacing it. It could also
> cause data loss if other nodes are added to the ring and don’t see an owned
> token where there should be one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15335) Node can corrupt gossip state and become unreplaceable
[
https://issues.apache.org/jira/browse/CASSANDRA-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937067#comment-16937067
]
Blake Eggleston edited comment on CASSANDRA-15335 at 9/24/19 6:17 PM:
--
[~brandon.williams] do you know if there's a problem we're trying to avoid by
omitting tokens in the first endpoint state? It seems like, if system.local
says we've bootstrapped and has tokens, we should be ok to include them
was (Author: bdeggleston):
[~brandon.williams] do you know if there's a problem we're trying to avoid by
omitting tokens in the first endpoint state?
> Node can corrupt gossip state and become unreplaceable
> --
>
> Key: CASSANDRA-15335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15335
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Priority: Normal
>
> In {{StorageService#prepareToJoin}}, a starting node first sends out an
> endpoint state without any tokens. Later, in
> {{StorageService#finishJoiningRing}} it sends out an endpoint state _with_
> it’s tokens. If that node dies between these 2 events and cannot be restarted
> due to some unrecoverable error, the ring’s gossip state will be missing
> tokens for that node. This won’t cause any immediate data loss since TMD is
> populated from system.peers, but it will prevent a replacement node from
> associating that address with it’s tokens and replacing it. It could also
> cause data loss if other nodes are added to the ring and don’t see an owned
> token where there should be one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15335) Node can corrupt gossip state and become unreplaceable
[
https://issues.apache.org/jira/browse/CASSANDRA-15335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937067#comment-16937067
]
Blake Eggleston commented on CASSANDRA-15335:
-
[~brandon.williams] do you know if there's a problem we're trying to avoid by
omitting tokens in the first endpoint state?
> Node can corrupt gossip state and become unreplaceable
> --
>
> Key: CASSANDRA-15335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15335
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Priority: Normal
>
> In {{StorageService#prepareToJoin}}, a starting node first sends out an
> endpoint state without any tokens. Later, in
> {{StorageService#finishJoiningRing}} it sends out an endpoint state _with_
> it’s tokens. If that node dies between these 2 events and cannot be restarted
> due to some unrecoverable error, the ring’s gossip state will be missing
> tokens for that node. This won’t cause any immediate data loss since TMD is
> populated from system.peers, but it will prevent a replacement node from
> associating that address with it’s tokens and replacing it. It could also
> cause data loss if other nodes are added to the ring and don’t see an owned
> token where there should be one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15335) Node can corrupt gossip state and become unreplaceable
Blake Eggleston created CASSANDRA-15335:
---
Summary: Node can corrupt gossip state and become unreplaceable
Key: CASSANDRA-15335
URL: https://issues.apache.org/jira/browse/CASSANDRA-15335
Project: Cassandra
Issue Type: Bug
Reporter: Blake Eggleston
In {{StorageService#prepareToJoin}}, a starting node first sends out an
endpoint state without any tokens. Later, in
{{StorageService#finishJoiningRing}} it sends out an endpoint state _with_ it’s
tokens. If that node dies between these 2 events and cannot be restarted due to
some unrecoverable error, the ring’s gossip state will be missing tokens for
that node. This won’t cause any immediate data loss since TMD is populated from
system.peers, but it will prevent a replacement node from associating that
address with it’s tokens and replacing it. It could also cause data loss if
other nodes are added to the ring and don’t see an owned token where there
should be one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937023#comment-16937023
]
Jon Haddad commented on CASSANDRA-15241:
Much nicer [~cnlwsu]. I promised you a tlp-stress profile that lets us hammer
virtual tables, and I haven't forgotten about it. I'll have it next week when
I get back from vacation.
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15299:
-
Description:
CASSANDRA-13304 made an important improvement to our native protocol: it
introduced checksumming/CRC32 to request and response bodies. It’s an important
step forward, but it doesn’t cover the entire stream. In particular, the
message header is not covered by a checksum or a crc, which poses a correctness
issue if, for example, {{streamId}} gets corrupted.
Additionally, we aren’t quite using CRC32 correctly, in two ways:
1. We are calculating the CRC32 of the *decompressed* value instead of
computing the CRC32 on the bytes written on the wire - losing the properties of
the CRC32. In some cases, due to this sequencing, attempting to decompress a
corrupt stream can cause a segfault by LZ4.
2. When using CRC32, the CRC32 value is written in the incorrect byte order,
also losing some of the protections.
See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
explanation for the two points above.
Separately, there are some long-standing issues with the protocol - since *way*
before CASSANDRA-13304. Importantly, both checksumming and compression operate
on individual message bodies rather than frames of multiple complete messages.
In reality, this has several important additional downsides. To name a couple:
# For compression, we are getting poor compression ratios for smaller messages
- when operating on tiny sequences of bytes. In reality, for most small
requests and responses we are discarding the compressed value as it’d be
smaller than the uncompressed one - incurring both redundant allocations and
compressions.
# For checksumming and CRC32 we pay a high overhead price for small messages. 4
bytes extra is *a lot* for an empty write response, for example.
To address the correctness issue of {{streamId}} not being covered by the
checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
should switch to a framing protocol with multiple messages in a single frame.
I suggest we reuse the framing protocol recently implemented for internode
messaging in CASSANDRA-15066 to the extent that its logic can be borrowed, and
that we do it before native protocol v5 graduates from beta. See
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
and
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
was:
CASSANDRA-13304 made an important improvement to our native protocol: it
introduced checksumming/CRC32 to request and response bodies. It’s an important
step forward, but it doesn’t cover the entire stream. In parcicular, the
message header is not covered by a checksum or a crc, which poses a correctness
issue if, for example, {{streamId}} gets corrupted.
Additionally, we aren’t quite using CRC32 correctly, in two ways:
1. We are calculating the CRC32 of the *decompressed* value instead of
computing the CRC32 on the bytes written on the wire - losing the properties of
the CRC32. In some cases, due to this sequencing, attempting to decompress a
corrupt stream can cause a segfault by LZ4.
2. When using CRC32, the CRC32 value is written in the incorrect byte order,
also losing some of the protections.
See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
explanation for the two points above.
Separately, there are some long-standing issues with the protocol - since *way*
before CASSANDRA-13304. Importantly, both checksumming and compression operate
on individual message bodies rather than frames of multiple complete messages.
In reality, this has several important additional downsides. To name a couple:
# For compression, we are getting poor compression ratios for smaller messages
- when operating on tiny sequences of bytes. In reality, for most small
requests and responses we are discarding the compressed value as it’d be
smaller than the uncompressed one - incurring both redundant allocations and
compressions.
# For checksumming and CRC32 we pay a high overhead price for small messages. 4
bytes extra is *a lot* for an empty write response, for example.
To address the correctness issue of {{streamId}} not being covered by the
checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
should switch to a framing protocol with multiple messages in a single frame.
I suggest we reuse the framing protocol recently implemented for internode
messaging in CASSANDRA-15066 to the extent that its logic can be borrowed, and
that we do it before native protocol v5 graduates from beta. See
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
and
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/Frame
[jira] [Comment Edited] (CASSANDRA-14655) Upgrade C* to use latest guava (27.0)
[
https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16936427#comment-16936427
]
mck edited comment on CASSANDRA-14655 at 9/24/19 2:35 PM:
--
[~sumanth.pasupuleti],
- unit tests look good,
- i think the {{"cassandra-driver-core"}} lines in the build.xml can now be
updated and uncommented, see {{"UPDATE AND UNCOMMENT"}} sections,
- for LoaderOptions and CqlConfigHelper are there docs we want to update? (ie
to use `host:port`?
- is the {{nativePort}} parameter needed anymore in
{{NativeSSTableLoaderClient}}'s constructor? the caller can put that into the
{{hosts}} parameter, (and then in the {{init(..)}} method (line 73) the cluster
builder called instead with {{addContactPointsWithPorts(hosts)}},
- i am still looking into the dtests…
bq. … the caller can put that into the {{hosts}} parameter, …
For example it looks like {{CqlBulkRecordWriter}} (in the call to
{{resolveHostAddresses}}), while {{BulkLoader}}+{{LoaderOptions}} could be
doing similar if {{LoaderOptions.Builder.build()}} looped through its {{hosts}}
and put in {{nativePort}} when undefined.
was (Author: michaelsembwever):
[~sumanth.pasupuleti],
- unit tests look good,
- i think the {{"cassandra-driver-core"}} lines in the build.xml can now be
updated and uncommented, see {{"UPDATE AND UNCOMMENT"}} sections,
- for LoaderOptions and CqlConfigHelper are there docs we want to update? (ie
to use `host:port`?
- is the {{nativePort}} parameter needed anymore in
{{NativeSSTableLoaderClient}}'s constructor? the caller can put that into the
{{hosts}} parameter, (and then in the {{init(..)}} method (line 73) the cluster
builder called instead with {{addContactPointsWithPorts(hosts)}},
- i am still looking into the dtests…
bq. … the caller can put that into the {{hosts}} parameter, …
For example it looks like {{CqlBulkRecordWriter}} (in the call to
{{resolveHostAddresses}}), while {{BulkLoader}}+{{LoaderOptions}} could be
doing similar if {{LoaderOptions.Builder.build()}} looped through its {{hosts}}
and put in {{nativePort}} when undefined.
> Upgrade C* to use latest guava (27.0)
> -
>
> Key: CASSANDRA-14655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14655
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
>
> C* currently uses guava 23.3. This JIRA is about changing C* to use latest
> guava (26.0). Originated from a discussion in the mailing list.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14655) Upgrade C* to use latest guava (27.0)
[
https://issues.apache.org/jira/browse/CASSANDRA-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16936427#comment-16936427
]
mck edited comment on CASSANDRA-14655 at 9/24/19 2:35 PM:
--
[~sumanth.pasupuleti],
- unit tests look good,
- i think the {{"cassandra-driver-core"}} lines in the build.xml can now be
updated and uncommented, see {{"UPDATE AND UNCOMMENT"}} sections,
- for LoaderOptions and CqlConfigHelper are there docs we want to update? (ie
to use `host:port`?
- is the {{nativePort}} parameter needed anymore in
{{NativeSSTableLoaderClient}}'s constructor? the caller can put that into the
{{hosts}} parameter, (and then in the {{init(..)}} method (line 73) the cluster
builder called instead with {{addContactPointsWithPorts(hosts)}},
- i am still looking into the dtests…
bq. … the caller can put that into the {{hosts}} parameter, …
For example it looks like {{CqlBulkRecordWriter}} (in the call to
{{resolveHostAddresses}}), while {{BulkLoader}}+{{LoaderOptions}} could be
doing similar if {{LoaderOptions.Builder.build()}} looped through its {{hosts}}
and put in {{nativePort}} when undefined.
was (Author: michaelsembwever):
[~sumanth.pasupuleti],
- unit tests look good,
- i think the {{"cassandra-driver-core"}} lines in the build.xml can now be
updated and uncommented, see {{"UPDATE AND UNCOMMENT"}} sections,
- for LoaderOptions and CqlConfigHelper are there docs we want to update? (ie
to use `host:`port`?
- is the {{nativePort}} parameter needed anymore in
{{NativeSSTableLoaderClient}}'s constructor? the caller can put that into the
{{hosts}} parameter, (and then in the {{init(..)}} method (line 73) the cluster
builder called instead with {{addContactPointsWithPorts(hosts)}},
- i am still looking into the dtests…
> Upgrade C* to use latest guava (27.0)
> -
>
> Key: CASSANDRA-14655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14655
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
>
> C* currently uses guava 23.3. This JIRA is about changing C* to use latest
> guava (26.0). Originated from a discussion in the mailing list.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16936759#comment-16936759
]
Aleksey Yeschenko commented on CASSANDRA-15299:
---
bq. Can you share what you had in mind?
Of course. We would be reusing the framing protocols introduced by the
messaging rewrite (see the links to code in the description above), including
for when neither checksumming or compression are enabled
({{FrameDecoderUnprotected}} in messaging).
bq. Are you thinking some kind of window for flushing messages?
We already have that implicitly. The only difference will be that instead of
emitting one frame for one message, multiple messages (if we have several to
encode) will often map to a single frame - with per-frame CRC32 and
compression, when either is enabled.
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Labels: client-impacting, protocolv5
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> parcicular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15319) Add support for network topology and tracing to in-JVM dtests.
[ https://issues.apache.org/jira/browse/CASSANDRA-15319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16936584#comment-16936584 ] Alex Petrov commented on CASSANDRA-15319: - I've also left several minor comments [here|https://github.com/apache/cassandra/pull/357#pullrequestreview-292258244]. > Add support for network topology and tracing to in-JVM dtests. > -- > > Key: CASSANDRA-15319 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15319 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > While working on CASSANDRA-15318, testing it properly with an in-JVM test > requires setting up the network topology and tracing requests to check which > nodes performed forwarding. > > In support of testing, make it possible to create in-JVM clusters with nodes > appearing in different datacenter/racks and add support for executing queries > with tracing enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16936567#comment-16936567
]
Jorge Bay commented on CASSANDRA-15299:
---
bq. we should switch to a framing protocol with multiple messages in a single
frame
Can you share what you had in mind? Would this mechanism be also available when
checksumming and/or compression is disabled? Are you thinking some kind of
window for flushing messages?
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Labels: client-impacting, protocolv5
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> parcicular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
