[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=17112780#comment-17112780
]
Olivier Michallat commented on CASSANDRA-15299:
---
I'm getting close to a working driver prototype.
Last remark on the protocol: I think the response to the initial STARTUP
message should never be wrapped either. That's because it might be a legacy
ERROR frame, if the driver is negotiating with a legacy server that doesn't
support v5. I can't tell before I have decoded that response, so I have no way
of guessing the correct format ahead of time.
So modern framing would only start with the next request sent by the driver
(AUTH_RESPONSE or whatnot).
> 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: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-alpha
>
>
> 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.
--
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=17112772#comment-17112772
]
Olivier Michallat commented on CASSANDRA-15299:
---
We discussed the header format on Slack. Quick summary:
* the header bytes are in little endian,
* the fields are in the reverse order (the spec will be amended).
So following the first example in my previous comment:
* receive the full header {{0x04000201f9f2}}
* extract the first 3 bytes: {{04 00 02}}
* switch endianness: {{02 00 04}}, or in binary: {{0010 0100}}
* extract the fields: 6-bit padding, selfContained flag (true), 17-bit payload
length (4)
> 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: Sam Tunnicliffe
>Priority: Normal
> Labels: protocolv5
> Fix For: 4.0-alpha
>
>
> 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.
--
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] [Assigned] (CASSANDRA-15824) High Local read latency for few tables
[ https://issues.apache.org/jira/browse/CASSANDRA-15824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ananda Babu Velupala reassigned CASSANDRA-15824: Assignee: Ananda Babu Velupala > High Local read latency for few tables > -- > > Key: CASSANDRA-15824 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15824 > Project: Cassandra > Issue Type: Bug >Reporter: Ananda Babu Velupala >Assignee: Ananda Babu Velupala >Priority: Normal > > Hi Team, > I am seeing high Local read latency for 3 tables in node(its 5 node cluster) > and keyspace has total 16 sstables and hitting 10 sstables for read from that > table, can you please suggest any path forward to fix read latency. > Appreciate your help.. Thanks > Cassandra version : 3.11.3 > SSTable Hitratio: > == > k2view_usp/service_network_element_relation histograms > Percentile SSTables Write Latency Read Latency Partition Size Cell Count > (micros) (micros) (bytes) > 50% 3.00 0.00 219.34 179 10 > 75% 7.00 0.00 315.85 179 10 > 95% 10.00 0.00 454.83 179 10 > 98% 10.00 0.00 545.79 215 10 > 99% 10.00 0.00 545.79 310 20 > Min 0.00 0.00 51.01 43 0 > Max 10.00 0.00 545.79 89970660 8409007 > > TABLE STATS: > == > Table: service_network_element_relation_mirTable: > service_network_element_relation_mir SSTable count: 3 Space used (live): > 283698097 Space used (total): 283698097 Space used by snapshots (total): 0 > Off heap memory used (total): 5335824 SSTable Compression Ratio: > 0.39563345719027554 Number of partitions (estimate): 2194136 Memtable cell > count: 0 Memtable data size: 0 Memtable off heap memory used: 0 Memtable > switch count: 0 Local read count: 0 Local read latency: NaN ms Local write > count: 0 Local write latency: NaN ms Pending flushes: 0 Percent repaired: > 100.0 Bloom filter false positives: 0 Bloom filter false ratio: 0.0 Bloom > filter space used: 4567016 Bloom filter off heap memory used: 4566992 Index > summary off heap memory used: 705208 Compression metadata off heap memory > used: 63624 Compacted partition minimum bytes: 104 Compacted partition > maximum bytes: 310 Compacted partition mean bytes: 154 Average live cells per > slice (last five minutes): NaN Maximum live cells per slice (last five > minutes): 0 Average tombstones per slice (last five minutes): NaN Maximum > tombstones per slice (last five minutes): 0 Dropped Mutations: 0 > > > Table: service_network_element_relationTable: > service_network_element_relation SSTable count: 11 Space used (live): > 8067239427 Space used (total): 8067239427 Space used by snapshots (total): 0 > Off heap memory used (total): 143032693 SSTable Compression Ratio: > 0.21558247949161227 Number of partitions (estimate): 29357598 Memtable cell > count: 2714 Memtable data size: 691617 Memtable off heap memory used: 0 > Memtable switch count: 9 Local read count: 6369399 Local read latency: 0.311 > ms Local write count: 161229 Local write latency: NaN ms Pending flushes: 0 > Percent repaired: 99.91 Bloom filter false positives: 1508 Bloom filter false > ratio: 0.00012 Bloom filter space used: 113071680 Bloom filter off heap > memory used: 113071592 Index summary off heap memory used: 27244541 > Compression metadata off heap memory used: 2716560 Compacted partition > minimum bytes: 43 Compacted partition maximum bytes: 89970660 Compacted > partition mean bytes: 265 Average live cells per slice (last five minutes): > 1.1779891304347827 Maximum live cells per slice (last five minutes): 103 > Average tombstones per slice (last five minutes): 1.0 Maximum tombstones per > slice (last five minutes): 1 Dropped Mutations: 0 > > Table: service_relationTable: service_relation SSTable count: 7 Space used > (live): 281354042 Space used (total): 281354042 Space used by snapshots > (total): 35695068 Off heap memory used (total): 6423276 SSTable Compression > Ratio: 0.17685515178431085 Number of partitions (estimate): 1719400 Memtable > cell count: 1150 Memtable data size: 67482 Memtable off heap memory used: 0 > Memtable switch count: 3 Local read count: 5506327 Local read latency: 0.182 > ms Local write count: 5237 Local write latency: 0.084 ms Pending flushes: 0 > Percent repaired: 55.48 Bloom filter false positives: 17 Bloom filter false > ratio: 0.0 Bloom filter space used: 5549664 Bloom filter off heap memory > used: 5549608 Index summary off heap memory used: 737348 Compression metadata > off heap memory used: 136320 Compacted partition minimum bytes: 87 Compacted > partition maximum bytes: 4055269 Compacted partition mean bytes: 351 Average > live cells per slice (last five minutes): 1.5556 Maximum live > cells per slice (last five minutes): 3 Average tombstones per slice (last > five minutes): 1.0 Maximum
[jira] [Updated] (CASSANDRA-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-15790:
Since Version: 2.1.0
Source Control Link:
https://github.com/jrwest/cassandra/commit/ea202cea2834dc4140b4a21645eb828f0414cbcd
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-15790:
Reviewers: Jordan West, Yifan Cai, Jordan West (was: Jordan West, Yifan
Cai)
Jordan West, Yifan Cai, Jordan West (was: Jordan West, Yifan
Cai)
Status: Review In Progress (was: Patch Available)
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-15790:
Status: Ready to Commit (was: Review In Progress)
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 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
[cassandra] branch trunk updated (dd1c811 -> b3a1c15)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from dd1c811 Provide ability to configure IAuditLogger add ea202ce EmptyType doesn't override writeValue so could attempt to write bytes when expected not to add 9519eb3 Merge branch 'cassandra-3.0' into cassandra-3.11 new b3a1c15 Merge branch 'cassandra-3.11' into trunk The 1 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: CHANGES.txt| 1 + .../org/apache/cassandra/db/marshal/EmptyType.java | 76 +++- .../cassandra/serializers/EmptySerializer.java | 1 + .../apache/cassandra/db/marshal/EmptyTypeTest.java | 83 ++ 4 files changed, 159 insertions(+), 2 deletions(-) create mode 100644 test/unit/org/apache/cassandra/db/marshal/EmptyTypeTest.java - 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 (86e1590 -> ea202ce)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 86e1590 Fix index queries on partition key columns when some partitions contains only static data add ea202ce EmptyType doesn't override writeValue so could attempt to write bytes when expected not to No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../org/apache/cassandra/db/marshal/EmptyType.java | 72 + .../cassandra/serializers/EmptySerializer.java | 1 + .../apache/cassandra/db/marshal/EmptyTypeTest.java | 94 ++ 4 files changed, 168 insertions(+) create mode 100644 test/unit/org/apache/cassandra/db/marshal/EmptyTypeTest.java - 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 (4a4d5e0 -> 9519eb3)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 4a4d5e0 Merge branch cassandra-3.0 into cassandra-3.11 add ea202ce EmptyType doesn't override writeValue so could attempt to write bytes when expected not to add 9519eb3 Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../org/apache/cassandra/db/marshal/EmptyType.java | 72 + .../cassandra/serializers/EmptySerializer.java | 1 + .../apache/cassandra/db/marshal/EmptyTypeTest.java | 94 ++ 4 files changed, 168 insertions(+) create mode 100644 test/unit/org/apache/cassandra/db/marshal/EmptyTypeTest.java - 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. jwest pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b3a1c159ac49ad375331856b12f3641585eddb30 Merge: dd1c811 9519eb3 Author: Jordan West AuthorDate: Wed May 20 13:42:58 2020 -0700 Merge branch 'cassandra-3.11' into trunk CHANGES.txt| 1 + .../org/apache/cassandra/db/marshal/EmptyType.java | 76 +++- .../cassandra/serializers/EmptySerializer.java | 1 + .../apache/cassandra/db/marshal/EmptyTypeTest.java | 83 ++ 4 files changed, 159 insertions(+), 2 deletions(-) diff --cc CHANGES.txt index b0e7224,a72fed9..c6c2358 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,37 -1,8 +1,38 @@@ -3.11.7 +4.0-alpha5 + * Provide ability to configure IAuditLogger (CASSANDRA-15748) + * Fix nodetool enablefullquerylog blocking param parsing (CASSANDRA-15819) + * Add isTransient to SSTableMetadataView (CASSANDRA-15806) + * Fix tools/bin/fqltool for all shells (CASSANDRA-15820) + * Fix clearing of legacy size_estimates (CASSANDRA-15776) + * Update port when reconnecting to pre-4.0 SSL storage (CASSANDRA-15727) + * Only calculate dynamicBadnessThreshold once per loop in DynamicEndpointSnitch (CASSANDRA-15798) + * Cleanup redundant nodetool commands added in 4.0 (CASSANDRA-15256) + * Update to Python driver 3.23 for cqlsh (CASSANDRA-15793) + * Add tunable initial size and growth factor to RangeTombstoneList (CASSANDRA-15763) + * Improve debug logging in SSTableReader for index summary (CASSANDRA-15755) + * bin/sstableverify should support user provided token ranges (CASSANDRA-15753) + * Improve logging when mutation passed to commit log is too large (CASSANDRA-14781) + * replace LZ4FastDecompressor with LZ4SafeDecompressor (CASSANDRA-15560) + * Fix buffer pool NPE with concurrent release due to in-progress tiny pool eviction (CASSANDRA-15726) + * Avoid race condition when completing stream sessions (CASSANDRA-15666) + * Flush with fast compressors by default (CASSANDRA-15379) + * Fix CqlInputFormat regression from the switch to system.size_estimates (CASSANDRA-15637) + * Allow sending Entire SSTables over SSL (CASSANDRA-15740) + * Fix CQLSH UTF-8 encoding issue for Python 2/3 compatibility (CASSANDRA-15739) + * Fix batch statement preparation when multiple tables and parameters are used (CASSANDRA-15730) + * Fix regression with traceOutgoingMessage printing message size (CASSANDRA-15687) + * Ensure repaired data tracking reads a consistent amount of data across replicas (CASSANDRA-15601) + * Fix CQLSH to avoid arguments being evaluated (CASSANDRA-15660) + * Correct Visibility and Improve Safety of Methods in LatencyMetrics (CASSANDRA-15597) + * Allow cqlsh to run with Python2.7/Python3.6+ (CASSANDRA-15659,CASSANDRA-15573) + * Improve logging around incremental repair (CASSANDRA-15599) + * Do not check cdc_raw_directory filesystem space if CDC disabled (CASSANDRA-15688) + * Replace array iterators with get by index (CASSANDRA-15394) + * Minimize BTree iterator allocations (CASSANDRA-15389) +Merged from 3.11: * Fix CQL formatting of read command restrictions for slow query log (CASSANDRA-15503) - * Allow sstableloader to use SSL on the native port (CASSANDRA-14904) Merged from 3.0: + * EmptyType doesn't override writeValue so could attempt to write bytes when expected not to (CASSANDRA-15790) * Fix index queries on partition key columns when some partitions contains only static data (CASSANDRA-13666) * Avoid creating duplicate rows during major upgrades (CASSANDRA-15789) * liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted (CASSANDRA-15674) diff --cc src/java/org/apache/cassandra/db/marshal/EmptyType.java index d3dd4c2,00c919d..88d62c4 --- a/src/java/org/apache/cassandra/db/marshal/EmptyType.java +++ b/src/java/org/apache/cassandra/db/marshal/EmptyType.java @@@ -22,11 -26,14 +26,14 @@@ import org.slf4j.LoggerFactory import org.apache.cassandra.cql3.CQL3Type; import org.apache.cassandra.cql3.Constants; import org.apache.cassandra.cql3.Term; - import org.apache.cassandra.serializers.TypeSerializer; - import org.apache.cassandra.transport.ProtocolVersion; + import org.apache.cassandra.io.util.DataInputPlus; + import org.apache.cassandra.io.util.DataOutputPlus; -import org.apache.cassandra.serializers.TypeSerializer; -import org.apache.cassandra.transport.ProtocolVersion; import org.apache.cassandra.serializers.EmptySerializer; import org.apache.cassandra.serializers.MarshalException; ++import org.apache.cassandra.serializers.TypeSerializer; ++import org.apache.cassandra.transport.ProtocolVersion; import org.apache.cassandra.utils.ByteBufferUtil; + import org.apache.cassandra.utils.NoSpamLogger; /** * A type that only accept empty data. diff --cc
[jira] [Comment Edited] (CASSANDRA-15823) Support for networking via identity instead of IP
[ https://issues.apache.org/jira/browse/CASSANDRA-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112584#comment-17112584 ] Jeremiah Jordan edited comment on CASSANDRA-15823 at 5/20/20, 8:24 PM: --- bq. Cassandra is protected here as we already have logic in place to update peers when we come up with the same host id, but a different IP address. bq. This definitely isn’t true / strictly safe. In fact it’s trivial to violate consistency / lose data by swapping the IP of two Pods/instances on the same host. Right. We are OK right now as long as you don't actually "swap" IPs with another node. Aka Node A goes down loses its IP, Node B goes down loses its IP, Node A comes back up with the IP node B previously had. "bad things" will happen in this case as there are a bunch of race conditions for the change in token ownership that just occurred. If a node comes up with a completely brand new IP that was never part of the cluster before, then we do not have any issues that I know of. Do you know of any problems that can happen for that case [~jjirsa] ? bq. We really need everything to be based on UUIDs, not ip or port or host name. And we really really really shouldn’t assume that dns is universally available or correct (because that’s just not always true, even in 2020). While I agree it would be best to have all membership based on UUID's, I think we need to allow people to have hostnames be the contact point, and have those re-resolve on every "connect". While I agree "ips are best, dns is the devil", I have seen bad DNS take down clusters, there are many systems being created right now where hostnames are the invariant, not ips, and we need Cassandra to be able to play in those environments. was (Author: jjordan): bq. Cassandra is protected here as we already have logic in place to update peers when we come up with the same host id, but a different IP address. bq. This definitely isn’t true / strictly safe. In fact it’s trivial to violate consistency / lose data by swapping the IP of two Pods/instances on the same host. Right. We are OK right now as long as you don't actually "swap" its with another node. Aka Node A goes down loses its IP, Node B goes down loses its IP, Node A comes back up with the IP node B previously had. "bad things" will happen in this case as there are a bunch of race conditions for the change in token ownership that just occurred. If a node comes up with a completely brand new IP that was never part of the cluster before, then we do not have any issues that I know of. Do you know of any problems that can happen for that case [~jjirsa] ? bq. We really need everything to be based on UUIDs, not ip or port or host name. And we really really really shouldn’t assume that dns is universally available or correct (because that’s just not always true, even in 2020). While I agree it would be best to have all membership based on UUID's, I think we need to allow people to have hostnames be the contact point, and have those re-resolve on every "connect". While I agree "ips are best, dns is the devil", I have seen bad DNS take down clusters, there are many systems being created right now where hostnames are the invariant, not ips, and we need Cassandra to be able to play in those environments. > Support for networking via identity instead of IP > - > > Key: CASSANDRA-15823 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15823 > Project: Cassandra > Issue Type: Improvement >Reporter: Christopher Bradford >Priority: Normal > Attachments: consul-mesh-gateways.png, > istio-multicluster-with-gateways.svg, linkerd-service-mirroring.svg > > > TL;DR: Instead of mapping host ids to IPs, use hostnames. This allows > resolution to different IP addresses per DC that may then be forwarded to > nodes on remote networks without requiring node to node IP connectivity for > cross-dc links. > > This approach should not affect existing deployments as those could continue > to use IPs as the hostname and skip resolution. > > With orchestration platforms like Kubernetes and the usage of ephemeral > containers in environments today we should consider some changes to how we > handle the tracking of nodes and their network location. Currently we > maintain a mapping between host ids and IP addresses. > > With traditional infrastructure, if a node goes down it, usually, comes back > up with the same IP. In some environments this contract may be explicit with > virtual IPs that may move between hosts. In newer deployments, like on > Kubernetes, this contract is not possible. Pods (analogous to nodes) are > assigned an IP address at start time. Should the pod be restarted or > scheduled on a different
[jira] [Commented] (CASSANDRA-15823) Support for networking via identity instead of IP
[ https://issues.apache.org/jira/browse/CASSANDRA-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112584#comment-17112584 ] Jeremiah Jordan commented on CASSANDRA-15823: - bq. Cassandra is protected here as we already have logic in place to update peers when we come up with the same host id, but a different IP address. bq. This definitely isn’t true / strictly safe. In fact it’s trivial to violate consistency / lose data by swapping the IP of two Pods/instances on the same host. Right. We are OK right now as long as you don't actually "swap" its with another node. Aka Node A goes down loses its IP, Node B goes down loses its IP, Node A comes back up with the IP node B previously had. "bad things" will happen in this case as there are a bunch of race conditions for the change in token ownership that just occurred. If a node comes up with a completely brand new IP that was never part of the cluster before, then we do not have any issues that I know of. Do you know of any problems that can happen for that case [~jjirsa] ? bq. We really need everything to be based on UUIDs, not ip or port or host name. And we really really really shouldn’t assume that dns is universally available or correct (because that’s just not always true, even in 2020). While I agree it would be best to have all membership based on UUID's, I think we need to allow people to have hostnames be the contact point, and have those re-resolve on every "connect". While I agree "ips are best, dns is the devil", I have seen bad DNS take down clusters, there are many systems being created right now where hostnames are the invariant, not ips, and we need Cassandra to be able to play in those environments. > Support for networking via identity instead of IP > - > > Key: CASSANDRA-15823 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15823 > Project: Cassandra > Issue Type: Improvement >Reporter: Christopher Bradford >Priority: Normal > Attachments: consul-mesh-gateways.png, > istio-multicluster-with-gateways.svg, linkerd-service-mirroring.svg > > > TL;DR: Instead of mapping host ids to IPs, use hostnames. This allows > resolution to different IP addresses per DC that may then be forwarded to > nodes on remote networks without requiring node to node IP connectivity for > cross-dc links. > > This approach should not affect existing deployments as those could continue > to use IPs as the hostname and skip resolution. > > With orchestration platforms like Kubernetes and the usage of ephemeral > containers in environments today we should consider some changes to how we > handle the tracking of nodes and their network location. Currently we > maintain a mapping between host ids and IP addresses. > > With traditional infrastructure, if a node goes down it, usually, comes back > up with the same IP. In some environments this contract may be explicit with > virtual IPs that may move between hosts. In newer deployments, like on > Kubernetes, this contract is not possible. Pods (analogous to nodes) are > assigned an IP address at start time. Should the pod be restarted or > scheduled on a different host there is no guarantee we would have the same > IP. Cassandra is protected here as we already have logic in place to update > peers when we come up with the same host id, but a different IP address. > > There are ways to get Kubernetes to assign a specific IP per Pod. Most > recommendations involve the use of a service per pod. Communication with the > fixed service IP would automatically forward to the associated pod, > regardless of address. We _could_ use this approach, but it seems like this > would needlessly create a number of extra resources in our k8s cluster to get > around the problem. Which, to be fair, doesn't seem like much of a problem > with the aforementioned mitigations built into C*. > > So what is the _actual_ problem? *Cross-region, cross-cloud, > hybrid-deployment connectivity between pods is a pain.* This can be solved > with significant investment by those who want to deploy these types of > topologies. You can definitely configure connectivity between clouds over > dedicated connections, or VPN tunnels. With a big chunk of time insuring that > pod to pod connectivity just works even if those pods are managed by separate > control planes, but that again requires time and talent. There are a number > of edge cases to support between the ever so slight, but very important, > differences in cloud vendor networks. > > Recently there have been a number of innovations that aid in the deployment > and operation of these types of applications on Kubernetes. Service meshes > support distributed microservices running across multiple k8s cluster control >
[jira] [Commented] (CASSANDRA-8272) 2ndary indexes can return stale data
[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112538#comment-17112538
]
ZhaoYang commented on CASSANDRA-8272:
-
The patch looks really good. Left some minor comments in the PR: I think we
need to disable `ReplicaFilteringProtection` on transient replicas where
repaired data are removed purposely to reduce storage requirement to avoid
unnecessary RFP.
> 2ndary indexes can return stale data
>
>
> Key: CASSANDRA-8272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8272
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Sylvain Lebresne
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.x, 4.0-beta
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> When replica return 2ndary index results, it's possible for a single replica
> to return a stale result and that result will be sent back to the user,
> potentially failing the CL contract.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v text);
> CREATE INDEX ON test(v);
> INSERT INTO test(k, v) VALUES (0, 'foo');
> {noformat}
> with every replica up to date. Now, suppose that the following queries are
> done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v = 'bar' WHERE k = 0;
> SELECT * FROM test WHERE v = 'foo';
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before
> having applied the insert, then the now stale result will be returned (since
> C will return it and A or B will return nothing).
> A potential solution would be that when we read a tombstone in the index (and
> provided we make the index inherit the gcGrace of it's parent CF), instead of
> skipping that tombstone, we'd insert in the result a corresponding range
> tombstone.
--
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-15825) Fix flaky test incrementalSSTableSelection - org.apache.cassandra.db.streaming.CassandraStreamManagerTest
David Capwell created CASSANDRA-15825:
-
Summary: Fix flaky test incrementalSSTableSelection -
org.apache.cassandra.db.streaming.CassandraStreamManagerTest
Key: CASSANDRA-15825
URL: https://issues.apache.org/jira/browse/CASSANDRA-15825
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: David Capwell
Build link:
https://app.circleci.com/pipelines/github/dcapwell/cassandra/287/workflows/06baf3db-7094-431f-920d-e8fcd1da9cce/jobs/1398
{code}
java.lang.RuntimeException: java.nio.file.NoSuchFileException:
/tmp/cassandra/build/test/cassandra/data:2/ks_1589913975959/tbl-051c0a709a0111eab5fb6f52366536f8/na-4-big-Statistics.db
at
org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55)
at
org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66)
at
org.apache.cassandra.io.util.RandomAccessReader.open(RandomAccessReader.java:315)
at
org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:126)
at
org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:136)
at
org.apache.cassandra.io.sstable.format.SSTableReader.reloadSSTableMetadata(SSTableReader.java:2047)
at
org.apache.cassandra.db.streaming.CassandraStreamManagerTest.mutateRepaired(CassandraStreamManagerTest.java:128)
at
org.apache.cassandra.db.streaming.CassandraStreamManagerTest.incrementalSSTableSelection(CassandraStreamManagerTest.java:175)
Caused by: java.nio.file.NoSuchFileException:
/tmp/cassandra/build/test/cassandra/data:2/ks_1589913975959/tbl-051c0a709a0111eab5fb6f52366536f8/na-4-big-Statistics.db
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
at java.nio.channels.FileChannel.open(FileChannel.java:287)
at java.nio.channels.FileChannel.open(FileChannel.java:335)
at
org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:51)
{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-15825) Fix flaky test incrementalSSTableSelection - org.apache.cassandra.db.streaming.CassandraStreamManagerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15825:
--
Fix Version/s: 4.0-alpha
> Fix flaky test incrementalSSTableSelection -
> org.apache.cassandra.db.streaming.CassandraStreamManagerTest
> -
>
> Key: CASSANDRA-15825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15825
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Build link:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/287/workflows/06baf3db-7094-431f-920d-e8fcd1da9cce/jobs/1398
>
> {code}
> java.lang.RuntimeException: java.nio.file.NoSuchFileException:
> /tmp/cassandra/build/test/cassandra/data:2/ks_1589913975959/tbl-051c0a709a0111eab5fb6f52366536f8/na-4-big-Statistics.db
> at
> org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55)
> at
> org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66)
> at
> org.apache.cassandra.io.util.RandomAccessReader.open(RandomAccessReader.java:315)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:126)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:136)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.reloadSSTableMetadata(SSTableReader.java:2047)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManagerTest.mutateRepaired(CassandraStreamManagerTest.java:128)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManagerTest.incrementalSSTableSelection(CassandraStreamManagerTest.java:175)
> Caused by: java.nio.file.NoSuchFileException:
> /tmp/cassandra/build/test/cassandra/data:2/ks_1589913975959/tbl-051c0a709a0111eab5fb6f52366536f8/na-4-big-Statistics.db
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
> at java.nio.channels.FileChannel.open(FileChannel.java:287)
> at java.nio.channels.FileChannel.open(FileChannel.java:335)
> at
> org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:51)
> {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-15825) Fix flaky test incrementalSSTableSelection - org.apache.cassandra.db.streaming.CassandraStreamManagerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15825:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: Transient
Incorrect Response(12987)
Complexity: Normal
Discovered By: Unit Test
Severity: Normal
Status: Open (was: Triage Needed)
> Fix flaky test incrementalSSTableSelection -
> org.apache.cassandra.db.streaming.CassandraStreamManagerTest
> -
>
> Key: CASSANDRA-15825
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15825
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Priority: Normal
>
> Build link:
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/287/workflows/06baf3db-7094-431f-920d-e8fcd1da9cce/jobs/1398
>
> {code}
> java.lang.RuntimeException: java.nio.file.NoSuchFileException:
> /tmp/cassandra/build/test/cassandra/data:2/ks_1589913975959/tbl-051c0a709a0111eab5fb6f52366536f8/na-4-big-Statistics.db
> at
> org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:55)
> at
> org.apache.cassandra.io.util.ChannelProxy.(ChannelProxy.java:66)
> at
> org.apache.cassandra.io.util.RandomAccessReader.open(RandomAccessReader.java:315)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:126)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:136)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.reloadSSTableMetadata(SSTableReader.java:2047)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManagerTest.mutateRepaired(CassandraStreamManagerTest.java:128)
> at
> org.apache.cassandra.db.streaming.CassandraStreamManagerTest.incrementalSSTableSelection(CassandraStreamManagerTest.java:175)
> Caused by: java.nio.file.NoSuchFileException:
> /tmp/cassandra/build/test/cassandra/data:2/ks_1589913975959/tbl-051c0a709a0111eab5fb6f52366536f8/na-4-big-Statistics.db
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
> at java.nio.channels.FileChannel.open(FileChannel.java:287)
> at java.nio.channels.FileChannel.open(FileChannel.java:335)
> at
> org.apache.cassandra.io.util.ChannelProxy.openChannel(ChannelProxy.java:51)
> {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] [Comment Edited] (CASSANDRA-15262) server_encryption_options is not backwards compatible with 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109708#comment-17109708
]
Ekaterina Dimitrova edited comment on CASSANDRA-15262 at 5/20/20, 5:55 PM:
---
I compared the test results with the Jenkins reports.
test_closing_connections - thrift_hsha_test.TestThriftHSHA is the only test
that is failing on 2.2 and 3.0 currently with this patch but not in Jenkins.
was (Author: e.dimitrova):
I compared the test results with the Jenkins reports.
test_closing_connections - thrift_hsha_test.TestThriftHSHA is the only test
that is failing on 2.2 and 3.0 currently with this patch but not in Jenkins.
[~jolynch] is there any reason why this was not merged to 3.11, too?
> server_encryption_options is not backwards compatible with 3.11
> ---
>
> Key: CASSANDRA-15262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
> # set to true for allowing secure incoming connections
> enabled: false
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
> enable_legacy_ssl_storage_port: false
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
> keystore: conf/.keystore
> keystore_password: cassandra
> truststore: conf/.truststore
> truststore_password: cassandra
> # More advanced defaults below:
> # protocol: TLS
> # store_type: JKS
> # cipher_suites:
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> # require_client_auth: false
> # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations
> for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular
> encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even
> client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code
> intelligently decides to open a TLS connection or not this is the more
> sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to
--
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-15824) High Local read latency for few tables
Ananda Babu Velupala created CASSANDRA-15824: Summary: High Local read latency for few tables Key: CASSANDRA-15824 URL: https://issues.apache.org/jira/browse/CASSANDRA-15824 Project: Cassandra Issue Type: Bug Reporter: Ananda Babu Velupala Hi Team, I am seeing high Local read latency for 3 tables in node(its 5 node cluster) and keyspace has total 16 sstables and hitting 10 sstables for read from that table, can you please suggest any path forward to fix read latency. Appreciate your help.. Thanks Cassandra version : 3.11.3 SSTable Hitratio: == k2view_usp/service_network_element_relation histograms Percentile SSTables Write Latency Read Latency Partition Size Cell Count (micros) (micros) (bytes) 50% 3.00 0.00 219.34 179 10 75% 7.00 0.00 315.85 179 10 95% 10.00 0.00 454.83 179 10 98% 10.00 0.00 545.79 215 10 99% 10.00 0.00 545.79 310 20 Min 0.00 0.00 51.01 43 0 Max 10.00 0.00 545.79 89970660 8409007 TABLE STATS: == Table: service_network_element_relation_mirTable: service_network_element_relation_mir SSTable count: 3 Space used (live): 283698097 Space used (total): 283698097 Space used by snapshots (total): 0 Off heap memory used (total): 5335824 SSTable Compression Ratio: 0.39563345719027554 Number of partitions (estimate): 2194136 Memtable cell count: 0 Memtable data size: 0 Memtable off heap memory used: 0 Memtable switch count: 0 Local read count: 0 Local read latency: NaN ms Local write count: 0 Local write latency: NaN ms Pending flushes: 0 Percent repaired: 100.0 Bloom filter false positives: 0 Bloom filter false ratio: 0.0 Bloom filter space used: 4567016 Bloom filter off heap memory used: 4566992 Index summary off heap memory used: 705208 Compression metadata off heap memory used: 63624 Compacted partition minimum bytes: 104 Compacted partition maximum bytes: 310 Compacted partition mean bytes: 154 Average live cells per slice (last five minutes): NaN Maximum live cells per slice (last five minutes): 0 Average tombstones per slice (last five minutes): NaN Maximum tombstones per slice (last five minutes): 0 Dropped Mutations: 0 Table: service_network_element_relationTable: service_network_element_relation SSTable count: 11 Space used (live): 8067239427 Space used (total): 8067239427 Space used by snapshots (total): 0 Off heap memory used (total): 143032693 SSTable Compression Ratio: 0.21558247949161227 Number of partitions (estimate): 29357598 Memtable cell count: 2714 Memtable data size: 691617 Memtable off heap memory used: 0 Memtable switch count: 9 Local read count: 6369399 Local read latency: 0.311 ms Local write count: 161229 Local write latency: NaN ms Pending flushes: 0 Percent repaired: 99.91 Bloom filter false positives: 1508 Bloom filter false ratio: 0.00012 Bloom filter space used: 113071680 Bloom filter off heap memory used: 113071592 Index summary off heap memory used: 27244541 Compression metadata off heap memory used: 2716560 Compacted partition minimum bytes: 43 Compacted partition maximum bytes: 89970660 Compacted partition mean bytes: 265 Average live cells per slice (last five minutes): 1.1779891304347827 Maximum live cells per slice (last five minutes): 103 Average tombstones per slice (last five minutes): 1.0 Maximum tombstones per slice (last five minutes): 1 Dropped Mutations: 0 Table: service_relationTable: service_relation SSTable count: 7 Space used (live): 281354042 Space used (total): 281354042 Space used by snapshots (total): 35695068 Off heap memory used (total): 6423276 SSTable Compression Ratio: 0.17685515178431085 Number of partitions (estimate): 1719400 Memtable cell count: 1150 Memtable data size: 67482 Memtable off heap memory used: 0 Memtable switch count: 3 Local read count: 5506327 Local read latency: 0.182 ms Local write count: 5237 Local write latency: 0.084 ms Pending flushes: 0 Percent repaired: 55.48 Bloom filter false positives: 17 Bloom filter false ratio: 0.0 Bloom filter space used: 5549664 Bloom filter off heap memory used: 5549608 Index summary off heap memory used: 737348 Compression metadata off heap memory used: 136320 Compacted partition minimum bytes: 87 Compacted partition maximum bytes: 4055269 Compacted partition mean bytes: 351 Average live cells per slice (last five minutes): 1.5556 Maximum live cells per slice (last five minutes): 3 Average tombstones per slice (last five minutes): 1.0 Maximum tombstones per slice (last five minutes): 1 Dropped Mutations: 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] [Commented] (CASSANDRA-15823) Support for networking via identity instead of IP
[ https://issues.apache.org/jira/browse/CASSANDRA-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112377#comment-17112377 ] Christopher Bradford commented on CASSANDRA-15823: -- Isn’t host id a uuid? I’m not suggesting we remove that part of the equation. The goal of this ticket is to support address identifiers other than IP. DNS availability and resilience should be weighed by the users on a per environment basis. If the user prefers configuration by hostname and believe their DNS is HA and resilient enough they should be able to opt in here. Now if we’re talking about validating a request was received and processed by a specific host id. IMHO that’s a different change / ticket. Do we have anything in our protocols / RPC that validates a request that’s received? IE if a coordinator sends a request to an IP that’s been swapped, does the receiving node validate that the request belongs to it? Maybe more succinctly, are host ids sent along with each request for validation purposes? > Support for networking via identity instead of IP > - > > Key: CASSANDRA-15823 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15823 > Project: Cassandra > Issue Type: Improvement >Reporter: Christopher Bradford >Priority: Normal > Attachments: consul-mesh-gateways.png, > istio-multicluster-with-gateways.svg, linkerd-service-mirroring.svg > > > TL;DR: Instead of mapping host ids to IPs, use hostnames. This allows > resolution to different IP addresses per DC that may then be forwarded to > nodes on remote networks without requiring node to node IP connectivity for > cross-dc links. > > This approach should not affect existing deployments as those could continue > to use IPs as the hostname and skip resolution. > > With orchestration platforms like Kubernetes and the usage of ephemeral > containers in environments today we should consider some changes to how we > handle the tracking of nodes and their network location. Currently we > maintain a mapping between host ids and IP addresses. > > With traditional infrastructure, if a node goes down it, usually, comes back > up with the same IP. In some environments this contract may be explicit with > virtual IPs that may move between hosts. In newer deployments, like on > Kubernetes, this contract is not possible. Pods (analogous to nodes) are > assigned an IP address at start time. Should the pod be restarted or > scheduled on a different host there is no guarantee we would have the same > IP. Cassandra is protected here as we already have logic in place to update > peers when we come up with the same host id, but a different IP address. > > There are ways to get Kubernetes to assign a specific IP per Pod. Most > recommendations involve the use of a service per pod. Communication with the > fixed service IP would automatically forward to the associated pod, > regardless of address. We _could_ use this approach, but it seems like this > would needlessly create a number of extra resources in our k8s cluster to get > around the problem. Which, to be fair, doesn't seem like much of a problem > with the aforementioned mitigations built into C*. > > So what is the _actual_ problem? *Cross-region, cross-cloud, > hybrid-deployment connectivity between pods is a pain.* This can be solved > with significant investment by those who want to deploy these types of > topologies. You can definitely configure connectivity between clouds over > dedicated connections, or VPN tunnels. With a big chunk of time insuring that > pod to pod connectivity just works even if those pods are managed by separate > control planes, but that again requires time and talent. There are a number > of edge cases to support between the ever so slight, but very important, > differences in cloud vendor networks. > > Recently there have been a number of innovations that aid in the deployment > and operation of these types of applications on Kubernetes. Service meshes > support distributed microservices running across multiple k8s cluster control > planes in disparate networks. Instead of directly connecting to IP addresses > of remote services instead they use a hostname. With this approach, hostname > traffic may then be routed to a proxy that sends traffic over the WAN > (sometimes with mTLS) to another proxy pod in the remote cluster which then > forwards the data along to the correct pod in that network. (See attached > diagrams) > > Which brings us to the point of this ticket. Instead of mapping host ids to > IPs, use hostnames (and update the underlying address periodically instead of > caching indefinitely). This allows resolution to different IP addresses per > DC (k8s cluster) that may then be forwarded to nodes (pods)
[jira] [Commented] (CASSANDRA-15700) Performance regression on internode messaging
[
https://issues.apache.org/jira/browse/CASSANDRA-15700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112333#comment-17112333
]
Benedict Elliott Smith commented on CASSANDRA-15700:
That part could also be left to CASSANDRA-15766, which I think is also
addressing this and will do so in a consistent manner across various
NoSpamLogger call sites.
> Performance regression on internode messaging
> -
>
> Key: CASSANDRA-15700
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15700
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Attachments: Oss40patchedvsOss311.png, Oss40vsOss311.png, oss40.gc,
> oss40_nogc.tar.xz, oss40_system.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Me and [~jasonstack] have been investigating a performance regression
> affecting 4.0 during a 3 nodes, RF 3 write throughput test with a timeseries
> like workload, as shown in this plot, where blue is 3.11 and orange is 4.0:
> !Oss40vsOss311.png|width=389,height=214!
> It's been a bit of a long investigation, but two clues ended up standing out:
> 1) An abnormal number of expired messages on 4.0 (as shown in the attached
> system log), while 3.11 has almost none.
> 2) An abnormal GC activity (as shown in the attached gc log).
> Turns out the two are related, as the [on expired
> callback|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundConnection.java#L462]
> creates a huge amount of strings in the {{id()}} call. The next question is
> what causes all those message expirations; we thoroughly reviewed the
> internode messaging code and the only issue we could find so far is related
> to the "batch pruning" calls
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L81]
> and
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L188]:
> it _seems_ too much time is spent on those, causing the event loop to fall
> behind in processing the rest of the messages, which will end up being
> expired. This is supported by the analysis of the collapsed stacks (after
> fixing the GC issue):
> {noformat}
> (tprint (top-aggregated-calls oss40nogc "EventLoopDelivery:doRun" 5))
> org/apache/cassandra/net/OutboundConnection$EventLoopDelivery:doRun 3456
> org/apache/cassandra/net/OutboundMessageQueue:access$600 1621
> org/apache/cassandra/net/PrunableArrayQueue:prune 1621
> org/apache/cassandra/net/OutboundMessageQueue$WithLock:close 1621
> org/apache/cassandra/net/OutboundMessageQueue:pruneInternalQueueWithLock 1620
> {noformat}
> Those are the top 5 sampled calls from {{EventLoopDelivery#doRun()}} which
> spends half of its time pruning. But only a tiny portion of such pruning time
> is spent actually expiring:
> {noformat}
> (tprint (top-aggregated-calls oss40nogc
> "OutboundMessageQueue:pruneInternalQueueWithLock" 5))
> org/apache/cassandra/net/OutboundMessageQueue:pruneInternalQueueWithLock 1900
> org/apache/cassandra/net/PrunableArrayQueue:prune 1894
> org/apache/cassandra/net/OutboundMessageQueue$1Pruner:onPruned 147
> org/apache/cassandra/net/OutboundConnection$$Lambda$444/740904487:accept 147
> org/apache/cassandra/net/OutboundConnection:onExpired 147
> {noformat}
> And indeed, the {{PrunableArrayQueue:prune()}} self time is dominant:
> {noformat}
> (tprint (top-self-calls oss40nogc "PrunableArrayQueue:prune" 5))
> org/apache/cassandra/net/PrunableArrayQueue:prune 1718
> org/apache/cassandra/net/OutboundConnection:releaseCapacity 27
> java/util/concurrent/ConcurrentHashMap:replaceNode 19
> java/util/concurrent/ConcurrentLinkedQueue:offer 16
> java/util/concurrent/LinkedBlockingQueue:offer 15
> {noformat}
> That said, before proceeding with a PR to fix those issues, I'd like to
> understand: what's the reason to prune so often, rather than just when
> polling the message during delivery? If there's a reason I'm missing, let's
> talk about how to optimize pruning, otherwise let's get rid of that.
--
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-8272) 2ndary indexes can return stale data
[
https://issues.apache.org/jira/browse/CASSANDRA-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112315#comment-17112315
]
Benjamin Lerer commented on CASSANDRA-8272:
---
The patch LGTM.
> 2ndary indexes can return stale data
>
>
> Key: CASSANDRA-8272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8272
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Sylvain Lebresne
>Assignee: Andres de la Peña
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.x, 4.0-beta
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When replica return 2ndary index results, it's possible for a single replica
> to return a stale result and that result will be sent back to the user,
> potentially failing the CL contract.
> For instance, consider 3 replicas A, B and C, and the following situation:
> {noformat}
> CREATE TABLE test (k int PRIMARY KEY, v text);
> CREATE INDEX ON test(v);
> INSERT INTO test(k, v) VALUES (0, 'foo');
> {noformat}
> with every replica up to date. Now, suppose that the following queries are
> done at {{QUORUM}}:
> {noformat}
> UPDATE test SET v = 'bar' WHERE k = 0;
> SELECT * FROM test WHERE v = 'foo';
> {noformat}
> then, if A and B acknowledge the insert but C respond to the read before
> having applied the insert, then the now stale result will be returned (since
> C will return it and A or B will return nothing).
> A potential solution would be that when we read a tombstone in the index (and
> provided we make the index inherit the gcGrace of it's parent CF), instead of
> skipping that tombstone, we'd insert in the result a corresponding range
> tombstone.
--
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-15802) Commented-out lines that end in a semicolon cause an error.
[ https://issues.apache.org/jira/browse/CASSANDRA-15802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112311#comment-17112311 ] Rens Groothuijsen commented on CASSANDRA-15802: --- [~null-] I've been playing around with a few ways, and I figure the most straightforward approach is to simply strip comment blocks out of the input before processing. I'm preparing a PR with that idea in mind. > Commented-out lines that end in a semicolon cause an error. > --- > > Key: CASSANDRA-15802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15802 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter, CQL/Syntax >Reporter: null >Priority: Normal > Attachments: cqlsh.png > > > Commented-out lines that end in a semicolon cause an error. > For example: > /* > describe keyspaces; > */ > > This produces an error: > SyntaxException: line 2:22 no viable alternative at input ' (...* > describe keyspaces;...) > > It works as expected if you use syntax: > -- describe keyspaces; > > Environment: > python:3.7.7-slim-stretch (docker image) > > I found that this was first seen here, and was patched, but the bug appears > to have resurfaced: > https://issues.apache.org/jira/browse/CASSANDRA-2488 -- 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-15748) Provide ability to configure IAuditLogger
[ https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15748: Status: Ready to Commit (was: Review In Progress) > Provide ability to configure IAuditLogger > - > > Key: CASSANDRA-15748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15748 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > Currently there is a parameterless constructor expected for IAuditLogger > instances. There is not any way how to "inject" configuration properties from > cassandra.yaml into these concrete classes. This would be very handy for > custom IAuditLogger implementations. > > PR: [https://github.com/apache/cassandra/pull/555] > [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748] -- 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-15748) Provide ability to configure IAuditLogger
[ https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15748: Reviewers: Marcus Eriksson, Vinay Chella, Marcus Eriksson (was: Marcus Eriksson, Vinay Chella) Marcus Eriksson, Vinay Chella, Marcus Eriksson (was: Marcus Eriksson, Vinay Chella) Status: Review In Progress (was: Patch Available) > Provide ability to configure IAuditLogger > - > > Key: CASSANDRA-15748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15748 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > Currently there is a parameterless constructor expected for IAuditLogger > instances. There is not any way how to "inject" configuration properties from > cassandra.yaml into these concrete classes. This would be very handy for > custom IAuditLogger implementations. > > PR: [https://github.com/apache/cassandra/pull/555] > [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748] -- 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-15748) Provide ability to configure IAuditLogger
[ https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15748: Source Control Link: https://github.com/apache/cassandra/commit/dd1c811f8796487f49e92ff4701917420caf49c0 Resolution: Fixed Status: Resolved (was: Ready to Commit) with [this|https://github.com/smiklosovic/cassandra/commit/6737442255feca95ec36f7335f11446358cec16d] fix tests look fine committed, thanks! > Provide ability to configure IAuditLogger > - > > Key: CASSANDRA-15748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15748 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > Currently there is a parameterless constructor expected for IAuditLogger > instances. There is not any way how to "inject" configuration properties from > cassandra.yaml into these concrete classes. This would be very handy for > custom IAuditLogger implementations. > > PR: [https://github.com/apache/cassandra/pull/555] > [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748] -- 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: Provide ability to configure IAuditLogger
This is an automated email from the ASF dual-hosted git repository. marcuse 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 dd1c811 Provide ability to configure IAuditLogger dd1c811 is described below commit dd1c811f8796487f49e92ff4701917420caf49c0 Author: Stefan Miklosovic AuthorDate: Wed Apr 22 09:23:16 2020 +0200 Provide ability to configure IAuditLogger Patch by Stefan Miklosovic; reviewed by Vinay Chella and marcuse for CASSANDRA-15748 --- CHANGES.txt| 1 + conf/cassandra.yaml| 3 ++- doc/source/new/auditlogging.rst| 25 -- .../apache/cassandra/audit/AuditLogManager.java| 25 +- .../apache/cassandra/audit/AuditLogOptions.java| 6 +- .../org/apache/cassandra/audit/BinAuditLogger.java | 3 ++- .../audit/DiagnosticEventAuditLogger.java | 7 ++ .../apache/cassandra/audit/FileAuditLogger.java| 4 +++- .../apache/cassandra/audit/NoOpAuditLogger.java| 7 ++ .../apache/cassandra/db/virtual/SettingsTable.java | 2 +- .../apache/cassandra/service/StorageService.java | 13 --- .../cassandra/service/StorageServiceMBean.java | 1 + src/java/org/apache/cassandra/tools/NodeProbe.java | 7 +- .../org/apache/cassandra/utils/FBUtilities.java| 15 + .../cassandra/audit/AuditLoggerAuthTest.java | 3 ++- .../apache/cassandra/audit/AuditLoggerTest.java| 10 + .../apache/cassandra/audit/BinAuditLoggerTest.java | 3 ++- .../cassandra/audit/InMemoryAuditLogger.java | 7 +- .../cassandra/db/virtual/SettingsTableTest.java| 3 ++- .../service/StorageServiceServerTest.java | 10 - .../cassandra/transport/CQLUserAuditTest.java | 3 ++- 21 files changed, 119 insertions(+), 39 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 88d633b..b0e7224 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0-alpha5 + * Provide ability to configure IAuditLogger (CASSANDRA-15748) * Fix nodetool enablefullquerylog blocking param parsing (CASSANDRA-15819) * Add isTransient to SSTableMetadataView (CASSANDRA-15806) * Fix tools/bin/fqltool for all shells (CASSANDRA-15820) diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index e1d2d2d..6db9557 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -1284,7 +1284,8 @@ back_pressure_strategy: # on audit_logging for full details about the various configuration options. audit_logging_options: enabled: false -logger: BinAuditLogger +logger: + - class_name: BinAuditLogger # audit_logs_dir: # included_keyspaces: # excluded_keyspaces: system, system_schema, system_virtual_schema diff --git a/doc/source/new/auditlogging.rst b/doc/source/new/auditlogging.rst index 0a15a9f..0842810 100644 --- a/doc/source/new/auditlogging.rst +++ b/doc/source/new/auditlogging.rst @@ -120,7 +120,8 @@ The audit logger is set with the ``logger`` option. :: - logger: BinAuditLogger + logger: + - class_name: BinAuditLogger Two types of audit loggers are supported: ``FileAuditLogger`` and ``BinAuditLogger``. ``BinAuditLogger`` is the default setting. The ``BinAuditLogger`` is an efficient way to log events to file in a binary format. @@ -129,6 +130,25 @@ Two types of audit loggers are supported: ``FileAuditLogger`` and ``BinAuditLogg The ``NoOpAuditLogger`` is a No-Op implementation of the audit logger to be used as a default audit logger when audit logging is disabled. +It is possible to configure your custom logger implementation by injecting a map of property keys and their respective values. Default `IAuditLogger` +implementations shipped with Cassandra do not react on these properties but your custom logger might. They would be present as +a parameter of logger constructor (as `Map`). In ``cassandra.yaml`` file, you may configure it like this: + +:: + + logger: + - class_name: MyCustomAuditLogger + parameters: + - key1: value1 + key2: value2 + +When it comes to configuring these parameters, you can use respective ``enableAuditLog`` method in ``StorageServiceMBean``. +There are two methods of same name with different signatures. The first one does not accept a map where your parameters would be. This method +is used primarily e.g. from JConsole or similar tooling. JConsole can not accept a map to be sent over JMX so in order to be able to enable it +from there, even without any parameters, use this method. ``BinAuditLogger`` does not need any parameters to run with so invoking this method is fine. +The second one does accept a map with your custom parameters so you can pass them programmatically. ``enableauditlog`` command of ``nodetool`` uses +the first ``enableAuditLog`` method mentioned. Hence, currently, there
[jira] [Commented] (CASSANDRA-15802) Commented-out lines that end in a semicolon cause an error.
[ https://issues.apache.org/jira/browse/CASSANDRA-15802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112299#comment-17112299 ] null commented on CASSANDRA-15802: --- Thanks [~RensGroothuijsen] and [~jwest] for your comments on this. Any idea how it can be patched? [~djoshi] any ideas? This is the only thing holding me back from moving away from Python 2.7 thanks! :) > Commented-out lines that end in a semicolon cause an error. > --- > > Key: CASSANDRA-15802 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15802 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter, CQL/Syntax >Reporter: null >Priority: Normal > Attachments: cqlsh.png > > > Commented-out lines that end in a semicolon cause an error. > For example: > /* > describe keyspaces; > */ > > This produces an error: > SyntaxException: line 2:22 no viable alternative at input ' (...* > describe keyspaces;...) > > It works as expected if you use syntax: > -- describe keyspaces; > > Environment: > python:3.7.7-slim-stretch (docker image) > > I found that this was first seen here, and was patched, but the bug appears > to have resurfaced: > https://issues.apache.org/jira/browse/CASSANDRA-2488 -- 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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112260#comment-17112260 ] Ekaterina Dimitrova commented on CASSANDRA-15783: - Thanks [~bdeggleston] Can you or [~djoshi] commit it, please? I am not a committer. Thanks in advance! > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 20m > Remaining Estimate: 0h > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15700) Performance regression on internode messaging
[
https://issues.apache.org/jira/browse/CASSANDRA-15700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112255#comment-17112255
]
Aleksey Yeschenko commented on CASSANDRA-15700:
---
On {{id()}} change: the only frequent callers of it are {{onOverloaded()}} and
{{onExpired()}} callbacks, via {{noSpamLogger.warn()}}. To get rid of these we
could pass {{OutboundConnection}} instance as argument itself instead of
explicitly invoking {{id()}}, as {{toString()}} is overloaded to return
{{id()}}, and will only be invoked by formatter if we should log - no more than
once in every 30 seconds. I think the code is a bit cleaner without that
change, though don't mind it too strongly.
> Performance regression on internode messaging
> -
>
> Key: CASSANDRA-15700
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15700
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Sergio Bossa
>Assignee: Sergio Bossa
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-beta
>
> Attachments: Oss40patchedvsOss311.png, Oss40vsOss311.png, oss40.gc,
> oss40_nogc.tar.xz, oss40_system.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Me and [~jasonstack] have been investigating a performance regression
> affecting 4.0 during a 3 nodes, RF 3 write throughput test with a timeseries
> like workload, as shown in this plot, where blue is 3.11 and orange is 4.0:
> !Oss40vsOss311.png|width=389,height=214!
> It's been a bit of a long investigation, but two clues ended up standing out:
> 1) An abnormal number of expired messages on 4.0 (as shown in the attached
> system log), while 3.11 has almost none.
> 2) An abnormal GC activity (as shown in the attached gc log).
> Turns out the two are related, as the [on expired
> callback|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundConnection.java#L462]
> creates a huge amount of strings in the {{id()}} call. The next question is
> what causes all those message expirations; we thoroughly reviewed the
> internode messaging code and the only issue we could find so far is related
> to the "batch pruning" calls
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L81]
> and
> [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L188]:
> it _seems_ too much time is spent on those, causing the event loop to fall
> behind in processing the rest of the messages, which will end up being
> expired. This is supported by the analysis of the collapsed stacks (after
> fixing the GC issue):
> {noformat}
> (tprint (top-aggregated-calls oss40nogc "EventLoopDelivery:doRun" 5))
> org/apache/cassandra/net/OutboundConnection$EventLoopDelivery:doRun 3456
> org/apache/cassandra/net/OutboundMessageQueue:access$600 1621
> org/apache/cassandra/net/PrunableArrayQueue:prune 1621
> org/apache/cassandra/net/OutboundMessageQueue$WithLock:close 1621
> org/apache/cassandra/net/OutboundMessageQueue:pruneInternalQueueWithLock 1620
> {noformat}
> Those are the top 5 sampled calls from {{EventLoopDelivery#doRun()}} which
> spends half of its time pruning. But only a tiny portion of such pruning time
> is spent actually expiring:
> {noformat}
> (tprint (top-aggregated-calls oss40nogc
> "OutboundMessageQueue:pruneInternalQueueWithLock" 5))
> org/apache/cassandra/net/OutboundMessageQueue:pruneInternalQueueWithLock 1900
> org/apache/cassandra/net/PrunableArrayQueue:prune 1894
> org/apache/cassandra/net/OutboundMessageQueue$1Pruner:onPruned 147
> org/apache/cassandra/net/OutboundConnection$$Lambda$444/740904487:accept 147
> org/apache/cassandra/net/OutboundConnection:onExpired 147
> {noformat}
> And indeed, the {{PrunableArrayQueue:prune()}} self time is dominant:
> {noformat}
> (tprint (top-self-calls oss40nogc "PrunableArrayQueue:prune" 5))
> org/apache/cassandra/net/PrunableArrayQueue:prune 1718
> org/apache/cassandra/net/OutboundConnection:releaseCapacity 27
> java/util/concurrent/ConcurrentHashMap:replaceNode 19
> java/util/concurrent/ConcurrentLinkedQueue:offer 16
> java/util/concurrent/LinkedBlockingQueue:offer 15
> {noformat}
> That said, before proceeding with a PR to fix those issues, I'd like to
> understand: what's the reason to prune so often, rather than just when
> polling the message during delivery? If there's a reason I'm missing, let's
> talk about how to optimize pruning, otherwise let's get rid of that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands,
[jira] [Assigned] (CASSANDRA-12126) CAS Reads Inconsistencies
[ https://issues.apache.org/jira/browse/CASSANDRA-12126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne reassigned CASSANDRA-12126: Assignee: Sylvain Lebresne > CAS Reads Inconsistencies > -- > > Key: CASSANDRA-12126 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12126 > Project: Cassandra > Issue Type: Bug > Components: Feature/Lightweight Transactions, Legacy/Coordination >Reporter: Sankalp Kohli >Assignee: Sylvain Lebresne >Priority: Normal > Labels: LWT, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > While looking at the CAS code in Cassandra, I found a potential issue with > CAS Reads. Here is how it can happen with RF=3 > 1) You issue a CAS Write and it fails in the propose phase. A machine replies > true to a propose and saves the commit in accepted filed. The other two > machines B and C does not get to the accept phase. > Current state is that machine A has this commit in paxos table as accepted > but not committed and B and C does not. > 2) Issue a CAS Read and it goes to only B and C. You wont be able to read the > value written in step 1. This step is as if nothing is inflight. > 3) Issue another CAS Read and it goes to A and B. Now we will discover that > there is something inflight from A and will propose and commit it with the > current ballot. Now we can read the value written in step 1 as part of this > CAS read. > If we skip step 3 and instead run step 4, we will never learn about value > written in step 1. > 4. Issue a CAS Write and it involves only B and C. This will succeed and > commit a different value than step 1. Step 1 value will never be seen again > and was never seen before. > If you read the Lamport “paxos made simple” paper and read section 2.3. It > talks about this issue which is how learners can find out if majority of the > acceptors have accepted the proposal. > In step 3, it is correct that we propose the value again since we dont know > if it was accepted by majority of acceptors. When we ask majority of > acceptors, and more than one acceptors but not majority has something in > flight, we have no way of knowing if it is accepted by majority of acceptors. > So this behavior is correct. > However we need to fix step 2, since it caused reads to not be linearizable > with respect to writes and other reads. In this case, we know that majority > of acceptors have no inflight commit which means we have majority that > nothing was accepted by majority. I think we should run a propose step here > with empty commit and that will cause write written in step 1 to not be > visible ever after. > With this fix, we will either see data written in step 1 on next serial read > or will never see it which is what we want. -- 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-14848) When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non seed nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-14848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112204#comment-17112204
]
Tommy Stendahl commented on CASSANDRA-14848:
I retested this on the latest trunk and the problem is solved, I think it was
solved in CASSANDRA-15727.
I verified this using [~eperott] procedure above using ccm. I also tested
starting the last node with enable_legacy_ssl_storage_port set to false and
that was also working.
> When upgrading 3.11.3->4.0 using SSL 4.0 nodes does not connect to old non
> seed nodes
> -
>
> Key: CASSANDRA-14848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14848
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Tommy Stendahl
>Assignee: Tommy Stendahl
>Priority: Urgent
> Labels: security
> Fix For: 4.0-beta
>
>
> When upgrading from 3.11.3 to 4.0 with server encryption enabled the new 4.0
> node only connects to 3.11.3 seed node, there are no connection established
> to non-seed nodes on the old version.
> I have four nodes, *.242 is upgraded to 4.0, *.243 and *.244 are 3.11.3
> non-seed and *.246 are 3.11.3 seed. After starting the 4.0 node I get this
> nodetool status on the different nodes:
> {noformat}
> *.242
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 1017.77 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> DN 10.216.193.243 743.32 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5
> RAC1
> DN 10.216.193.244 711.54 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 659.81 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.243 and *.244
> -- Address Load Tokens Owns (effective) Host ID Rack
> DN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> *.246
> -- Address Load Tokens Owns (effective) Host ID Rack
> UN 10.216.193.242 657.4 KiB 256 75,1% 7d278e14-d549-42f3-840d-77cfd852fbf4
> RAC1
> UN 10.216.193.243 471 KiB 256 74,8% 5586243a-ca74-4125-8e7e-09e82e23c4e5 RAC1
> UN 10.216.193.244 471.71 KiB 256 75,2% c155e262-b898-4e86-9e1d-d4d0f97e88f6
> RAC1
> UN 10.216.193.246 388.54 KiB 256 74,9% 502dd00f-fc02-4024-b65f-b98ba3808291
> RAC1
> {noformat}
>
> I have built 4.0 with wire tracing activated and in my config the
> storage_port=12700 and ssl_storage_port=12701. In the log I can see that the
> 4.0 node start to connect to the 3.11.3 seed node on the storage_port but
> quickly switch to the ssl_storage_port, but when connecting to the non-seed
> nodes it never switch to the ssl_storage_port.
> {noformat}
> >grep 193.246 system.log | grep Outbound
> 2018-10-25T10:57:36.799+0200 [MessagingService-NettyOutbound-Thread-4-1] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x2f0e5e55] CONNECT:
> /10.216.193.246:12700
> 2018-10-25T10:57:36.902+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c] CONNECT:
> /10.216.193.246:12701
> 2018-10-25T10:57:36.905+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] ACTIVE
> 2018-10-25T10:57:36.906+0200 [MessagingService-NettyOutbound-Thread-4-2] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x9e81f62c,
> L:/10.216.193.242:37252 - R:10.216.193.246/10.216.193.246:12701] WRITE: 8B
> >grep 193.243 system.log | grep Outbound
> 2018-10-25T10:57:38.438+0200 [MessagingService-NettyOutbound-Thread-4-3] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xd8f1d6c4] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.540+0200 [MessagingService-NettyOutbound-Thread-4-4] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0xfde6cc9f] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.694+0200 [MessagingService-NettyOutbound-Thread-4-5] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x7e87fc4e] CONNECT:
> /10.216.193.243:12700
> 2018-10-25T10:57:38.741+0200 [MessagingService-NettyOutbound-Thread-4-7] INFO
> i.n.u.internal.logging.Slf4JLogger:101 info [id: 0x39395296] CONNECT:
> /10.216.193.243:12700{noformat}
>
> When I had the dbug log activated and started the 4.0 node I can see that it
> switch port for *.246 but not for *.243 and *.244.
> {noformat}
> >grep DEBUG system.log| grep OutboundMessagingConnection | grep
> >maybeUpdateConnectionId
>
[jira] [Commented] (CASSANDRA-15806) C* 4.0 is missing a way to identify transient/non-transient SSTables on disk
[ https://issues.apache.org/jira/browse/CASSANDRA-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112195#comment-17112195 ] Ekaterina Dimitrova commented on CASSANDRA-15806: - Thank you [~snazy] > C* 4.0 is missing a way to identify transient/non-transient SSTables on disk > > > Key: CASSANDRA-15806 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15806 > Project: Cassandra > Issue Type: Bug > Components: Tool/sstable >Reporter: sequoyha pelletier >Assignee: sequoyha pelletier >Priority: Normal > Fix For: 4.0-alpha > > Attachments: 15806-4.0.txt > > > Currently, there is no way to identify SSTables that were created as > transient replicated data. Even thought the feature is experimental we should > open that up for those that want to experiment. This seems to be an > oversight. I have added the missing line of code to the SStableMetadataViewer > and will attach a patch shortly. -- 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-15819) nodetool enablefullquerylog doesn't allow caller to make non-blocking
[
https://issues.apache.org/jira/browse/CASSANDRA-15819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15819:
---
Fix Version/s: (was: 4.0-beta)
4.0-alpha
Since Version: 4.0-alpha
Source Control Link:
https://github.com/apache/cassandra/commit/94c52450ed9ad3fd704faef7d395ede5050fcdc3
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into trunk at 94c52450ed9ad3fd704faef7d395ede5050fcdc3
> nodetool enablefullquerylog doesn't allow caller to make non-blocking
> -
>
> Key: CASSANDRA-15819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15819
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> $ ./bin/nodetool enablefullquerylog --path /tmp/deleteme --blocking false
> Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
> nodetool: Found unexpected parameters: [false]
> See 'nodetool help' or 'nodetool help '.
> {code}
> The root cause is boolean is special cased in airlift, so any time —blocking
> is set it gets turned on.
--
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-15819) nodetool enablefullquerylog doesn't allow caller to make non-blocking
[
https://issues.apache.org/jira/browse/CASSANDRA-15819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15819:
---
Status: Ready to Commit (was: Review In Progress)
> nodetool enablefullquerylog doesn't allow caller to make non-blocking
> -
>
> Key: CASSANDRA-15819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15819
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> $ ./bin/nodetool enablefullquerylog --path /tmp/deleteme --blocking false
> Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
> nodetool: Found unexpected parameters: [false]
> See 'nodetool help' or 'nodetool help '.
> {code}
> The root cause is boolean is special cased in airlift, so any time —blocking
> is set it gets turned on.
--
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-15819) nodetool enablefullquerylog doesn't allow caller to make non-blocking
[
https://issues.apache.org/jira/browse/CASSANDRA-15819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112107#comment-17112107
]
Benjamin Lerer commented on CASSANDRA-15819:
+1 Thanks for the patch.
> nodetool enablefullquerylog doesn't allow caller to make non-blocking
> -
>
> Key: CASSANDRA-15819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15819
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> $ ./bin/nodetool enablefullquerylog --path /tmp/deleteme --blocking false
> Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
> nodetool: Found unexpected parameters: [false]
> See 'nodetool help' or 'nodetool help '.
> {code}
> The root cause is boolean is special cased in airlift, so any time —blocking
> is set it gets turned on.
--
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 (714dbe3 -> 94c5245)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 714dbe3 Merge branch 'cassandra-3.11' into trunk add 94c5245 Fix nodetool enablefullquerylog blocking param parsing No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/tools/nodetool/EnableFullQueryLog.java | 14 +++--- 2 files changed, 12 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15748) Provide ability to configure IAuditLogger
[
https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112098#comment-17112098
]
Marcus Eriksson commented on CASSANDRA-15748:
-
{{SettingsTableTest}} is failing:
https://circleci.com/gh/krummas/cassandra/3349#tests/containers/13
> Provide ability to configure IAuditLogger
> -
>
> Key: CASSANDRA-15748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15748
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently there is a parameterless constructor expected for IAuditLogger
> instances. There is not any way how to "inject" configuration properties from
> cassandra.yaml into these concrete classes. This would be very handy for
> custom IAuditLogger implementations.
>
> PR: [https://github.com/apache/cassandra/pull/555]
> [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748]
--
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-15748) Provide ability to configure IAuditLogger
[ https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112075#comment-17112075 ] Marcus Eriksson commented on CASSANDRA-15748: - cci run: [https://circleci.com/gh/krummas/workflows/cassandra/tree/15748] > Provide ability to configure IAuditLogger > - > > Key: CASSANDRA-15748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15748 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > Currently there is a parameterless constructor expected for IAuditLogger > instances. There is not any way how to "inject" configuration properties from > cassandra.yaml into these concrete classes. This would be very handy for > custom IAuditLogger implementations. > > PR: [https://github.com/apache/cassandra/pull/555] > [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748] -- 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-15807) Support multiple keyspaces in Cassandra-Diff
[ https://issues.apache.org/jira/browse/CASSANDRA-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15807: Fix Version/s: 4.0-alpha Resolution: Fixed Status: Resolved (was: Ready to Commit) +1, committed, thanks! > Support multiple keyspaces in Cassandra-Diff > > > Key: CASSANDRA-15807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15807 > Project: Cassandra > Issue Type: Improvement > Components: Tool/diff >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Attachments: local_e2e_log.txt > > > Adding the support to run diff comparison of tables across multiple keyspaces > to avoid bringing up multiple spark jobs and give a better view of data diffs > in the whole cluster. > Cassandra-diff currently only support compare multiple tables under one > single keyspace. -- 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-15807) Support multiple keyspaces in Cassandra-Diff
[ https://issues.apache.org/jira/browse/CASSANDRA-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15807: Reviewers: Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson) Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson) Status: Review In Progress (was: Patch Available) > Support multiple keyspaces in Cassandra-Diff > > > Key: CASSANDRA-15807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15807 > Project: Cassandra > Issue Type: Improvement > Components: Tool/diff >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > Attachments: local_e2e_log.txt > > > Adding the support to run diff comparison of tables across multiple keyspaces > to avoid bringing up multiple spark jobs and give a better view of data diffs > in the whole cluster. > Cassandra-diff currently only support compare multiple tables under one > single keyspace. -- 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-15807) Support multiple keyspaces in Cassandra-Diff
[ https://issues.apache.org/jira/browse/CASSANDRA-15807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15807: Status: Ready to Commit (was: Review In Progress) > Support multiple keyspaces in Cassandra-Diff > > > Key: CASSANDRA-15807 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15807 > Project: Cassandra > Issue Type: Improvement > Components: Tool/diff >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > Attachments: local_e2e_log.txt > > > Adding the support to run diff comparison of tables across multiple keyspaces > to avoid bringing up multiple spark jobs and give a better view of data diffs > in the whole cluster. > Cassandra-diff currently only support compare multiple tables under one > single keyspace. -- 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-diff] branch master updated: Support running diff on multiple keyspaces
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-diff.git
The following commit(s) were added to refs/heads/master by this push:
new e9782c6 Support running diff on multiple keyspaces
e9782c6 is described below
commit e9782c6b59a0888e4c63248ef95468e6b176406d
Author: Yifan Cai
AuthorDate: Fri May 15 13:57:48 2020 -0700
Support running diff on multiple keyspaces
Patch by Yifan Cai; reviewed by marcuse for CASSANDRA-15807
closes #8
---
README.md | 17 ++-
.../cassandra/diff/api/services/DBService.java | 61
common/pom.xml | 7 +
.../apache/cassandra/diff/JobConfiguration.java| 4 +-
.../apache/cassandra/diff/KeyspaceTablePair.java | 61
.../cassandra/diff/YamlJobConfiguration.java | 14 +-
.../cassandra/diff/YamlJobConfigurationTest.java | 16 ++
.../src/test/resources/testconfig.yaml | 10 +-
...onfig.yaml => localconfig-multi-keyspaces.yaml} | 9 +-
spark-job/localconfig.yaml | 8 +-
.../apache/cassandra/diff/ComparisonExecutor.java | 12 +-
.../org/apache/cassandra/diff/DiffCluster.java | 95 +++-
.../java/org/apache/cassandra/diff/DiffJob.java| 57
.../java/org/apache/cassandra/diff/Differ.java | 98 ++---
.../org/apache/cassandra/diff/JobMetadataDb.java | 161 +++--
.../apache/cassandra/diff/PartitionComparator.java | 5 +-
.../org/apache/cassandra/diff/PartitionKey.java| 5 +-
.../org/apache/cassandra/diff/RangeComparator.java | 8 +-
.../java/org/apache/cassandra/diff/RangeStats.java | 5 +-
.../java/org/apache/cassandra/diff/TableSpec.java | 37 +++--
.../org/apache/cassandra/diff/DiffJobTest.java | 3 -
.../java/org/apache/cassandra/diff/DifferTest.java | 39 +++--
.../cassandra/diff/PartitionComparatorTest.java| 5 +-
23 files changed, 427 insertions(+), 310 deletions(-)
diff --git a/README.md b/README.md
index 5fab877..c17ef59 100644
--- a/README.md
+++ b/README.md
@@ -41,9 +41,15 @@ $ cd cassandra-diff
$ mvn package
$ docker run --name cas-src -d -p 9042:9042 cassandra:3.0.18
$ docker run --name cas-tgt -d -p 9043:9042 cassandra:latest
-$ docker exec cas-src cassandra-stress write n=1k
-$ docker exec cas-tgt cassandra-stress write n=1k
+# Create 1000 rows in table "standard1" under keyspace "keyspace1"
+$ docker exec cas-src cassandra-stress write n=1k -schema keyspace="keyspace1"
+$ docker exec cas-tgt cassandra-stress write n=1k -schema keyspace="keyspace1"
+# Optionally, create another 1000 rows in table "standard1" under keyspace
"keyspace2"
+$ docker exec cas-src cassandra-stress write n=1k -schema keyspace="keyspace2"
+$ docker exec cas-tgt cassandra-stress write n=1k -schema keyspace="keyspace2"
$ spark-submit --verbose --files ./spark-job/localconfig.yaml --class
org.apache.cassandra.diff.DiffJob
spark-uberjar/target/spark-uberjar-0.2-SNAPSHOT.jar localconfig.yaml
+# If rows are created in "keyspace2", you can run pick up the
localconfig-multi-keyspaces.yaml to compare data across multiple keyspaces! See
the command below.
+# $ spark-submit --verbose --files
./spark-job/localconfig-multi-keyspaces.yaml --class
org.apache.cassandra.diff.DiffJob
spark-uberjar/target/spark-uberjar-0.2-SNAPSHOT.jar
localconfig-multi-keyspaces.yaml
# ... logs
INFO DiffJob:124 - FINISHED: {standard1=Matched Partitions - 1000, Mismatched
Partitions - 0, Partition Errors - 0, Partitions Only In Source - 0, Partitions
Only In Target - 0, Skipped Partitions - 0, Matched Rows - 1000, Matched Values
- 6000, Mismatched Values - 0 }
## start api-server:
@@ -55,9 +61,8 @@ $ curl -s localhost:8089/jobs/recent | python -mjson.tool
{
"jobId": "99b8d556-07ed-4bfd-b978-7d9b7b2cc21a",
"buckets": 100,
- "keyspace": "keyspace1",
- "tables": [
- "standard1"
+ "keyspace_tables": [
+ "keyspace1.standard1"
],
"sourceClusterName": "local_test_1",
"sourceClusterDesc": "ContactPoints Cluster: name=name,
dc=datacenter1, contact points= [127.0.0.1]",
@@ -71,7 +76,7 @@ $ curl -s
localhost:8089/jobs/99b8d556-07ed-4bfd-b978-7d9b7b2cc21a/results | pyt
[
{
"jobId": "99b8d556-07ed-4bfd-b978-7d9b7b2cc21a",
- "table": "standard1",
+ "table": "keyspace1.standard1",
"matchedPartitions": 1000,
"mismatchedPartitions": 0,
"matchedRows": 1000,
diff --git
a/api-server/src/main/java/org/apache/cassandra/diff/api/services/DBService.java
b/api-server/src/main/java/org/apache/cassandra/diff/api/services/DBService.java
index 1bf1f88..0a9707a 100644
---
a/api-server/src/main/java/org/apache/cassandra/diff/api/services/DBService.java
+++
[jira] [Updated] (CASSANDRA-13666) Secondary index query on partition key columns might not return partitions with only static data
[
https://issues.apache.org/jira/browse/CASSANDRA-13666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-13666:
---
Fix Version/s: 4.0
3.11.7
3.0.21
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/86e1590042116b35a63a705676ecdffd5dfcde6c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into 3.0 at 86e1590042116b35a63a705676ecdffd5dfcde6c and merged into
3.11 and trunk
> Secondary index query on partition key columns might not return partitions
> with only static data
>
>
> Key: CASSANDRA-13666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13666
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Benjamin Lerer
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The problem can be reproduced with the following test in {{3.0}}:
> {code}
>@Test
> public void testIndexOnPartitionKeyWithPartitionWithoutRows() throws
> Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, s int static,
> v int, PRIMARY KEY((pk1, pk2), c))");
> createIndex("CREATE INDEX ON %s (pk2)");
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 2, 9, 2);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 3, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 4, 1, 1, 9, 1);
> flush();
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, 1, 9, 1),
>row(4, 1, 1, 9, 1));
> execute("DELETE FROM %s WHERE pk1 = ? AND pk2 = ? AND c = ?", 3, 1,
> 1);
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, null, 9, null), // This row will not be returned
>row(4, 1, 1, 9, 1));
> }
> {code}
> The problem seems to be that the index entries for the static data are
> inserted with an empty clustering key. When the first {{SELECT}} is executed
> those entries are removed by {{CompositesSearcher::filterStaleEntries}} which
> consider that those entries are stales. When the second {{SELECT}} is
> executed the index ignore the (3, 1) partition as there is not entry for it
> anymore.
--
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-13666) Secondary index query on partition key columns might not return partitions with only static data
[
https://issues.apache.org/jira/browse/CASSANDRA-13666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-13666:
---
Status: Ready to Commit (was: Review In Progress)
> Secondary index query on partition key columns might not return partitions
> with only static data
>
>
> Key: CASSANDRA-13666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13666
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Benjamin Lerer
>Assignee: Berenguer Blasi
>Priority: Normal
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The problem can be reproduced with the following test in {{3.0}}:
> {code}
>@Test
> public void testIndexOnPartitionKeyWithPartitionWithoutRows() throws
> Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, s int static,
> v int, PRIMARY KEY((pk1, pk2), c))");
> createIndex("CREATE INDEX ON %s (pk2)");
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 2, 9, 2);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 3, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 4, 1, 1, 9, 1);
> flush();
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, 1, 9, 1),
>row(4, 1, 1, 9, 1));
> execute("DELETE FROM %s WHERE pk1 = ? AND pk2 = ? AND c = ?", 3, 1,
> 1);
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, null, 9, null), // This row will not be returned
>row(4, 1, 1, 9, 1));
> }
> {code}
> The problem seems to be that the index entries for the static data are
> inserted with an empty clustering key. When the first {{SELECT}} is executed
> those entries are removed by {{CompositesSearcher::filterStaleEntries}} which
> consider that those entries are stales. When the second {{SELECT}} is
> executed the index ignore the (3, 1) partition as there is not entry for it
> anymore.
--
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-13666) Secondary index query on partition key columns might not return partitions with only static data
[
https://issues.apache.org/jira/browse/CASSANDRA-13666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-13666:
---
Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Status: Review In Progress (was: Patch Available)
> Secondary index query on partition key columns might not return partitions
> with only static data
>
>
> Key: CASSANDRA-13666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13666
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Benjamin Lerer
>Assignee: Berenguer Blasi
>Priority: Normal
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The problem can be reproduced with the following test in {{3.0}}:
> {code}
>@Test
> public void testIndexOnPartitionKeyWithPartitionWithoutRows() throws
> Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, c int, s int static,
> v int, PRIMARY KEY((pk1, pk2), c))");
> createIndex("CREATE INDEX ON %s (pk2)");
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 1, 1, 2, 9, 2);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 3, 1, 1, 9, 1);
> execute("INSERT INTO %s (pk1, pk2, c, s, v) VALUES (?, ?, ?, ?, ?)",
> 4, 1, 1, 9, 1);
> flush();
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, 1, 9, 1),
>row(4, 1, 1, 9, 1));
> execute("DELETE FROM %s WHERE pk1 = ? AND pk2 = ? AND c = ?", 3, 1,
> 1);
> assertRows(execute("SELECT * FROM %s WHERE pk2 = ?", 1),
>row(1, 1, 1, 9, 1),
>row(1, 1, 2, 9, 2),
>row(3, 1, null, 9, null), // This row will not be returned
>row(4, 1, 1, 9, 1));
> }
> {code}
> The problem seems to be that the index entries for the static data are
> inserted with an empty clustering key. When the first {{SELECT}} is executed
> those entries are removed by {{CompositesSearcher::filterStaleEntries}} which
> consider that those entries are stales. When the second {{SELECT}} is
> executed the index ignore the (3, 1) partition as there is not entry for it
> anymore.
--
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] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 714dbe3b671b5aba6386a9440bd272ec646d4efd Merge: 97aeff6 4a4d5e0 Author: Benjamin Lerer AuthorDate: Wed May 20 11:17:49 2020 +0200 Merge branch 'cassandra-3.11' into trunk CHANGES.txt| 1 + .../internal/composites/CompositesSearcher.java| 19 --- .../index/internal/CassandraIndexTest.java | 28 ++ 3 files changed, 45 insertions(+), 3 deletions(-) diff --cc CHANGES.txt index f181c32,f005147..c4e0fdc --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,35 -1,8 +1,36 @@@ -3.11.7 +4.0-alpha5 + * Add isTransient to SSTableMetadataView (CASSANDRA-15806) + * Fix tools/bin/fqltool for all shells (CASSANDRA-15820) + * Fix clearing of legacy size_estimates (CASSANDRA-15776) + * Update port when reconnecting to pre-4.0 SSL storage (CASSANDRA-15727) + * Only calculate dynamicBadnessThreshold once per loop in DynamicEndpointSnitch (CASSANDRA-15798) + * Cleanup redundant nodetool commands added in 4.0 (CASSANDRA-15256) + * Update to Python driver 3.23 for cqlsh (CASSANDRA-15793) + * Add tunable initial size and growth factor to RangeTombstoneList (CASSANDRA-15763) + * Improve debug logging in SSTableReader for index summary (CASSANDRA-15755) + * bin/sstableverify should support user provided token ranges (CASSANDRA-15753) + * Improve logging when mutation passed to commit log is too large (CASSANDRA-14781) + * replace LZ4FastDecompressor with LZ4SafeDecompressor (CASSANDRA-15560) + * Fix buffer pool NPE with concurrent release due to in-progress tiny pool eviction (CASSANDRA-15726) + * Avoid race condition when completing stream sessions (CASSANDRA-15666) + * Flush with fast compressors by default (CASSANDRA-15379) + * Fix CqlInputFormat regression from the switch to system.size_estimates (CASSANDRA-15637) + * Allow sending Entire SSTables over SSL (CASSANDRA-15740) + * Fix CQLSH UTF-8 encoding issue for Python 2/3 compatibility (CASSANDRA-15739) + * Fix batch statement preparation when multiple tables and parameters are used (CASSANDRA-15730) + * Fix regression with traceOutgoingMessage printing message size (CASSANDRA-15687) + * Ensure repaired data tracking reads a consistent amount of data across replicas (CASSANDRA-15601) + * Fix CQLSH to avoid arguments being evaluated (CASSANDRA-15660) + * Correct Visibility and Improve Safety of Methods in LatencyMetrics (CASSANDRA-15597) + * Allow cqlsh to run with Python2.7/Python3.6+ (CASSANDRA-15659,CASSANDRA-15573) + * Improve logging around incremental repair (CASSANDRA-15599) + * Do not check cdc_raw_directory filesystem space if CDC disabled (CASSANDRA-15688) + * Replace array iterators with get by index (CASSANDRA-15394) + * Minimize BTree iterator allocations (CASSANDRA-15389) +Merged from 3.11: * Fix CQL formatting of read command restrictions for slow query log (CASSANDRA-15503) - * Allow sstableloader to use SSL on the native port (CASSANDRA-14904) Merged from 3.0: + * Fix index queries on partition key columns when some partitions contains only static data (CASSANDRA-13666) * Avoid creating duplicate rows during major upgrades (CASSANDRA-15789) * liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted (CASSANDRA-15674) * Fix Debian init start/stop (CASSANDRA-15770) - 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 (e1a0db7 -> 4a4d5e0)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e1a0db7 Merge branch 'cassandra-3.0' into cassandra-3.11 add 86e1590 Fix index queries on partition key columns when some partitions contains only static data add 4a4d5e0 Merge branch cassandra-3.0 into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../internal/composites/CompositesSearcher.java| 19 --- .../index/internal/CassandraIndexTest.java | 28 ++ 3 files changed, 45 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (97aeff6 -> 714dbe3)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 97aeff6 Merge branch 'cassandra-3.11' into trunk add 86e1590 Fix index queries on partition key columns when some partitions contains only static data add 4a4d5e0 Merge branch cassandra-3.0 into cassandra-3.11 new 714dbe3 Merge branch 'cassandra-3.11' into trunk The 1 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: CHANGES.txt| 1 + .../internal/composites/CompositesSearcher.java| 19 --- .../index/internal/CassandraIndexTest.java | 28 ++ 3 files changed, 45 insertions(+), 3 deletions(-) - 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 (4d42c18 -> 86e1590)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 4d42c18 Avoid creating duplicate rows during major upgrades add 86e1590 Fix index queries on partition key columns when some partitions contains only static data No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../internal/composites/CompositesSearcher.java| 19 -- .../index/internal/CassandraIndexTest.java | 29 +- 3 files changed, 46 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15819) nodetool enablefullquerylog doesn't allow caller to make non-blocking
[
https://issues.apache.org/jira/browse/CASSANDRA-15819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15819:
---
Reviewers: Benjamin Lerer, David Capwell (was: David Capwell)
> nodetool enablefullquerylog doesn't allow caller to make non-blocking
> -
>
> Key: CASSANDRA-15819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15819
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> $ ./bin/nodetool enablefullquerylog --path /tmp/deleteme --blocking false
> Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
> nodetool: Found unexpected parameters: [false]
> See 'nodetool help' or 'nodetool help '.
> {code}
> The root cause is boolean is special cased in airlift, so any time —blocking
> is set it gets turned on.
--
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-15805) Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones interacts with collection tombstones
[
https://issues.apache.org/jira/browse/CASSANDRA-15805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111019#comment-17111019
]
Sylvain Lebresne edited comment on CASSANDRA-15805 at 5/20/20, 8:59 AM:
Thanks for the review. I addressed the comments, squash-cleaned, 'merged' into
3.11 and started CI (first try at https://ci-cassandra.apache.org, not sure how
that will go).
||branch||CI||
| [3.0|https://github.com/pcmanus/cassandra/commits/C-15805-3.0] |
[ci-cassandra
#131|https://ci-cassandra.apache.org/job/Cassandra-devbranch/131/] |
| [3.11|https://github.com/pcmanus/cassandra/commits/C-15805-3.11] |
[ci-cassandra
#132|https://ci-cassandra.apache.org/job/Cassandra-devbranch/132/] |
was (Author: slebresne):
Thanks for the review. I addressed the comments, squash-cleaned, 'merged' into
3.11 and started CI (first try at https://ci-cassandra.apache.org, not sure how
that will go).
||branch||CI||
| [3.0|https://github.com/pcmanus/cassandra/commits/C-15805-3.0] |
[ci-cassandra
#122|https://ci-cassandra.apache.org/job/Cassandra-devbranch/131/] |
| [3.11|https://github.com/pcmanus/cassandra/commits/C-15805-3.11] |
[ci-cassandra
#123|https://ci-cassandra.apache.org/job/Cassandra-devbranch/132/] |
> Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones
> interacts with collection tombstones
> --
>
> Key: CASSANDRA-15805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15805
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/SSTable
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> The legacy reading code ({{LegacyLayout}} and
> {{UnfilteredDeserializer.OldFormatDeserializer}}) does not handle correctly
> the case where a range tombstone covering multiple rows interacts with a
> collection tombstone.
> A simple example of this problem is if one runs on 2.X:
> {noformat}
> CREATE TABLE t (
> k int,
> c1 text,
> c2 text,
> a text,
> b set,
> c text,
> PRIMARY KEY((k), c1, c2)
> );
> // Delete all rows where c1 is 'A'
> DELETE FROM t USING TIMESTAMP 1 WHERE k = 0 AND c1 = 'A';
> // Inserts a row covered by that previous range tombstone
> INSERT INTO t(k, c1, c2, a, b, c) VALUES (0, 'A', 'X', 'foo', {'whatever'},
> 'bar') USING TIMESTAMP 2;
> // Delete the collection of that previously inserted row
> DELETE b FROM t USING TIMESTAMP 3 WHERE k = 0 AND c1 = 'A' and c2 = 'X';
> {noformat}
> If the following is ran on 2.X (with everything either flushed in the same
> table or compacted together), then this will result in the inserted row being
> duplicated (one part containing the {{a}} column, the other the {{c}} one).
> I will note that this is _not_ a duplicate of CASSANDRA-15789 and this
> reproduce even with the fix to {{LegacyLayout}} of this ticket. That said,
> the additional code added to CASSANDRA-15789 to force merging duplicated rows
> if they are produced _will_ end up fixing this as a consequence (assuming
> there is no variation of this problem that leads to other visible issues than
> duplicated rows). That said, I "think" we'd still rather fix the source of
> the issue.
--
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] [Assigned] (CASSANDRA-15677) Topology events are not sent to clients if the nodes use the same network interface
[
https://issues.apache.org/jira/browse/CASSANDRA-15677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-15677:
--
Assignee: Bryn Cooke
> Topology events are not sent to clients if the nodes use the same network
> interface
> ---
>
> Key: CASSANDRA-15677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15677
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Alan Boudreault
>Assignee: Bryn Cooke
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-rc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *This bug only happens when the cassandra nodes are configured to use a
> single network interface (ip) but different ports. See CASSANDRA-7544.*
> Issue: The topology events aren't sent to clients. The problem is that the
> port is not taken into account when determining if we send it or not:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624
> To reproduce:
> {code}
> # I think the cassandra-test branch is required to get the -S option
> (USE_SINGLE_INTERFACE)
> ccm create -n4 local40 -v 4.0-alpha2 -S
> {code}
>
> Then run this small python driver script:
> {code}
> import time
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect()
> while True:
> print(cluster.metadata.all_hosts())
> print([h.is_up for h in cluster.metadata.all_hosts()])
> time.sleep(5)
> {code}
> Then decommission a node:
> {code}
> ccm node2 nodetool disablebinary
> ccm node2 nodetool decommission
> {code}
>
> You should see that the node is never removed from the client cluster
> metadata and the reconnector started.
--
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-15805) Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones interacts with collection tombstones
[
https://issues.apache.org/jira/browse/CASSANDRA-15805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111019#comment-17111019
]
Sylvain Lebresne edited comment on CASSANDRA-15805 at 5/20/20, 8:59 AM:
Thanks for the review. I addressed the comments, squash-cleaned, 'merged' into
3.11 and started CI (first try at https://ci-cassandra.apache.org, not sure how
that will go).
||branch||CI||
| [3.0|https://github.com/pcmanus/cassandra/commits/C-15805-3.0] |
[ci-cassandra
#122|https://ci-cassandra.apache.org/job/Cassandra-devbranch/131/] |
| [3.11|https://github.com/pcmanus/cassandra/commits/C-15805-3.11] |
[ci-cassandra
#123|https://ci-cassandra.apache.org/job/Cassandra-devbranch/132/] |
was (Author: slebresne):
Thanks for the review. I addressed the comments, squash-cleaned, 'merged' into
3.11 and started CI (first try at https://ci-cassandra.apache.org, not sure how
that will go).
||branch||CI||
| [3.0|https://github.com/pcmanus/cassandra/commits/C-15805-3.0] |
[ci-cassandra
#122|https://ci-cassandra.apache.org/job/Cassandra-devbranch/122/] |
| [3.11|https://github.com/pcmanus/cassandra/commits/C-15805-3.11] |
[ci-cassandra
#123|https://ci-cassandra.apache.org/job/Cassandra-devbranch/123/] |
> Potential duplicate rows on 2.X->3.X upgrade when multi-rows range tombstones
> interacts with collection tombstones
> --
>
> Key: CASSANDRA-15805
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15805
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/SSTable
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> The legacy reading code ({{LegacyLayout}} and
> {{UnfilteredDeserializer.OldFormatDeserializer}}) does not handle correctly
> the case where a range tombstone covering multiple rows interacts with a
> collection tombstone.
> A simple example of this problem is if one runs on 2.X:
> {noformat}
> CREATE TABLE t (
> k int,
> c1 text,
> c2 text,
> a text,
> b set,
> c text,
> PRIMARY KEY((k), c1, c2)
> );
> // Delete all rows where c1 is 'A'
> DELETE FROM t USING TIMESTAMP 1 WHERE k = 0 AND c1 = 'A';
> // Inserts a row covered by that previous range tombstone
> INSERT INTO t(k, c1, c2, a, b, c) VALUES (0, 'A', 'X', 'foo', {'whatever'},
> 'bar') USING TIMESTAMP 2;
> // Delete the collection of that previously inserted row
> DELETE b FROM t USING TIMESTAMP 3 WHERE k = 0 AND c1 = 'A' and c2 = 'X';
> {noformat}
> If the following is ran on 2.X (with everything either flushed in the same
> table or compacted together), then this will result in the inserted row being
> duplicated (one part containing the {{a}} column, the other the {{c}} one).
> I will note that this is _not_ a duplicate of CASSANDRA-15789 and this
> reproduce even with the fix to {{LegacyLayout}} of this ticket. That said,
> the additional code added to CASSANDRA-15789 to force merging duplicated rows
> if they are produced _will_ end up fixing this as a consequence (assuming
> there is no variation of this problem that leads to other visible issues than
> duplicated rows). That said, I "think" we'd still rather fix the source of
> the issue.
--
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-15667) StreamResultFuture check for completeness is inconsistent, leading to races
[
https://issues.apache.org/jira/browse/CASSANDRA-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091505#comment-17091505
]
Benjamin Lerer edited comment on CASSANDRA-15667 at 5/20/20, 8:05 AM:
--
Jenkins CI runs:
|[4.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/129/]|[3.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/130/]|[3.11|https://ci-cassandra.apache.org/job/Cassandra-devbranch/124/]|
was (Author: blerer):
Jenkins CI runs:
|[4.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/128/]|[3.0|https://ci-cassandra.apache.org/job/Cassandra-devbranch/127/]|[3.11|https://ci-cassandra.apache.org/job/Cassandra-devbranch/124/]|
> StreamResultFuture check for completeness is inconsistent, leading to races
> ---
>
> Key: CASSANDRA-15667
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15667
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
>Reporter: Sergio Bossa
>Assignee: Massimiliano Tomassi
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: log_bootstrap_resumable
>
>
> {{StreamResultFuture#maybeComplete()}} uses
> {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are
> completed, but then accesses each session state via
> {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the
> former relies on the actual {{StreamSession}} state, while the latter on the
> {{SessionInfo}} state, and the two are concurrently updated with no
> coordination whatsoever.
> This leads to races, i.e. apparent in some dtest spurious failures, such as
> {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc
> [~e.dimitrova].
--
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-builds] branch master updated: In Jenkins builds verify the devbranch parameters at the beginning of the build, and add the cassandra-test-report.txt as an artifact to make it easy to grab.
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/master by this push:
new f8ccefe In Jenkins builds verify the devbranch parameters at the
beginning of the build, and add the cassandra-test-report.txt as an artifact to
make it easy to grab.
f8ccefe is described below
commit f8ccefea31a52a5d39862f452398aa34923d3162
Author: mck
AuthorDate: Wed May 20 08:36:22 2020 +0200
In Jenkins builds verify the devbranch parameters at the beginning of the
build, and add the cassandra-test-report.txt as an artifact to make it easy to
grab.
---
jenkins-dsl/cassandra_pipeline.groovy | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/jenkins-dsl/cassandra_pipeline.groovy
b/jenkins-dsl/cassandra_pipeline.groovy
index c3102fb..15de1ce 100644
--- a/jenkins-dsl/cassandra_pipeline.groovy
+++ b/jenkins-dsl/cassandra_pipeline.groovy
@@ -3,9 +3,14 @@ pipeline {
agent { label 'cassandra' }
stages {
stage('Init') {
-steps {
-cleanWs()
-}
+ steps {
+ cleanWs()
+ sh "git clone -b ${BRANCH}
https://github.com/${REPO}/cassandra.git;
+ sh "test -f cassandra/.jenkins/Jenkinsfile"
+ sh "git clone -b ${DTEST_BRANCH} ${DTEST_REPO}"
+ sh "test -f cassandra-dtest/requirements.txt"
+ sh "docker pull ${DOCKER_IMAGE}"
+ }
}
stage('Build') {
steps {
@@ -229,10 +234,16 @@ pipeline {
}
stage('Summary') {
steps {
+sh "rm -fR cassandra-builds"
sh "git clone
https://gitbox.apache.org/repos/asf/cassandra-builds.git;
sh "./cassandra-builds/build-scripts/cassandra-test-report.sh"
junit '**/build/test/**/TEST*.xml,**/cqlshlib.xml,**/nosetests.xml'
}
+post {
+always {
+archiveArtifacts artifacts: 'cassandra-test-report.txt',
fingerprint: true
+}
+}
}
}
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15819) nodetool enablefullquerylog doesn't allow caller to make non-blocking
[
https://issues.apache.org/jira/browse/CASSANDRA-15819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111856#comment-17111856
]
Berenguer Blasi commented on CASSANDRA-15819:
-
Right, I didn't run CI as I saw only a minimal NodeTool test. But thx for
running it, better safe than sorry :-)
> nodetool enablefullquerylog doesn't allow caller to make non-blocking
> -
>
> Key: CASSANDRA-15819
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15819
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> $ ./bin/nodetool enablefullquerylog --path /tmp/deleteme --blocking false
> Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
> nodetool: Found unexpected parameters: [false]
> See 'nodetool help' or 'nodetool help '.
> {code}
> The root cause is boolean is special cased in airlift, so any time —blocking
> is set it gets turned on.
--
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-15789) Rows can get duplicated in mixed major-version clusters and after full upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15789:
Fix Version/s: 4.0-alpha
3.11.7
3.0.21
Since Version: 3.0 alpha 1
Source Control Link:
https://github.com/apache/cassandra/commit/4d42c189fa82b32fd93ae42a164b91e4db62992e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
and committed, thanks!
> Rows can get duplicated in mixed major-version clusters and after full upgrade
> --
>
> Key: CASSANDRA-15789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15789
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Aleksey Yeschenko
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0-alpha
>
>
> In a mixed 2.X/3.X major version cluster a sequence of row deletes,
> collection overwrites, paging, and read repair can cause 3.X nodes to split
> individual rows into several rows with identical clustering. This happens due
> to 2.X paging and RT semantics, and a 3.X {{LegacyLayout}} deficiency.
> To reproduce, set up a 2-node mixed major version cluster with the following
> table:
> {code}
> CREATE TABLE distributed_test_keyspace.tlb (
> pk int,
> ck int,
> v map,
> PRIMARY KEY (pk, ck)
> );
> {code}
> 1. Using either node as the coordinator, delete the row with ck=2 using
> timestamp 1
> {code}
> DELETE FROM tbl USING TIMESTAMP 1 WHERE pk = 1 AND ck = 2;
> {code}
> 2. Using either node as the coordinator, insert the following 3 rows:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 1, {'e':'f'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 3, {'i':'j'}) USING TIMESTAMP 3;
> {code}
> 3. Flush the table on both nodes
> 4. Using the 2.2 node as the coordinator, force read repar by querying the
> table with page size = 2:
>
> {code}
> SELECT * FROM tbl;
> {code}
> 5. Overwrite the row with ck=2 using timestamp 5:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 5;}}
> {code}
> 6. Query the 3.0 node and observe the split row:
> {code}
> cqlsh> select * from distributed_test_keyspace.tlb ;
> pk | ck | v
> ++
> 1 | 1 | {'e': 'f'}
> 1 | 2 | {'g': 'h'}
> 1 | 2 | {'k': 'l'}
> 1 | 3 | {'i': 'j'}
> {code}
> This happens because the read to query the second page ends up generating the
> following mutation for the 3.0 node:
> {code}
> ColumnFamily(tbl -{deletedAt=-9223372036854775808, localDeletion=2147483647,
> ranges=[2:v:_-2:v:!, deletedAt=2, localDeletion=1588588821]
> [2:v:!-2:!, deletedAt=1, localDeletion=1588588821]
> [3:v:_-3:v:!, deletedAt=2, localDeletion=1588588821]}-
> [2:v:63:false:1@3,])
> {code}
> Which on 3.0 side gets incorrectly deserialized as
> {code}
> Mutation(keyspace='distributed_test_keyspace', key='0001', modifications=[
> [distributed_test_keyspace.tbl] key=1
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647
> columns=[[] | [v]]
> Row[info=[ts=-9223372036854775808] ]: ck=2 | del(v)=deletedAt=2,
> localDeletion=1588588821, [v[c]=d ts=3]
> Row[info=[ts=-9223372036854775808] del=deletedAt=1,
> localDeletion=1588588821 ]: ck=2 |
> Row[info=[ts=-9223372036854775808] ]: ck=3 | del(v)=deletedAt=2,
> localDeletion=1588588821
> ])
> {code}
> {{LegacyLayout}} correctly interprets a range tombstone whose start and
> finish {{collectionName}} values don't match as a wrapping fragment of a
> legacy row deletion that's being interrupted by a collection deletion
> (correctly) - see
> [code|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/LegacyLayout.java#L1874-L1889].
> Quoting the comment inline:
> {code}
> // Because of the way RangeTombstoneList work, we can have a tombstone where
> only one of
> // the bound has a collectionName. That happens if we have a big tombstone A
> (spanning one
> // or multiple rows) and a collection tombstone B. In that case,
> RangeTombstoneList will
> // split this into 3 RTs: the first one from the beginning of A to the
> beginning of B,
> // then B, then a third one from the end of B to the end of A. To make this
> simpler, if
> // we detect that case we transform the 1st and 3rd tombstone so they don't
> end in the middle
> // of a row (which is still correct).
> {code}
> {{LegacyLayout#addRowTombstone()}} method then chokes when it encounters such
> a tombstone in the middle of an
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 97aeff6bd66c03d1304cab8334c14e7a19049889
Merge: fdcd0df e1a0db7
Author: Marcus Eriksson
AuthorDate: Wed May 20 08:50:15 2020 +0200
Merge branch 'cassandra-3.11' into trunk
CHANGES.txt| 1 +
src/java/org/apache/cassandra/config/Config.java | 18 ++
.../cassandra/config/DatabaseDescriptor.java | 30 +++
.../db/compaction/CompactionIterator.java | 3 +
.../db/transform/DuplicateRowChecker.java | 139
.../apache/cassandra/repair/RepairRunnable.java| 13 +-
.../cassandra/service/SnapshotVerbHandler.java | 60 +-
.../org/apache/cassandra/service/StorageProxy.java | 54 +
.../cassandra/service/StorageProxyMBean.java | 11 +
.../service/reads/AbstractReadExecutor.java| 3 +-
.../service/reads/repair/RepairedDataVerifier.java | 31 +--
.../cassandra/utils/DiagnosticSnapshotService.java | 199 ++
.../cassandra/distributed/impl/Instance.java | 2 +
.../distributed/test/RepairDigestTrackingTest.java | 4 +-
.../upgrade/MixedModeReadRepairTest.java | 2 +-
.../db/compaction/CompactionIteratorTest.java | 64 +-
.../db/transform/DuplicateRowCheckerTest.java | 234 +
17 files changed, 769 insertions(+), 99 deletions(-)
diff --cc CHANGES.txt
index 56212f9,3506589..f181c32
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,35 -1,8 +1,36 @@@
-3.11.7
+4.0-alpha5
+ * Add isTransient to SSTableMetadataView (CASSANDRA-15806)
+ * Fix tools/bin/fqltool for all shells (CASSANDRA-15820)
+ * Fix clearing of legacy size_estimates (CASSANDRA-15776)
+ * Update port when reconnecting to pre-4.0 SSL storage (CASSANDRA-15727)
+ * Only calculate dynamicBadnessThreshold once per loop in
DynamicEndpointSnitch (CASSANDRA-15798)
+ * Cleanup redundant nodetool commands added in 4.0 (CASSANDRA-15256)
+ * Update to Python driver 3.23 for cqlsh (CASSANDRA-15793)
+ * Add tunable initial size and growth factor to RangeTombstoneList
(CASSANDRA-15763)
+ * Improve debug logging in SSTableReader for index summary (CASSANDRA-15755)
+ * bin/sstableverify should support user provided token ranges
(CASSANDRA-15753)
+ * Improve logging when mutation passed to commit log is too large
(CASSANDRA-14781)
+ * replace LZ4FastDecompressor with LZ4SafeDecompressor (CASSANDRA-15560)
+ * Fix buffer pool NPE with concurrent release due to in-progress tiny pool
eviction (CASSANDRA-15726)
+ * Avoid race condition when completing stream sessions (CASSANDRA-15666)
+ * Flush with fast compressors by default (CASSANDRA-15379)
+ * Fix CqlInputFormat regression from the switch to system.size_estimates
(CASSANDRA-15637)
+ * Allow sending Entire SSTables over SSL (CASSANDRA-15740)
+ * Fix CQLSH UTF-8 encoding issue for Python 2/3 compatibility
(CASSANDRA-15739)
+ * Fix batch statement preparation when multiple tables and parameters are
used (CASSANDRA-15730)
+ * Fix regression with traceOutgoingMessage printing message size
(CASSANDRA-15687)
+ * Ensure repaired data tracking reads a consistent amount of data across
replicas (CASSANDRA-15601)
+ * Fix CQLSH to avoid arguments being evaluated (CASSANDRA-15660)
+ * Correct Visibility and Improve Safety of Methods in LatencyMetrics
(CASSANDRA-15597)
+ * Allow cqlsh to run with Python2.7/Python3.6+
(CASSANDRA-15659,CASSANDRA-15573)
+ * Improve logging around incremental repair (CASSANDRA-15599)
+ * Do not check cdc_raw_directory filesystem space if CDC disabled
(CASSANDRA-15688)
+ * Replace array iterators with get by index (CASSANDRA-15394)
+ * Minimize BTree iterator allocations (CASSANDRA-15389)
+Merged from 3.11:
* Fix CQL formatting of read command restrictions for slow query log
(CASSANDRA-15503)
- * Allow sstableloader to use SSL on the native port (CASSANDRA-14904)
Merged from 3.0:
+ * Avoid creating duplicate rows during major upgrades (CASSANDRA-15789)
* liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if
IndexSummaryRedistribution gets interrupted (CASSANDRA-15674)
* Fix Debian init start/stop (CASSANDRA-15770)
* Fix infinite loop on index query paging in tables with clustering
(CASSANDRA-14242)
diff --cc src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index 85a107f,86d2287..5c753e0
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@@ -2888,225 -2585,39 +2888,255 @@@ public class DatabaseDescripto
return backPressureStrategy;
}
-public static boolean strictRuntimeChecks()
+public static ConsistencyLevel getIdealConsistencyLevel()
{
-return strictRuntimeChecks;
+return conf.ideal_consistency_level;
+}
+
+public static void
[jira] [Updated] (CASSANDRA-15789) Rows can get duplicated in mixed major-version clusters and after full upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15789:
Status: In Progress (was: Patch Available)
> Rows can get duplicated in mixed major-version clusters and after full upgrade
> --
>
> Key: CASSANDRA-15789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15789
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Aleksey Yeschenko
>Assignee: Marcus Eriksson
>Priority: Normal
>
> In a mixed 2.X/3.X major version cluster a sequence of row deletes,
> collection overwrites, paging, and read repair can cause 3.X nodes to split
> individual rows into several rows with identical clustering. This happens due
> to 2.X paging and RT semantics, and a 3.X {{LegacyLayout}} deficiency.
> To reproduce, set up a 2-node mixed major version cluster with the following
> table:
> {code}
> CREATE TABLE distributed_test_keyspace.tlb (
> pk int,
> ck int,
> v map,
> PRIMARY KEY (pk, ck)
> );
> {code}
> 1. Using either node as the coordinator, delete the row with ck=2 using
> timestamp 1
> {code}
> DELETE FROM tbl USING TIMESTAMP 1 WHERE pk = 1 AND ck = 2;
> {code}
> 2. Using either node as the coordinator, insert the following 3 rows:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 1, {'e':'f'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 3, {'i':'j'}) USING TIMESTAMP 3;
> {code}
> 3. Flush the table on both nodes
> 4. Using the 2.2 node as the coordinator, force read repar by querying the
> table with page size = 2:
>
> {code}
> SELECT * FROM tbl;
> {code}
> 5. Overwrite the row with ck=2 using timestamp 5:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 5;}}
> {code}
> 6. Query the 3.0 node and observe the split row:
> {code}
> cqlsh> select * from distributed_test_keyspace.tlb ;
> pk | ck | v
> ++
> 1 | 1 | {'e': 'f'}
> 1 | 2 | {'g': 'h'}
> 1 | 2 | {'k': 'l'}
> 1 | 3 | {'i': 'j'}
> {code}
> This happens because the read to query the second page ends up generating the
> following mutation for the 3.0 node:
> {code}
> ColumnFamily(tbl -{deletedAt=-9223372036854775808, localDeletion=2147483647,
> ranges=[2:v:_-2:v:!, deletedAt=2, localDeletion=1588588821]
> [2:v:!-2:!, deletedAt=1, localDeletion=1588588821]
> [3:v:_-3:v:!, deletedAt=2, localDeletion=1588588821]}-
> [2:v:63:false:1@3,])
> {code}
> Which on 3.0 side gets incorrectly deserialized as
> {code}
> Mutation(keyspace='distributed_test_keyspace', key='0001', modifications=[
> [distributed_test_keyspace.tbl] key=1
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647
> columns=[[] | [v]]
> Row[info=[ts=-9223372036854775808] ]: ck=2 | del(v)=deletedAt=2,
> localDeletion=1588588821, [v[c]=d ts=3]
> Row[info=[ts=-9223372036854775808] del=deletedAt=1,
> localDeletion=1588588821 ]: ck=2 |
> Row[info=[ts=-9223372036854775808] ]: ck=3 | del(v)=deletedAt=2,
> localDeletion=1588588821
> ])
> {code}
> {{LegacyLayout}} correctly interprets a range tombstone whose start and
> finish {{collectionName}} values don't match as a wrapping fragment of a
> legacy row deletion that's being interrupted by a collection deletion
> (correctly) - see
> [code|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/LegacyLayout.java#L1874-L1889].
> Quoting the comment inline:
> {code}
> // Because of the way RangeTombstoneList work, we can have a tombstone where
> only one of
> // the bound has a collectionName. That happens if we have a big tombstone A
> (spanning one
> // or multiple rows) and a collection tombstone B. In that case,
> RangeTombstoneList will
> // split this into 3 RTs: the first one from the beginning of A to the
> beginning of B,
> // then B, then a third one from the end of B to the end of A. To make this
> simpler, if
> // we detect that case we transform the 1st and 3rd tombstone so they don't
> end in the middle
> // of a row (which is still correct).
> {code}
> {{LegacyLayout#addRowTombstone()}} method then chokes when it encounters such
> a tombstone in the middle of an existing row - having seen {{v[c]=d}} first,
> and mistakenly starts a new row, while in the middle of an existing one: (see
> [code|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/LegacyLayout.java#L1500-L1501]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[cassandra] branch cassandra-3.0 updated: Avoid creating duplicate rows during major upgrades
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new 4d42c18 Avoid creating duplicate rows during major upgrades
4d42c18 is described below
commit 4d42c189fa82b32fd93ae42a164b91e4db62992e
Author: Marcus Eriksson
AuthorDate: Mon May 4 09:35:54 2020 +0200
Avoid creating duplicate rows during major upgrades
Patch by Aleksey Yeschenko, Sam Tunnicliffe and Marcus Eriksson;
reviewed by Sylvain Lebresne and Alex Petrov for CASSANDRA-15789
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/config/Config.java | 19 ++
.../cassandra/config/DatabaseDescriptor.java | 31 +++
src/java/org/apache/cassandra/db/LegacyLayout.java | 18 +-
.../db/compaction/CompactionIterator.java | 5 +-
.../db/partitions/AbstractBTreePartition.java | 5 +-
.../db/partitions/ImmutableBTreePartition.java | 2 +-
.../cassandra/db/partitions/PartitionUpdate.java | 25 ++-
.../db/transform/DuplicateRowChecker.java | 139
.../org/apache/cassandra/service/ReadCallback.java | 7 +-
.../cassandra/service/SnapshotVerbHandler.java | 5 +
.../org/apache/cassandra/service/StorageProxy.java | 54 +
.../cassandra/service/StorageProxyMBean.java | 13 ++
.../cassandra/utils/DiagnosticSnapshotService.java | 188
.../cassandra/distributed/impl/Instance.java | 4 +-
.../upgrade/MixedModeReadRepairTest.java | 85
.../distributed/upgrade/UpgradeTestBase.java | 3 +-
.../org/apache/cassandra/db/LegacyLayoutTest.java | 39 +++-
.../db/compaction/CompactionIteratorTest.java | 134
.../db/partition/PartitionUpdateTest.java | 144 +
.../db/transform/DuplicateRowCheckerTest.java | 240 +
21 files changed, 1145 insertions(+), 16 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 0a0a4d5..b875ae1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.21
+ * Avoid creating duplicate rows during major upgrades (CASSANDRA-15789)
* liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if
IndexSummaryRedistribution gets interrupted (CASSANDRA-15674)
* Fix Debian init start/stop (CASSANDRA-15770)
* Fix infinite loop on index query paging in tables with clustering
(CASSANDRA-14242)
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index bc3e3bf..6003bd1 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -361,6 +361,25 @@ public class Config
outboundBindAny = value;
}
+/**
+ * If true, when rows with duplicate clustering keys are detected during a
read or compaction
+ * a snapshot will be taken. In the read case, each a snapshot request
will be issued to each
+ * replica involved in the query, for compaction the snapshot will be
created locally.
+ * These are limited at the replica level so that only a single snapshot
per-day can be taken
+ * via this method.
+ *
+ * This requires check_for_duplicate_rows_during_reads and/or
check_for_duplicate_rows_during_compaction
+ * below to be enabled
+ */
+public volatile boolean snapshot_on_duplicate_row_detection = false;
+
+/**
+ * If these are enabled duplicate keys will get logged, and if
snapshot_on_duplicate_row_detection
+ * is enabled, the table will get snapshotted for offline investigation
+ */
+public volatile boolean check_for_duplicate_rows_during_reads = true;
+public volatile boolean check_for_duplicate_rows_during_compaction = true;
+
public static boolean isClientMode()
{
return isClientMode;
diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
index a161a2a..4b732c2 100644
--- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
+++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java
@@ -2164,4 +2164,35 @@ public class DatabaseDescriptor
{
return strictRuntimeChecks;
}
+
+public static boolean snapshotOnDuplicateRowDetection()
+{
+return conf.snapshot_on_duplicate_row_detection;
+}
+
+public static void setSnapshotOnDuplicateRowDetection(boolean enabled)
+{
+conf.snapshot_on_duplicate_row_detection = enabled;
+}
+
+public static boolean checkForDuplicateRowsDuringReads()
+{
+return conf.check_for_duplicate_rows_during_reads;
+}
+
+public static void setCheckForDuplicateRowsDuringReads(boolean enabled)
+{
+conf.check_for_duplicate_rows_during_reads = enabled;
+}
+
+public static
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit e1a0db798aedc6fcbb02e3076d545581bad28b0e
Merge: 406a859 4d42c18
Author: Marcus Eriksson
AuthorDate: Wed May 20 08:44:06 2020 +0200
Merge branch 'cassandra-3.0' into cassandra-3.11
CHANGES.txt| 1 +
src/java/org/apache/cassandra/config/Config.java | 18 ++
.../cassandra/config/DatabaseDescriptor.java | 31 +++
src/java/org/apache/cassandra/db/LegacyLayout.java | 18 +-
.../db/compaction/CompactionIterator.java | 5 +-
.../db/partitions/AbstractBTreePartition.java | 5 +-
.../db/partitions/ImmutableBTreePartition.java | 2 +-
.../cassandra/db/partitions/PartitionUpdate.java | 26 ++-
.../db/transform/DuplicateRowChecker.java | 139
.../org/apache/cassandra/service/ReadCallback.java | 4 +-
.../cassandra/service/SnapshotVerbHandler.java | 5 +
.../org/apache/cassandra/service/StorageProxy.java | 54 +
.../cassandra/service/StorageProxyMBean.java | 13 ++
.../cassandra/utils/DiagnosticSnapshotService.java | 188
.../cassandra/distributed/impl/Instance.java | 4 +-
.../upgrade/MixedModeReadRepairTest.java | 85 +++
.../distributed/upgrade/UpgradeTestBase.java | 3 +-
.../org/apache/cassandra/db/LegacyLayoutTest.java | 39 +++-
.../db/compaction/CompactionIteratorTest.java | 80 ++-
.../db/partition/PartitionUpdateTest.java | 144
.../db/transform/DuplicateRowCheckerTest.java | 246 +
21 files changed, 1092 insertions(+), 18 deletions(-)
diff --cc CHANGES.txt
index 46625b3,b875ae1..3506589
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,7 -1,5 +1,8 @@@
-3.0.21
+3.11.7
+ * Fix CQL formatting of read command restrictions for slow query log
(CASSANDRA-15503)
+ * Allow sstableloader to use SSL on the native port (CASSANDRA-14904)
+Merged from 3.0:
+ * Avoid creating duplicate rows during major upgrades (CASSANDRA-15789)
* liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if
IndexSummaryRedistribution gets interrupted (CASSANDRA-15674)
* Fix Debian init start/stop (CASSANDRA-15770)
* Fix infinite loop on index query paging in tables with clustering
(CASSANDRA-14242)
diff --cc src/java/org/apache/cassandra/config/Config.java
index 7f28546,6003bd1..322f1f5
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@@ -397,12 -362,29 +397,30 @@@ public class Confi
}
/**
+ * If true, when rows with duplicate clustering keys are detected during
a read or compaction
+ * a snapshot will be taken. In the read case, each a snapshot request
will be issued to each
+ * replica involved in the query, for compaction the snapshot will be
created locally.
+ * These are limited at the replica level so that only a single snapshot
per-day can be taken
+ * via this method.
+ *
+ * This requires check_for_duplicate_rows_during_reads and/or
check_for_duplicate_rows_during_compaction
+ * below to be enabled
+ */
+ public volatile boolean snapshot_on_duplicate_row_detection = false;
-
+ /**
+ * If these are enabled duplicate keys will get logged, and if
snapshot_on_duplicate_row_detection
+ * is enabled, the table will get snapshotted for offline investigation
+ */
+ public volatile boolean check_for_duplicate_rows_during_reads = true;
+ public volatile boolean check_for_duplicate_rows_during_compaction = true;
+
-public static boolean isClientMode()
-{
-return isClientMode;
-}
-
++/**
+ * Client mode means that the process is a pure client, that uses C* code
base but does
+ * not read or write local C* database files.
+ *
+ * @deprecated migrate to {@link
DatabaseDescriptor#clientInitialization(boolean)}
+ */
+@Deprecated
public static void setClientMode(boolean clientMode)
{
isClientMode = clientMode;
diff --cc src/java/org/apache/cassandra/db/LegacyLayout.java
index 09f9cfa,37cc935..4ec0c30
--- a/src/java/org/apache/cassandra/db/LegacyLayout.java
+++ b/src/java/org/apache/cassandra/db/LegacyLayout.java
@@@ -28,8 -28,9 +28,10 @@@ import java.util.stream.Collectors
import org.apache.cassandra.cql3.ColumnIdentifier;
import org.apache.cassandra.cql3.SuperColumnCompatibility;
+import org.apache.cassandra.config.SchemaConstants;
import org.apache.cassandra.utils.AbstractIterator;
+
+ import com.google.common.annotations.VisibleForTesting;
import com.google.common.collect.Iterators;
import com.google.common.collect.Lists;
import com.google.common.collect.PeekingIterator;
diff --cc src/java/org/apache/cassandra/db/compaction/CompactionIterator.java
index
[cassandra] branch trunk updated (fdcd0df -> 97aeff6)
This is an automated email from the ASF dual-hosted git repository. marcuse pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from fdcd0df Fixed non-deterministic test in CasWriteTest new 4d42c18 Avoid creating duplicate rows during major upgrades new e1a0db7 Merge branch 'cassandra-3.0' into cassandra-3.11 new 97aeff6 Merge branch 'cassandra-3.11' into trunk 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: CHANGES.txt| 1 + src/java/org/apache/cassandra/config/Config.java | 18 ++ .../cassandra/config/DatabaseDescriptor.java | 30 +++ .../db/compaction/CompactionIterator.java | 3 + .../db/transform/DuplicateRowChecker.java | 139 .../apache/cassandra/repair/RepairRunnable.java| 13 +- .../cassandra/service/SnapshotVerbHandler.java | 60 +- .../org/apache/cassandra/service/StorageProxy.java | 54 + .../cassandra/service/StorageProxyMBean.java | 11 + .../service/reads/AbstractReadExecutor.java| 3 +- .../service/reads/repair/RepairedDataVerifier.java | 31 +-- .../cassandra/utils/DiagnosticSnapshotService.java | 199 ++ .../cassandra/distributed/impl/Instance.java | 2 + .../distributed/test/RepairDigestTrackingTest.java | 4 +- .../upgrade/MixedModeReadRepairTest.java | 2 +- .../db/compaction/CompactionIteratorTest.java | 64 +- .../db/transform/DuplicateRowCheckerTest.java | 234 + 17 files changed, 769 insertions(+), 99 deletions(-) create mode 100644 src/java/org/apache/cassandra/db/transform/DuplicateRowChecker.java create mode 100644 src/java/org/apache/cassandra/utils/DiagnosticSnapshotService.java create mode 100644 test/unit/org/apache/cassandra/db/transform/DuplicateRowCheckerTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15789) Rows can get duplicated in mixed major-version clusters and after full upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15789:
Status: Patch Available (was: In Progress)
> Rows can get duplicated in mixed major-version clusters and after full upgrade
> --
>
> Key: CASSANDRA-15789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15789
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Aleksey Yeschenko
>Assignee: Marcus Eriksson
>Priority: Normal
>
> In a mixed 2.X/3.X major version cluster a sequence of row deletes,
> collection overwrites, paging, and read repair can cause 3.X nodes to split
> individual rows into several rows with identical clustering. This happens due
> to 2.X paging and RT semantics, and a 3.X {{LegacyLayout}} deficiency.
> To reproduce, set up a 2-node mixed major version cluster with the following
> table:
> {code}
> CREATE TABLE distributed_test_keyspace.tlb (
> pk int,
> ck int,
> v map,
> PRIMARY KEY (pk, ck)
> );
> {code}
> 1. Using either node as the coordinator, delete the row with ck=2 using
> timestamp 1
> {code}
> DELETE FROM tbl USING TIMESTAMP 1 WHERE pk = 1 AND ck = 2;
> {code}
> 2. Using either node as the coordinator, insert the following 3 rows:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 1, {'e':'f'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 3, {'i':'j'}) USING TIMESTAMP 3;
> {code}
> 3. Flush the table on both nodes
> 4. Using the 2.2 node as the coordinator, force read repar by querying the
> table with page size = 2:
>
> {code}
> SELECT * FROM tbl;
> {code}
> 5. Overwrite the row with ck=2 using timestamp 5:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 5;}}
> {code}
> 6. Query the 3.0 node and observe the split row:
> {code}
> cqlsh> select * from distributed_test_keyspace.tlb ;
> pk | ck | v
> ++
> 1 | 1 | {'e': 'f'}
> 1 | 2 | {'g': 'h'}
> 1 | 2 | {'k': 'l'}
> 1 | 3 | {'i': 'j'}
> {code}
> This happens because the read to query the second page ends up generating the
> following mutation for the 3.0 node:
> {code}
> ColumnFamily(tbl -{deletedAt=-9223372036854775808, localDeletion=2147483647,
> ranges=[2:v:_-2:v:!, deletedAt=2, localDeletion=1588588821]
> [2:v:!-2:!, deletedAt=1, localDeletion=1588588821]
> [3:v:_-3:v:!, deletedAt=2, localDeletion=1588588821]}-
> [2:v:63:false:1@3,])
> {code}
> Which on 3.0 side gets incorrectly deserialized as
> {code}
> Mutation(keyspace='distributed_test_keyspace', key='0001', modifications=[
> [distributed_test_keyspace.tbl] key=1
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647
> columns=[[] | [v]]
> Row[info=[ts=-9223372036854775808] ]: ck=2 | del(v)=deletedAt=2,
> localDeletion=1588588821, [v[c]=d ts=3]
> Row[info=[ts=-9223372036854775808] del=deletedAt=1,
> localDeletion=1588588821 ]: ck=2 |
> Row[info=[ts=-9223372036854775808] ]: ck=3 | del(v)=deletedAt=2,
> localDeletion=1588588821
> ])
> {code}
> {{LegacyLayout}} correctly interprets a range tombstone whose start and
> finish {{collectionName}} values don't match as a wrapping fragment of a
> legacy row deletion that's being interrupted by a collection deletion
> (correctly) - see
> [code|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/LegacyLayout.java#L1874-L1889].
> Quoting the comment inline:
> {code}
> // Because of the way RangeTombstoneList work, we can have a tombstone where
> only one of
> // the bound has a collectionName. That happens if we have a big tombstone A
> (spanning one
> // or multiple rows) and a collection tombstone B. In that case,
> RangeTombstoneList will
> // split this into 3 RTs: the first one from the beginning of A to the
> beginning of B,
> // then B, then a third one from the end of B to the end of A. To make this
> simpler, if
> // we detect that case we transform the 1st and 3rd tombstone so they don't
> end in the middle
> // of a row (which is still correct).
> {code}
> {{LegacyLayout#addRowTombstone()}} method then chokes when it encounters such
> a tombstone in the middle of an existing row - having seen {{v[c]=d}} first,
> and mistakenly starts a new row, while in the middle of an existing one: (see
> [code|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/LegacyLayout.java#L1500-L1501]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[cassandra] branch cassandra-3.11 updated (406a859 -> e1a0db7)
This is an automated email from the ASF dual-hosted git repository. marcuse pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 406a859 Fix CQL formatting of read command restrictions for slow query log new 4d42c18 Avoid creating duplicate rows during major upgrades new e1a0db7 Merge branch 'cassandra-3.0' into cassandra-3.11 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: CHANGES.txt| 1 + src/java/org/apache/cassandra/config/Config.java | 18 ++ .../cassandra/config/DatabaseDescriptor.java | 31 +++ src/java/org/apache/cassandra/db/LegacyLayout.java | 18 +- .../db/compaction/CompactionIterator.java | 5 +- .../db/partitions/AbstractBTreePartition.java | 5 +- .../db/partitions/ImmutableBTreePartition.java | 2 +- .../cassandra/db/partitions/PartitionUpdate.java | 26 ++- .../db/transform/DuplicateRowChecker.java | 139 .../org/apache/cassandra/service/ReadCallback.java | 4 +- .../cassandra/service/SnapshotVerbHandler.java | 5 + .../org/apache/cassandra/service/StorageProxy.java | 54 + .../cassandra/service/StorageProxyMBean.java | 13 ++ .../cassandra/utils/DiagnosticSnapshotService.java | 188 .../cassandra/distributed/impl/Instance.java | 4 +- .../upgrade/MixedModeReadRepairTest.java | 85 +++ .../distributed/upgrade/UpgradeTestBase.java | 3 +- .../org/apache/cassandra/db/LegacyLayoutTest.java | 39 +++- .../db/compaction/CompactionIteratorTest.java | 80 ++- .../db/partition/PartitionUpdateTest.java | 144 .../db/transform/DuplicateRowCheckerTest.java | 246 + 21 files changed, 1092 insertions(+), 18 deletions(-) create mode 100644 src/java/org/apache/cassandra/db/transform/DuplicateRowChecker.java create mode 100644 src/java/org/apache/cassandra/utils/DiagnosticSnapshotService.java create mode 100644 test/unit/org/apache/cassandra/db/transform/DuplicateRowCheckerTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15789) Rows can get duplicated in mixed major-version clusters and after full upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15789:
Reviewers: Alex Petrov, Sylvain Lebresne, Marcus Eriksson (was: Alex
Petrov, Marcus Eriksson, Sylvain Lebresne)
Alex Petrov, Sylvain Lebresne, Marcus Eriksson (was: Alex
Petrov, Sylvain Lebresne)
Status: Review In Progress (was: Patch Available)
> Rows can get duplicated in mixed major-version clusters and after full upgrade
> --
>
> Key: CASSANDRA-15789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15789
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Aleksey Yeschenko
>Assignee: Marcus Eriksson
>Priority: Normal
>
> In a mixed 2.X/3.X major version cluster a sequence of row deletes,
> collection overwrites, paging, and read repair can cause 3.X nodes to split
> individual rows into several rows with identical clustering. This happens due
> to 2.X paging and RT semantics, and a 3.X {{LegacyLayout}} deficiency.
> To reproduce, set up a 2-node mixed major version cluster with the following
> table:
> {code}
> CREATE TABLE distributed_test_keyspace.tlb (
> pk int,
> ck int,
> v map,
> PRIMARY KEY (pk, ck)
> );
> {code}
> 1. Using either node as the coordinator, delete the row with ck=2 using
> timestamp 1
> {code}
> DELETE FROM tbl USING TIMESTAMP 1 WHERE pk = 1 AND ck = 2;
> {code}
> 2. Using either node as the coordinator, insert the following 3 rows:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 1, {'e':'f'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 3, {'i':'j'}) USING TIMESTAMP 3;
> {code}
> 3. Flush the table on both nodes
> 4. Using the 2.2 node as the coordinator, force read repar by querying the
> table with page size = 2:
>
> {code}
> SELECT * FROM tbl;
> {code}
> 5. Overwrite the row with ck=2 using timestamp 5:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 5;}}
> {code}
> 6. Query the 3.0 node and observe the split row:
> {code}
> cqlsh> select * from distributed_test_keyspace.tlb ;
> pk | ck | v
> ++
> 1 | 1 | {'e': 'f'}
> 1 | 2 | {'g': 'h'}
> 1 | 2 | {'k': 'l'}
> 1 | 3 | {'i': 'j'}
> {code}
> This happens because the read to query the second page ends up generating the
> following mutation for the 3.0 node:
> {code}
> ColumnFamily(tbl -{deletedAt=-9223372036854775808, localDeletion=2147483647,
> ranges=[2:v:_-2:v:!, deletedAt=2, localDeletion=1588588821]
> [2:v:!-2:!, deletedAt=1, localDeletion=1588588821]
> [3:v:_-3:v:!, deletedAt=2, localDeletion=1588588821]}-
> [2:v:63:false:1@3,])
> {code}
> Which on 3.0 side gets incorrectly deserialized as
> {code}
> Mutation(keyspace='distributed_test_keyspace', key='0001', modifications=[
> [distributed_test_keyspace.tbl] key=1
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647
> columns=[[] | [v]]
> Row[info=[ts=-9223372036854775808] ]: ck=2 | del(v)=deletedAt=2,
> localDeletion=1588588821, [v[c]=d ts=3]
> Row[info=[ts=-9223372036854775808] del=deletedAt=1,
> localDeletion=1588588821 ]: ck=2 |
> Row[info=[ts=-9223372036854775808] ]: ck=3 | del(v)=deletedAt=2,
> localDeletion=1588588821
> ])
> {code}
> {{LegacyLayout}} correctly interprets a range tombstone whose start and
> finish {{collectionName}} values don't match as a wrapping fragment of a
> legacy row deletion that's being interrupted by a collection deletion
> (correctly) - see
> [code|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/LegacyLayout.java#L1874-L1889].
> Quoting the comment inline:
> {code}
> // Because of the way RangeTombstoneList work, we can have a tombstone where
> only one of
> // the bound has a collectionName. That happens if we have a big tombstone A
> (spanning one
> // or multiple rows) and a collection tombstone B. In that case,
> RangeTombstoneList will
> // split this into 3 RTs: the first one from the beginning of A to the
> beginning of B,
> // then B, then a third one from the end of B to the end of A. To make this
> simpler, if
> // we detect that case we transform the 1st and 3rd tombstone so they don't
> end in the middle
> // of a row (which is still correct).
> {code}
> {{LegacyLayout#addRowTombstone()}} method then chokes when it encounters such
> a tombstone in the middle of an existing row - having seen {{v[c]=d}} first,
> and mistakenly starts a new row, while in the middle of an existing one: (see
>
[jira] [Updated] (CASSANDRA-15789) Rows can get duplicated in mixed major-version clusters and after full upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-15789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15789:
Status: Ready to Commit (was: Review In Progress)
> Rows can get duplicated in mixed major-version clusters and after full upgrade
> --
>
> Key: CASSANDRA-15789
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15789
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Local/Memtable, Local/SSTable
>Reporter: Aleksey Yeschenko
>Assignee: Marcus Eriksson
>Priority: Normal
>
> In a mixed 2.X/3.X major version cluster a sequence of row deletes,
> collection overwrites, paging, and read repair can cause 3.X nodes to split
> individual rows into several rows with identical clustering. This happens due
> to 2.X paging and RT semantics, and a 3.X {{LegacyLayout}} deficiency.
> To reproduce, set up a 2-node mixed major version cluster with the following
> table:
> {code}
> CREATE TABLE distributed_test_keyspace.tlb (
> pk int,
> ck int,
> v map,
> PRIMARY KEY (pk, ck)
> );
> {code}
> 1. Using either node as the coordinator, delete the row with ck=2 using
> timestamp 1
> {code}
> DELETE FROM tbl USING TIMESTAMP 1 WHERE pk = 1 AND ck = 2;
> {code}
> 2. Using either node as the coordinator, insert the following 3 rows:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 1, {'e':'f'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 3;
> INSERT INTO tbl (pk, ck, v) VALUES (1, 3, {'i':'j'}) USING TIMESTAMP 3;
> {code}
> 3. Flush the table on both nodes
> 4. Using the 2.2 node as the coordinator, force read repar by querying the
> table with page size = 2:
>
> {code}
> SELECT * FROM tbl;
> {code}
> 5. Overwrite the row with ck=2 using timestamp 5:
> {code}
> INSERT INTO tbl (pk, ck, v) VALUES (1, 2, {'g':'h'}) USING TIMESTAMP 5;}}
> {code}
> 6. Query the 3.0 node and observe the split row:
> {code}
> cqlsh> select * from distributed_test_keyspace.tlb ;
> pk | ck | v
> ++
> 1 | 1 | {'e': 'f'}
> 1 | 2 | {'g': 'h'}
> 1 | 2 | {'k': 'l'}
> 1 | 3 | {'i': 'j'}
> {code}
> This happens because the read to query the second page ends up generating the
> following mutation for the 3.0 node:
> {code}
> ColumnFamily(tbl -{deletedAt=-9223372036854775808, localDeletion=2147483647,
> ranges=[2:v:_-2:v:!, deletedAt=2, localDeletion=1588588821]
> [2:v:!-2:!, deletedAt=1, localDeletion=1588588821]
> [3:v:_-3:v:!, deletedAt=2, localDeletion=1588588821]}-
> [2:v:63:false:1@3,])
> {code}
> Which on 3.0 side gets incorrectly deserialized as
> {code}
> Mutation(keyspace='distributed_test_keyspace', key='0001', modifications=[
> [distributed_test_keyspace.tbl] key=1
> partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647
> columns=[[] | [v]]
> Row[info=[ts=-9223372036854775808] ]: ck=2 | del(v)=deletedAt=2,
> localDeletion=1588588821, [v[c]=d ts=3]
> Row[info=[ts=-9223372036854775808] del=deletedAt=1,
> localDeletion=1588588821 ]: ck=2 |
> Row[info=[ts=-9223372036854775808] ]: ck=3 | del(v)=deletedAt=2,
> localDeletion=1588588821
> ])
> {code}
> {{LegacyLayout}} correctly interprets a range tombstone whose start and
> finish {{collectionName}} values don't match as a wrapping fragment of a
> legacy row deletion that's being interrupted by a collection deletion
> (correctly) - see
> [code|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/LegacyLayout.java#L1874-L1889].
> Quoting the comment inline:
> {code}
> // Because of the way RangeTombstoneList work, we can have a tombstone where
> only one of
> // the bound has a collectionName. That happens if we have a big tombstone A
> (spanning one
> // or multiple rows) and a collection tombstone B. In that case,
> RangeTombstoneList will
> // split this into 3 RTs: the first one from the beginning of A to the
> beginning of B,
> // then B, then a third one from the end of B to the end of A. To make this
> simpler, if
> // we detect that case we transform the 1st and 3rd tombstone so they don't
> end in the middle
> // of a row (which is still correct).
> {code}
> {{LegacyLayout#addRowTombstone()}} method then chokes when it encounters such
> a tombstone in the middle of an existing row - having seen {{v[c]=d}} first,
> and mistakenly starts a new row, while in the middle of an existing one: (see
> [code|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/LegacyLayout.java#L1500-L1501]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CASSANDRA-14128) Prune dead links from cassandra.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-14128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14128: --- Status: In Progress (was: Patch Available) > Prune dead links from cassandra.apache.org > -- > > Key: CASSANDRA-14128 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14128 > Project: Cassandra > Issue Type: Task > Components: Legacy/Documentation and Website >Reporter: Jeff Jirsa >Assignee: Kurt Greaves >Priority: Low > Labels: lhf > Attachments: 14128-site.patch > > > Lots of dead links on the site, including the homepage. Should do some > pruning cleanup. > Site repo is [here|https://svn.apache.org/repos/asf/cassandra/site/] (in svn) > for anyone who wishes to give this a shot. -- 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-15748) Provide ability to configure IAuditLogger
[ https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111811#comment-17111811 ] Stefan Miklosovic commented on CASSANDRA-15748: --- [~vinaykumarcse] I have added a paragraph into docs here (1). Feel free to squash these commits and merge as you wish. (1) [https://github.com/smiklosovic/cassandra/commit/6c84d675dc2be150e6dbc179da533457b008f0d2] > Provide ability to configure IAuditLogger > - > > Key: CASSANDRA-15748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15748 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > Currently there is a parameterless constructor expected for IAuditLogger > instances. There is not any way how to "inject" configuration properties from > cassandra.yaml into these concrete classes. This would be very handy for > custom IAuditLogger implementations. > > PR: [https://github.com/apache/cassandra/pull/555] > [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748] -- 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
