[jira] [Updated] (CASSANDRA-16161) Validation Compactions causing Java GC pressure
[ https://issues.apache.org/jira/browse/CASSANDRA-16161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16161: --- Fix Version/s: (was: 3.11.8) > Validation Compactions causing Java GC pressure > --- > > Key: CASSANDRA-16161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16161 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/Config, Tool/nodetool >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > Attachments: 16161.patch > > > Validation Compactions are not rate limited which can cause Java GC pressure > and result in spikes in latency. -- 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-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:comment-tabpanel=17226544#comment-17226544
]
Marcus Eriksson edited comment on CASSANDRA-15789 at 11/5/20, 7:32 AM:
---
[~leonz] thanks for letting us know, fixed in
https://github.com/apache/cassandra/commit/fa9bbd431100ceac0af8ca3ea0a3dac407246446
and merged up to 3.11 and trunk
was (Author: krummas):
[~leonz] thanks for letting us known, fixed in
https://github.com/apache/cassandra/commit/fa9bbd431100ceac0af8ca3ea0a3dac407246446
and merged up to 3.11 and trunk
> 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, 4.0-beta1
>
>
> 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}
>
[jira] [Commented] (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:comment-tabpanel=17226544#comment-17226544
]
Marcus Eriksson commented on CASSANDRA-15789:
-
[~leonz] thanks for letting us known, fixed in
https://github.com/apache/cassandra/commit/fa9bbd431100ceac0af8ca3ea0a3dac407246446
and merged up to 3.11 and trunk
> 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, 4.0-beta1
>
>
> 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
>
[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 9960cf17481c9a46141de3ba3cc48c5818fff844 Merge: 3854348 fa9bbd4 Author: Marcus Eriksson AuthorDate: Thu Nov 5 08:20:21 2020 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 src/java/org/apache/cassandra/service/StorageProxyMBean.java | 2 -- 1 file changed, 2 deletions(-) - 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. marcuse pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d68c45eb2a4d6bcea0bac78c1797496988e23ee0 Merge: 7e0c0e5 9960cf1 Author: Marcus Eriksson AuthorDate: Thu Nov 5 08:26:31 2020 +0100 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (7e0c0e5 -> d68c45e)
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 7e0c0e5 Harden sstableupgrade unit test new fa9bbd4 remove bad import from CASSANDRA-15789 new 9960cf1 Merge branch 'cassandra-3.0' into cassandra-3.11 new d68c45e 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: - 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: remove bad import from CASSANDRA-15789
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 fa9bbd4 remove bad import from CASSANDRA-15789
fa9bbd4 is described below
commit fa9bbd431100ceac0af8ca3ea0a3dac407246446
Author: Marcus Eriksson
AuthorDate: Thu Nov 5 08:19:55 2020 +0100
remove bad import from CASSANDRA-15789
---
src/java/org/apache/cassandra/service/StorageProxyMBean.java | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/java/org/apache/cassandra/service/StorageProxyMBean.java
b/src/java/org/apache/cassandra/service/StorageProxyMBean.java
index 047934c..9ec8e64 100644
--- a/src/java/org/apache/cassandra/service/StorageProxyMBean.java
+++ b/src/java/org/apache/cassandra/service/StorageProxyMBean.java
@@ -21,8 +21,6 @@ import java.util.List;
import java.util.Map;
import java.util.Set;
-import org.apache.cassandra.config.DatabaseDescriptor;
-
public interface StorageProxyMBean
{
public long getTotalHints();
-
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 (3854348 -> 9960cf1)
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 3854348 Merge branch 'cassandra-3.0' into cassandra-3.11 new fa9bbd4 remove bad import from CASSANDRA-15789 new 9960cf1 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: src/java/org/apache/cassandra/service/StorageProxyMBean.java | 2 -- 1 file changed, 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226498#comment-17226498 ] Berenguer Blasi commented on CASSANDRA-16121: - Hi [~dcapwell] [~e.dimitrova] thx for looking into this. Unfortunately logs are not reachable atm so that is food for another ticket imo. Details in the PR. > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- 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=17226492#comment-17226492
]
Caleb Rackliffe commented on CASSANDRA-15299:
-
[~ifesdjeen] I think the flow chart is certainly helpful. A couple of very
minor things...
* The arrows from "Is first frame?" look like they are missing "Yes"/"No"
labels.
* Once the frame naming decisions are finalized, there might be a couple labels
that should be updated.
> 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
>
> Attachments: Process CQL Frame.png, V5 Flow Chart.png
>
>
> 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-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:comment-tabpanel=17226467#comment-17226467
]
Leon Zaruvinsky commented on CASSANDRA-15789:
-
Hey all - just wanted to call out that an errant import made it into the
Cassandra 3.11 patch of this PR:
https://github.com/apache/cassandra/blob/4d42c189fa82b32fd93ae42a164b91e4db62992e/src/java/org/apache/cassandra/service/StorageProxyMBean.java#L24
Not a big deal, but noticed this because we publish the MBeans/jmx api as their
own custom-built package and hit a compilation error because the
DatabaseDescriptor wasn't included.
> 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, 4.0-beta1
>
>
> 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).
>
[jira] [Comment Edited] (CASSANDRA-16161) Validation Compactions causing Java GC pressure
[ https://issues.apache.org/jira/browse/CASSANDRA-16161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226450#comment-17226450 ] Stefan Miklosovic edited comment on CASSANDRA-16161 at 11/5/20, 1:44 AM: - Jus to make it clear, we are fixing and focusing on 3.11.x only, right? We are fine with this, our primary concern is to make it happen in 3.11.x, but anyway, we are patching it on our side regardless so no rush. I ve briefly looked and validation compaction logic is rewritten a bit in 4.0 and this stuff does not make sense there anymore ... was (Author: stefan.miklosovic): Jus to make it clear, we are fixing and focusin on 3.11.x only, right? We are fine with this, our primary concern is to make it happen in 3.11.x, but anyway, we are patching it on our side regardless so no rush. I ve briefly looked and validation compaction logic is rewritten a bit in 4.0 and this stuff does not make sense there anymore ... > Validation Compactions causing Java GC pressure > --- > > Key: CASSANDRA-16161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16161 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/Config, Tool/nodetool >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x, 3.11.8 > > Attachments: 16161.patch > > > Validation Compactions are not rate limited which can cause Java GC pressure > and result in spikes in latency. -- 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-16161) Validation Compactions causing Java GC pressure
[ https://issues.apache.org/jira/browse/CASSANDRA-16161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226450#comment-17226450 ] Stefan Miklosovic commented on CASSANDRA-16161: --- Jus to make it clear, we are fixing and focusin on 3.11.x only, right? We are fine with this, our primary concern is to make it happen in 3.11.x, but anyway, we are patching it on our side regardless so no rush. I ve briefly looked and validation compaction logic is rewritten a bit in 4.0 and this stuff does not make sense there anymore ... > Validation Compactions causing Java GC pressure > --- > > Key: CASSANDRA-16161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16161 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/Config, Tool/nodetool >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x, 3.11.8 > > Attachments: 16161.patch > > > Validation Compactions are not rate limited which can cause Java GC pressure > and result in spikes in latency. -- 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-16160) Regression in cqlsh with regard to row id display
[
https://issues.apache.org/jira/browse/CASSANDRA-16160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226398#comment-17226398
]
David Capwell commented on CASSANDRA-16160:
---
we found the table
{code}
CREATE TABLE ks.tbl (
pk1 text,
pk2 text,
c1 timeuuid,
PRIMARY KEY ((pk1, pk2), c1)
) WITH CLUSTERING ORDER BY (c1 DESC)
{code}
> Regression in cqlsh with regard to row id display
> -
>
> Key: CASSANDRA-16160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16160
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-beta
>
>
> When you run a query such as
> {code}
> expand on;
> select * from table_with_clustering_keys where token(partition_key) =
> 1192326969048244361;
> {code}
> We print out a header for each row that looks like the following
> @ Row 1
> In 3.0 all values printed were uniq, but in 4.0 they are no longer unique
> {code}
> $ grep Row 3.0-rows.results | sort | uniq -c | sort -k1 -h -r | head -n 10
> 1 @ Row 999
> 1 @ Row 998
> 1 @ Row 997
> 1 @ Row 996
> 1 @ Row 995
> 1 @ Row 994
> 1 @ Row 993
> 1 @ Row 992
> 1 @ Row 991
> 1 @ Row 990
> {code}
> {code}
> $ grep Row 4.0-rows.results | sort | uniq -c | sort -k1 -h -r | head -n 10
> 10 @ Row 9
> 10 @ Row 8
> 10 @ Row 7
> 10 @ Row 6
> 10 @ Row 5
> 10 @ Row 48
> 10 @ Row 47
> 10 @ Row 46
> 10 @ Row 45
> 10 @ Row 44
> {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-15214) OOMs caught and not rethrown
[ https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15214: -- Reviewers: David Capwell, David Capwell (was: David Capwell) David Capwell, David Capwell Status: Review In Progress (was: Patch Available) > OOMs caught and not rethrown > > > Key: CASSANDRA-15214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15214 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Benedict Elliott Smith >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0, 4.0-rc > > Attachments: oom-experiments.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, > so presently there is no way to ensure that an OOM reaches the JVM handler to > trigger a crash/heapdump. > It may be that the simplest most consistent way to do this would be to have a > single thread spawned at startup that waits for any exceptions we must > propagate to the Runtime. > We could probably submit a patch upstream to Netty, but for a guaranteed > future proof approach, it may be worth paying the cost of a single thread. -- 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-16160) Regression in cqlsh with regard to row id display
[
https://issues.apache.org/jira/browse/CASSANDRA-16160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226382#comment-17226382
]
David Capwell commented on CASSANDRA-16160:
---
[~yifanc] do you remember the schema?
> Regression in cqlsh with regard to row id display
> -
>
> Key: CASSANDRA-16160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16160
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: David Capwell
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-beta
>
>
> When you run a query such as
> {code}
> expand on;
> select * from table_with_clustering_keys where token(partition_key) =
> 1192326969048244361;
> {code}
> We print out a header for each row that looks like the following
> @ Row 1
> In 3.0 all values printed were uniq, but in 4.0 they are no longer unique
> {code}
> $ grep Row 3.0-rows.results | sort | uniq -c | sort -k1 -h -r | head -n 10
> 1 @ Row 999
> 1 @ Row 998
> 1 @ Row 997
> 1 @ Row 996
> 1 @ Row 995
> 1 @ Row 994
> 1 @ Row 993
> 1 @ Row 992
> 1 @ Row 991
> 1 @ Row 990
> {code}
> {code}
> $ grep Row 4.0-rows.results | sort | uniq -c | sort -k1 -h -r | head -n 10
> 10 @ Row 9
> 10 @ Row 8
> 10 @ Row 7
> 10 @ Row 6
> 10 @ Row 5
> 10 @ Row 48
> 10 @ Row 47
> 10 @ Row 46
> 10 @ Row 45
> 10 @ Row 44
> {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] [Commented] (CASSANDRA-16233) remove "replace" from cql reserved words
[ https://issues.apache.org/jira/browse/CASSANDRA-16233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226381#comment-17226381 ] Caleb Rackliffe commented on CASSANDRA-16233: - +1 LGTM > remove "replace" from cql reserved words > > > Key: CASSANDRA-16233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16233 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-7395 (2.2) added “replace” as a reserved word into CQL which causes > client facing outages upgrading from 2.1 to 3.x. The reserved word is not > needed as a reserved word as parsing works just fine removing it from > reserved. > To help upgrade users to the 3.x and 4.x lines, we should remove “replace” > from the reserved word list. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16233) remove "replace" from cql reserved words
[ https://issues.apache.org/jira/browse/CASSANDRA-16233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16233: Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Caleb Rackliffe, Caleb Rackliffe Status: Review In Progress (was: Patch Available) > remove "replace" from cql reserved words > > > Key: CASSANDRA-16233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16233 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-7395 (2.2) added “replace” as a reserved word into CQL which causes > client facing outages upgrading from 2.1 to 3.x. The reserved word is not > needed as a reserved word as parsing works just fine removing it from > reserved. > To help upgrade users to the 3.x and 4.x lines, we should remove “replace” > from the reserved word list. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226373#comment-17226373 ] Ekaterina Dimitrova commented on CASSANDRA-16121: - +1 as soon as David's comment is addressed and the logs are added, thank you for spotting the absence and adding the tests > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- 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-16146) Node state incorrectly set to NORMAL after nodetool disablegossip and enablegossip during bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-16146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226364#comment-17226364
]
David Capwell commented on CASSANDRA-16146:
---
3.x line LGTM
> Node state incorrectly set to NORMAL after nodetool disablegossip and
> enablegossip during bootstrap
> ---
>
> Key: CASSANDRA-16146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16146
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> At high level, {{StorageService#setGossipTokens}} set the gossip state to
> {{NORMAL}} blindly. Therefore, re-enabling gossip (stop and start gossip)
> overrides the actual gossip state.
>
> It could happen in the below scenario.
> # Bootstrap failed. The gossip state remains in {{BOOT}} / {{JOINING}} and
> code execution exits StorageService#initServer.
> # Operator runs nodetool to stop and re-start gossip. The gossip state gets
> flipped to {{NORMAL}}
--
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-16146) Node state incorrectly set to NORMAL after nodetool disablegossip and enablegossip during bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-16146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226352#comment-17226352
]
Yifan Cai commented on CASSANDRA-16146:
---
Updated the 3.0 and 3.11 fixup branchs to correctly finish ring initialization
in the mock gossip mode, instead of enabling GOSSOP in the test.
> Node state incorrectly set to NORMAL after nodetool disablegossip and
> enablegossip during bootstrap
> ---
>
> Key: CASSANDRA-16146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16146
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> At high level, {{StorageService#setGossipTokens}} set the gossip state to
> {{NORMAL}} blindly. Therefore, re-enabling gossip (stop and start gossip)
> overrides the actual gossip state.
>
> It could happen in the below scenario.
> # Bootstrap failed. The gossip state remains in {{BOOT}} / {{JOINING}} and
> code execution exits StorageService#initServer.
> # Operator runs nodetool to stop and re-start gossip. The gossip state gets
> flipped to {{NORMAL}}
--
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-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226335#comment-17226335
]
Stefan Miklosovic edited comment on CASSANDRA-14013 at 11/4/20, 7:05 PM:
-
[~blerer] more to it, I have just added that "tableId" into test, that is just
minor detail, the implementation already copes with that.
Devil is in details, for example, for sstableloader, people might put sstable
into /tmp/some/path/mykeyspace/mytable/(data files), and that "mytable" will
not have any "id" on it ... the solution works with both scenarios. Plus this
"path" might be arbitrary, different from the actual data locations specified
in cassandra.yaml etc ...
What I do not like in particular is that the whole solution feels rather
"spaghetti-like" (I do not want to offend here anybody). I based my solution on
regular expressions.
bq. It seems to me that when we hit a directory named snapshots, it can either
be the snapshots directory or the keyspace directory.
And you can have also a snapshot taken which is called "snapshots" :) That
complicates things ever further. Now what, you have a "snapshots" dir where
snapshots are and there you might have "snapshots" dir which represents the
snapshot taken etc etc ...
was (Author: stefan.miklosovic):
[~blerer] more to it, I have just added that "tableId" into test, that is just
minor detail, the implementation already copes with that.
Devil is in details, for example, for sstableloader, people might put sstable
into /tmp/some/path/mykeyspace/mytable/(data files), and that "mytable" will
not have any "id" on it ... the solution works with both scenarios. Plus this
"path" might be arbitrary, different from the actual data locations specified
in cassandra.yaml etc ...
What I do not like in particular is that the whole solution feels rather
"spaghetti-like" (I do not want to offend here anybody). I based my solution on
regular expressions.
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.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-16146) Node state incorrectly set to NORMAL after nodetool disablegossip and enablegossip during bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-16146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226338#comment-17226338
]
David Capwell commented on CASSANDRA-16146:
---
for the 3.x you added Feature.GOSSIP which wasn't needed in the test, this
tells me the non-gossip state is not fixed; can we fix jvm dtest?
> Node state incorrectly set to NORMAL after nodetool disablegossip and
> enablegossip during bootstrap
> ---
>
> Key: CASSANDRA-16146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16146
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> At high level, {{StorageService#setGossipTokens}} set the gossip state to
> {{NORMAL}} blindly. Therefore, re-enabling gossip (stop and start gossip)
> overrides the actual gossip state.
>
> It could happen in the below scenario.
> # Bootstrap failed. The gossip state remains in {{BOOT}} / {{JOINING}} and
> code execution exits StorageService#initServer.
> # Operator runs nodetool to stop and re-start gossip. The gossip state gets
> flipped to {{NORMAL}}
--
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-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226336#comment-17226336 ] David Capwell commented on CASSANDRA-16121: --- Overall +1 from me, only small comment about keeping the logs > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- 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-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226335#comment-17226335
]
Stefan Miklosovic commented on CASSANDRA-14013:
---
[~blerer] more to it, I have just added that "tableId" into test, that is just
minor detail, the implementation already copes with that.
Devil is in details, for example, for sstableloader, people might put sstable
into /tmp/some/path/mykeyspace/mytable/(data files), and that "mytable" will
not have any "id" on it ... the solution works with both scenarios. Plus this
"path" might be arbitrary, different from the actual data locations specified
in cassandra.yaml etc ...
What I do not like in particular is that the whole solution feels rather
"spaghetti-like" (I do not want to offend here anybody). I based my solution on
regular expressions.
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.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-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226328#comment-17226328 ] David Capwell commented on CASSANDRA-16121: --- sorry for the delay, starting back today. > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- 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-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226324#comment-17226324
]
Stefan Miklosovic commented on CASSANDRA-14013:
---
[~blerer] I put this together
https://github.com/apache/cassandra/pull/798
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.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-16011) sstableupgrade unit test hardening
[
https://issues.apache.org/jira/browse/CASSANDRA-16011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16011:
-
Fix Version/s: 4.0-beta4
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/7e0c0e59c7c5a27df2dfce52f02c2cb7c0eff968
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks.
> sstableupgrade unit test hardening
> --
>
> Key: CASSANDRA-16011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16011
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0, 4.0-beta4
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> During CASSANDRA-15883 / CASSANDRA-15991 it was detected unit test coverage
> for this tool is minimal. There is a unit test to enhance upon under
> {{test/unit/org/apache/cassandra/tools}}.
--
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: Harden sstableupgrade unit test
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams 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 7e0c0e5 Harden sstableupgrade unit test
7e0c0e5 is described below
commit 7e0c0e59c7c5a27df2dfce52f02c2cb7c0eff968
Author: Bereng
AuthorDate: Wed Nov 4 09:01:05 2020 +0100
Harden sstableupgrade unit test
Patch by Berenguer Blasi, reviewed by brandonwilliams for
CASSANDRA-16011
---
.../apache/cassandra/tools/StandaloneUpgrader.java | 6 +-
.../cassandra/io/sstable/LegacySSTableTest.java| 4 +-
.../tools/StandaloneUpgraderOnSStablesTest.java| 157 +
3 files changed, 164 insertions(+), 3 deletions(-)
diff --git a/src/java/org/apache/cassandra/tools/StandaloneUpgrader.java
b/src/java/org/apache/cassandra/tools/StandaloneUpgrader.java
index ed25e42..323dab1 100644
--- a/src/java/org/apache/cassandra/tools/StandaloneUpgrader.java
+++ b/src/java/org/apache/cassandra/tools/StandaloneUpgrader.java
@@ -22,6 +22,7 @@ import java.util.concurrent.TimeUnit;
import org.apache.commons.cli.*;
+import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.db.ColumnFamilyStore;
import org.apache.cassandra.db.Directories;
import org.apache.cassandra.db.Keyspace;
@@ -48,7 +49,10 @@ public class StandaloneUpgrader
public static void main(String args[])
{
Options options = Options.parseArgs(args);
-Util.initDatabaseDescriptor();
+if (Boolean.getBoolean(Util.ALLOW_TOOL_REINIT_FOR_TEST))
+DatabaseDescriptor.toolInitialization(false); //Necessary for
testing
+else
+Util.initDatabaseDescriptor();
try
{
diff --git a/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java
b/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java
index 7a18133..940084f 100644
--- a/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java
+++ b/test/unit/org/apache/cassandra/io/sstable/LegacySSTableTest.java
@@ -445,7 +445,7 @@ public class LegacySSTableTest
new
StreamPlan(StreamOperation.OTHER).transferStreams(FBUtilities.getBroadcastAddressAndPort(),
streams).execute().get();
}
-private static void truncateLegacyTables(String legacyVersion) throws
Exception
+public static void truncateLegacyTables(String legacyVersion) throws
Exception
{
logger.info("Truncating legacy version {}", legacyVersion);
Keyspace.open("legacy_tables").getColumnFamilyStore(String.format("legacy_%s_simple",
legacyVersion)).truncateBlocking();
@@ -463,7 +463,7 @@ public class LegacySSTableTest
Keyspace.open("legacy_tables").getColumnFamilyStore(String.format("legacy_%s_clust_counter",
legacyVersion)).forceMajorCompaction();
}
-private static void loadLegacyTables(String legacyVersion) throws Exception
+public static void loadLegacyTables(String legacyVersion) throws Exception
{
logger.info("Preparing legacy version {}", legacyVersion);
loadLegacyTable("legacy_%s_simple", legacyVersion);
diff --git
a/test/unit/org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java
b/test/unit/org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java
new file mode 100644
index 000..570610b
--- /dev/null
+++ b/test/unit/org/apache/cassandra/tools/StandaloneUpgraderOnSStablesTest.java
@@ -0,0 +1,157 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.tools;
+
+import java.io.File;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.List;
+import java.util.Set;
+import java.util.stream.Collectors;
+
+import org.junit.AfterClass;
+import org.junit.BeforeClass;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+
+import org.apache.cassandra.OrderedJUnit4ClassRunner;
+import org.apache.cassandra.db.ColumnFamilyStore;
+import org.apache.cassandra.db.Keyspace;
+import org.apache.cassandra.exceptions.ConfigurationException;
+import org.apache.cassandra.exceptions.StartupException;
+import
[jira] [Updated] (CASSANDRA-16011) sstableupgrade unit test hardening
[
https://issues.apache.org/jira/browse/CASSANDRA-16011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16011:
-
Status: Ready to Commit (was: Review In Progress)
> sstableupgrade unit test hardening
> --
>
> Key: CASSANDRA-16011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16011
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> During CASSANDRA-15883 / CASSANDRA-15991 it was detected unit test coverage
> for this tool is minimal. There is a unit test to enhance upon under
> {{test/unit/org/apache/cassandra/tools}}.
--
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-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226291#comment-17226291
]
Benjamin Lerer edited comment on CASSANDRA-14013 at 11/4/20, 5:17 PM:
--
It seems to me that when we hit a directory named {{snapshots}}, it can either
be the {{snapshots}} directory or the keyspace directory.
If the directory is the {{snapshots}} directory then we know that its parent
will be the table directory and will have a name with the pattern
{{-}}. By consequence determining if the name is the
{{snapshots}} directory or the keyspace directory should be relatively easy.
was (Author: blerer):
It seems to me that when we hit a directory named {{snapshots}}, it can either
be the {{snapshots}} directory or the keyspace directory.
If the directory is the {{snapshots}} directory then we know that its parent
will be the table directory and will have a name with the pattern
{{-}}.
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.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-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226291#comment-17226291
]
Benjamin Lerer commented on CASSANDRA-14013:
It seems to me that when we hit a directory named {{snapshots}}, it can either
be the {{snapshots}} directory or the keyspace directory.
If the directory is the {{snapshots}} directory then we know that its parent
will be the table directory and will have a name with the pattern
{{-}}.
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.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] [Comment Edited] (CASSANDRA-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226269#comment-17226269
]
Benjamin Lerer edited comment on CASSANDRA-14013 at 11/4/20, 5:10 PM:
--
{quote}The current solution does not count on the fact that for example there
might be also a snapshot / table called "snapshots" as well as "backups" for
example - same for indexes and indexes in backups and snapshots. There might be
also a snapshot called "snapshot" for a keyspace which is called "snapshots"
and table which is called "snapshots" too and so on ... {quote}
[~stefan.miklosovic] I do not believe that tables or indexes named
{{snapshots}} or {{backups}} are trully a problem because their corresponding
directories will have different names.
The directory name for a table named {{snapshots}} is {{snapshots-}}
and the directory name for an index named {{snapshots}} is {{.snapshots}}.
The {{testKeyspaceTableParsing}} is incorrect because it assumes that a table
named {{snapshots}} will result in a directory called {{snapshots}}.
was (Author: blerer):
{quote}The current solution does not count on the fact that for example there
might be also a snapshot / table called "snapshot" as well as "backups" for
example - same for indexes and indexes in backups and snapshots. There might be
also a snapshot called "snapshot" for a keyspace which is called "snapshot" and
table which is called "snapshot" too and so on ... {quote}
[~stefan.miklosovic] I do not believe that tables or indexes named {{snapshot}}
or {{backups}} are trully a problem because their corresponding directories
will have different names.
The directory name for a table named {{snapshot}} is {{snapshot-}} and
the directory name for an index named {{snapshot}} is {{.snapshot}}.
The {{testKeyspaceTableParsing}} is incorrect because it assumes that a table
named {{snapshot}} will result in a directory called {{snapshot}}.
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.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] [Comment Edited] (CASSANDRA-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226269#comment-17226269
]
Benjamin Lerer edited comment on CASSANDRA-14013 at 11/4/20, 4:52 PM:
--
{quote}The current solution does not count on the fact that for example there
might be also a snapshot / table called "snapshot" as well as "backups" for
example - same for indexes and indexes in backups and snapshots. There might be
also a snapshot called "snapshot" for a keyspace which is called "snapshot" and
table which is called "snapshot" too and so on ... {quote}
[~stefan.miklosovic] I do not believe that tables or indexes named {{snapshot}}
or {{backups}} are trully a problem because their corresponding directories
will have different names.
The directory name for a table named {{snapshot}} is {{snapshot-}} and
the directory name for an index named {{snapshot}} is {{.snapshot}}.
The {{testKeyspaceTableParsing}} is incorrect because it assumes that a table
named {{snapshot}} will result in a directory called {{snapshot}}.
was (Author: blerer):
{quote}The current solution does not count on the fact that for example there
might be also a snapshot / table called "snapshot" as well as "backups" for
example - same for indexes and indexes in backups and snapshots. There might be
also a snapshot called "snapshot" for a keyspace which is called "snapshot" and
table which is called "snapshot" too and so on ... {quote}
[~stefan.miklosovic] I do not believe that tables or an indexes named
{{snapshot}} or {{backups}} are trully a problem because their corresponding
directories will have different names.
The directory name for a table named {{snapshot}} is {{snapshot-}} and
the directory name for an index named {{snapshot}} is {{.snapshot}}.
The {{testKeyspaceTableParsing}} is incorrect because it assumes that a table
named {{snapshot}} will result in a directory called {{snapshot}}.
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.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-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226269#comment-17226269
]
Benjamin Lerer commented on CASSANDRA-14013:
{quote}The current solution does not count on the fact that for example there
might be also a snapshot / table called "snapshot" as well as "backups" for
example - same for indexes and indexes in backups and snapshots. There might be
also a snapshot called "snapshot" for a keyspace which is called "snapshot" and
table which is called "snapshot" too and so on ... {quote}
[~stefan.miklosovic] I do not believe that tables or an indexes named
{{snapshot}} or {{backups}} are trully a problem because their corresponding
directories will have different names.
The directory name for a table named {{snapshot}} is {{snapshot-}} and
the directory name for an index named {{snapshot}} is {{.snapshot}}.
The {{testKeyspaceTableParsing}} is incorrect because it assumes that a table
named {{snapshot}} will result in a directory called {{snapshot}}.
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.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] [Comment Edited] (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=17226048#comment-17226048
]
Alex Petrov edited comment on CASSANDRA-15299 at 11/4/20, 1:36 PM:
---
Patch looks good to me, I have only several comments:
* in {{CQLMessageHeader#processLargeMessage}}, we seem to be creating a
{{LargeMessage}} object to call {{processCqlFrame()}} over a frame that is
assembled from a single byte buffer. Maybe we can just call {{processCqlFrame}}
directly?
* this is probably something that we should address outside this ticket, but
still: "corrupt frame recovered" seems to be slightly misleading wording, same
as {{Frame#recoverable}}. We can not recover the frame itself, we just can
skip/drop it. Maybe we can rename this, along with metrics in Messaging, before
they become public in 4.0.
* in {{CQLMessageHeader#processCqlFrame}}, we only call
{{handleErrorAndRelease}}. However, it may theoretically happen that we fail
before we finish {{messageDecoder.decode(channel, frame)}}. Maybe we can do
something like the [1], to make it consistent with what we do in
{{ProtocolDecoder#decode}}?
* in {{CQLMessageHeader$LargeMessage#onComplete}}, we wrap
{{processCqlFrame(assembleFrame()}} call in try/catch which is identical to
try/catch block from {{processCqlFrame}} itself. Just checking if this is
intended.
* in {{Dispatcher#processRequest}}, we can slightly simplify code by declaring
{{FlushItem flushItem}} variable outside try/catch block and assigning a
corresponding value in try or catch, and only calling {{flush}} once.
* during sever bootstrap initialization, we're using deprecated low/high
watermark child options, probably we should use
{{.childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new
WriteBufferWaterMark(8 * 1024, 32 * 1024))}} instead.
* {{SimpleClientBurnTest#random}} is unused
If this is helpful, I've also put nits mentioned above (and a couple cleanups)
in a commit
[here|https://github.com/apache/cassandra/commit/76ee6e00f42446d94679e9c9001c81ebfa9418ab].
* this seems to be test-only, but still might be good to fix, there seems to be
a leak in simple client (see [2])
Not sure if this is helpful, but I've also put together a v5 flow chart, which
might be helpful if anyone wants a quick overview of what's going on in v5.
[1]
{code}
protected void processCqlFrame(Frame frame)
{
M message = null;
try
{
message = messageDecoder.decode(channel, frame);
dispatcher.accept(channel, message, this::toFlushItem);
}
catch (Exception e)
{
if (message == null)
frame.release();
handleErrorAndRelease(e, frame.header);
}
}
{code}
[2]
{code}
ERROR [nioEventLoopGroup-2-2] 2020-11-02 14:52:12,101
ResourceLeakDetector.java:320 - LEAK: ByteBuf.release() was not called before
it's garbage-collected. See
https://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records:
Created at:
io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:363)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:178)
io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:115)
org.apache.cassandra.transport.Message.encode(Message.java:360)
org.apache.cassandra.transport.SimpleClient$InitialHandler$3.write(SimpleClient.java:510)
io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:717)
io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:764)
io.netty.channel.AbstractChannelHandlerContext$WriteTask.run(AbstractChannelHandlerContext.java:1071)
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
java.lang.Thread.run(Thread.java:748)
{code}
was (Author: ifesdjeen):
Patch looks good to me, I have only several comments:
* in {{CQLMessageHeader#processLargeMessage}}, we seem to be creating a
{{LargeMessage}} object to call {{processCqlFrame()}} over a frame that is
assembled from a single byte buffer. Maybe we can just call {{processCqlFrame}}
directly?
* this is probably
[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=17226048#comment-17226048
]
Alex Petrov commented on CASSANDRA-15299:
-
Patch looks good to me, I have only several comments:
* in {{CQLMessageHeader#processLargeMessage}}, we seem to be creating a
{{LargeMessage}} object to call {{processCqlFrame()}} over a frame that is
assembled from a single byte buffer. Maybe we can just call {{processCqlFrame}}
directly?
* this is probably something that we should address outside this ticket, but
still: "corrupt frame recovered" seems to be slightly misleading wording, same
as {{Frame#recoverable}}. We can not recover the frame itself, we just can
skip/drop it. Maybe we can rename this, along with metrics in Messaging, before
they become public in 4.0.
* in {{CQLMessageHeader#processCqlFrame}}, we only call
{{handleErrorAndRelease}}. However, it may theoretically happen that we fail
before we finish {{messageDecoder.decode(channel, frame)}}. Maybe we can do
something like the [1], to make it consistent with what we do in
{{ProtocolDecoder#decode}}?
* in {{CQLMessageHeader$LargeMessage#onComplete}}, we wrap
{{processCqlFrame(assembleFrame()}} call in try/catch which is identical to
try/catch block from {{processCqlFrame}} itself. Just checking if this is
intended.
* in {{Dispatcher#processRequest}}, we can slightly simplify code by declaring
{{FlushItem flushItem}} variable outside try/catch block and assigning a
corresponding value in try or catch, and only calling {{flush}} once.
* during sever bootstrap initialization, we're using deprecated low/high
watermark child options, probably we should use
{{.childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new
WriteBufferWaterMark(8 * 1024, 32 * 1024))}} instead.
* {{SimpleClientBurnTest#random}} is unused
If this is helpful, I've also put nits mentioned above (and a couple cleanups)
in a commit
[here|https://github.com/apache/cassandra/commit/76ee6e00f42446d94679e9c9001c81ebfa9418ab].
Not sure if this is helpful, but I've also put together a v5 flow chart, which
might be helpful if anyone wants a quick overview of what's going on in v5.
[1]
{code}
protected void processCqlFrame(Frame frame)
{
M message = null;
try
{
message = messageDecoder.decode(channel, frame);
dispatcher.accept(channel, message, this::toFlushItem);
}
catch (Exception e)
{
if (message == null)
frame.release();
handleErrorAndRelease(e, frame.header);
}
}
{code}
> 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
>
> Attachments: Process CQL Frame.png, V5 Flow Chart.png
>
>
> 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
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15299:
Attachment: V5 Flow Chart.png
Process CQL Frame.png
> 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
>
> Attachments: Process CQL Frame.png, V5 Flow Chart.png
>
>
> 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] [Updated] (CASSANDRA-16011) sstableupgrade unit test hardening
[
https://issues.apache.org/jira/browse/CASSANDRA-16011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16011:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams
Status: Review In Progress (was: Patch Available)
> sstableupgrade unit test hardening
> --
>
> Key: CASSANDRA-16011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16011
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> During CASSANDRA-15883 / CASSANDRA-15991 it was detected unit test coverage
> for this tool is minimal. There is a unit test to enhance upon under
> {{test/unit/org/apache/cassandra/tools}}.
--
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-16228) TableMetrics are exposed before ColumnFamilyStore is fully initialized
[
https://issues.apache.org/jira/browse/CASSANDRA-16228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16228:
---
Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Status: Review In Progress (was: Patch Available)
> TableMetrics are exposed before ColumnFamilyStore is fully initialized
> --
>
> Key: CASSANDRA-16228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16228
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> The {{ColumnFamilyStore}} exposes the {{TableMetrics}} before it is fully
> initialized, due to that it is possible to perform a call via the metrics
> that access uninitialized part of the {{ColumnFamilyStore}}.
> The following test can be added to ColumnFamilyMetricTest to show the issue:
> {code:java}
> @Test
> public void testStartupRaceConditionOnMetricListeners()
> {
> // Since the ColumnFamilyStore instance reference escapes during the
> construction
> // we have a race condition and listeners can see an instance that is in an
> unknown state.
> // This test just check that all callbacks can access the data without
> throwing any exception.
> registerMetricListener();
> SchemaLoader.createKeyspace("Keyspace2",
> KeyspaceParams.simple(1),
> SchemaLoader.standardCFMD("Keyspace2", "Standard2"));
> }
> private void registerMetricListener()
> {
> CassandraMetricsRegistry.Metrics.addListener(new
> MetricRegistryListener.Base()
> {
> @Override
> public void onGaugeAdded(String name, Gauge gauge)
> {
> gauge.getValue();
> }
> @Override
> public void onGaugeRemoved(String name)
> {
> }
> @Override
> public void onCounterAdded(String name, Counter counter)
> {
> counter.getCount();
> }
> @Override
> public void onCounterRemoved(String name)
> {
> }
> @Override
> public void onHistogramAdded(String name, Histogram histogram)
> {
> histogram.getCount();
> }
> @Override
> public void onHistogramRemoved(String name)
> {
> }
> @Override
> public void onMeterAdded(String name, Meter meter)
> {
> meter.getCount();
> }
> @Override
> public void onMeterRemoved(String name)
> {
> }
> @Override
> public void onTimerAdded(String name, Timer timer)
> {
> timer.getCount();
> }
> @Override
> public void onTimerRemoved(String name)
> {
> }
> });{code}
> While looking into that ticket we also discovered a problem with the used of
> {{Metered}} in {{CacheMetrics}}.
> Metrics reporter looks for metrics classes that are instance of the standard
> codahale classes. Due to that, other Metered implementations are not be
> exposed through the reporter. This ticket will also address that 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] [Updated] (CASSANDRA-16228) TableMetrics are exposed before ColumnFamilyStore is fully initialized
[
https://issues.apache.org/jira/browse/CASSANDRA-16228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16228:
---
Description:
The {{ColumnFamilyStore}} exposes the {{TableMetrics}} before it is fully
initialized, due to that it is possible to perform a call via the metrics that
access uninitialized part of the {{ColumnFamilyStore}}.
The following test can be added to ColumnFamilyMetricTest to show the issue:
{code:java}
@Test
public void testStartupRaceConditionOnMetricListeners()
{
// Since the ColumnFamilyStore instance reference escapes during the
construction
// we have a race condition and listeners can see an instance that is in an
unknown state.
// This test just check that all callbacks can access the data without
throwing any exception.
registerMetricListener();
SchemaLoader.createKeyspace("Keyspace2",
KeyspaceParams.simple(1),
SchemaLoader.standardCFMD("Keyspace2", "Standard2"));
}
private void registerMetricListener()
{
CassandraMetricsRegistry.Metrics.addListener(new MetricRegistryListener.Base()
{
@Override
public void onGaugeAdded(String name, Gauge gauge)
{
gauge.getValue();
}
@Override
public void onGaugeRemoved(String name)
{
}
@Override
public void onCounterAdded(String name, Counter counter)
{
counter.getCount();
}
@Override
public void onCounterRemoved(String name)
{
}
@Override
public void onHistogramAdded(String name, Histogram histogram)
{
histogram.getCount();
}
@Override
public void onHistogramRemoved(String name)
{
}
@Override
public void onMeterAdded(String name, Meter meter)
{
meter.getCount();
}
@Override
public void onMeterRemoved(String name)
{
}
@Override
public void onTimerAdded(String name, Timer timer)
{
timer.getCount();
}
@Override
public void onTimerRemoved(String name)
{
}
});{code}
While looking into that ticket we also discovered a problem with the used of
{{Metered}} in {{CacheMetrics}}.
Metrics reporter looks for metrics classes that are instance of the standard
codahale classes. Due to that, other Metered implementations are not be exposed
through the reporter. This ticket will also address that issue.
was:
The {{ColumnFamilyStore}} exposes the {{TableMetrics}} before it is fully
initialized, due to that it is possible to perform a call via the metrics that
access uninitialized part of the {{ColumnFamilyStore}}.
The following test can be added to ColumnFamilyMetricTest to show the issue:
{code:java}
@Test
public void testStartupRaceConditionOnMetricListeners()
{
// Since the ColumnFamilyStore instance reference escapes during the
construction
// we have a race condition and listeners can see an instance that is in an
unknown state.
// This test just check that all callbacks can access the data without
throwing any exception.
registerMetricListener();
SchemaLoader.createKeyspace("Keyspace2",
KeyspaceParams.simple(1),
SchemaLoader.standardCFMD("Keyspace2", "Standard2"));
}
private void registerMetricListener()
{
CassandraMetricsRegistry.Metrics.addListener(new MetricRegistryListener.Base()
{
@Override
public void onGaugeAdded(String name, Gauge gauge)
{
gauge.getValue();
}
@Override
public void onGaugeRemoved(String name)
{
}
@Override
public void onCounterAdded(String name, Counter counter)
{
counter.getCount();
}
@Override
public void onCounterRemoved(String name)
{
}
@Override
public void onHistogramAdded(String name, Histogram histogram)
{
histogram.getCount();
}
@Override
public void onHistogramRemoved(String name)
{
}
@Override
public void onMeterAdded(String name, Meter meter)
{
meter.getCount();
}
@Override
public void onMeterRemoved(String name)
{
}
@Override
public void onTimerAdded(String name, Timer timer)
{
timer.getCount();
}
@Override
public void onTimerRemoved(String name)
{
}
});{code}
*NOTE:* In order to be able to run the test in 4.0 and use
registerMetricListener() method a small modification to requests in
CacheMetrics is needed. This will be submitted and further explained with a
coming patch.
> TableMetrics are exposed before ColumnFamilyStore is fully initialized
> --
>
> Key: CASSANDRA-16228
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16228
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> The {{ColumnFamilyStore}} exposes the {{TableMetrics}} before it is fully
> initialized, due to that it is possible to perform a call via the metrics
> that access uninitialized part of the {{ColumnFamilyStore}}.
> The following test can be added to
svn commit: r42345 - in /release/cassandra: 2.2.18/ 3.0.22/ 3.11.8/ 4.0-beta2/
Author: mck Date: Wed Nov 4 12:31:48 2020 New Revision: 42345 Log: Remove old releases after Cassandra 2.2.19, 3.0.23, 3.11.9, 4.0-beta3 Removed: release/cassandra/2.2.18/ release/cassandra/3.0.22/ release/cassandra/3.11.8/ release/cassandra/4.0-beta2/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit f45b1edc918877aa285c42d86a23911656c014aa Merge: 93c2d76 3854348 Author: Mick Semb Wever AuthorDate: Wed Nov 4 12:49:22 2020 +0100 Merge branch 'cassandra-3.11' into trunk CHANGES.txt | 5 - build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 11 insertions(+), 2 deletions(-) diff --cc CHANGES.txt index 3586d95,e46731b..bf626ab --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,43 -1,19 +1,46 @@@ -3.11.10 +4.0-beta4 + * Produce consistent tombstone for reads to avoid digest mistmatch (CASSANDRA-15369) + * Fix SSTableloader issue when restoring a table named backups (CASSANDRA-16235) + * Invalid serialized size for responses caused by increasing message time by 1ms which caused extra bytes in size calculation (CASSANDRA-16103) + * Throw BufferOverflowException from DataOutputBuffer for better visibility (CASSANDRA-16214) ++Merged from 3.11: + Merged from 3.0: - * Fix invalid cell value skipping when reading from disk (CASSANDRA-16223) + * Prevent invoking enable/disable gossip when not in NORMAL (CASSANDRA-16146) + -3.11.9 - * Synchronize Keyspace instance store/clear (CASSANDRA-16210) +4.0-beta3 + * Segregate Network and Chunk Cache BufferPools and Recirculate Partially Freed Chunks (CASSANDRA-15229) + * Fail truncation requests when they fail on a replica (CASSANDRA-16208) + * Move compact storage validation earlier in startup process (CASSANDRA-16063) + * Fix ByteBufferAccessor cast exceptions are thrown when trying to query a virtual table (CASSANDRA-16155) + * Consolidate node liveness check for forced repair (CASSANDRA-16113) + * Use unsigned short in ValueAccessor.sliceWithShortLength (CASSANDRA-16147) + * Abort repairs when getting a truncation request (CASSANDRA-15854) + * Remove bad assert when getting active compactions for an sstable (CASSANDRA-15457) + * Avoid failing compactions with very large partitions (CASSANDRA-15164) + * Prevent NPE in StreamMessage in type lookup (CASSANDRA-16131) + * Avoid invalid state transition exception during incremental repair (CASSANDRA-16067) + * Allow zero padding in timestamp serialization (CASSANDRA-16105) + * Add byte array backed cells (CASSANDRA-15393) + * Correctly handle pending ranges with adjacent range movements (CASSANDRA-14801) + * Avoid adding locahost when streaming trivial ranges (CASSANDRA-16099) + * Add nodetool getfullquerylog (CASSANDRA-15988) + * Fix yaml format and alignment in tpstats (CASSANDRA-11402) + * Avoid trying to keep track of RTs for endpoints we won't write to during read repair (CASSANDRA-16084) + * When compaction gets interrupted, the exception should include the compactionId (CASSANDRA-15954) + * Make Table/Keyspace Metric Names Consistent With Each Other (CASSANDRA-15909) + * Mutating sstable component may race with entire-sstable-streaming(ZCS) causing checksum validation failure (CASSANDRA-15861) + * NPE thrown while updating speculative execution time if keyspace is removed during task execution (CASSANDRA-15949) + * Show the progress of data streaming and index build (CASSANDRA-15406) + * Add flag to disable chunk cache and disable by default (CASSANDRA-16036) + * Upgrade to snakeyaml >= 1.26 version for CVE-2017-18640 fix (CASSANDRA-16150) +Merged from 3.11: * Fix ColumnFilter to avoid querying cells of unselected complex columns (CASSANDRA-15977) * Fix memory leak in CompressedChunkReader (CASSANDRA-15880) * Don't attempt value skipping with mixed version cluster (CASSANDRA-15833) - * Avoid failing compactions with very large partitions (CASSANDRA-15164) + * Use IF NOT EXISTS for index and UDT create statements in snapshot schema files (CASSANDRA-13935) * Make sure LCS handles duplicate sstable added/removed notifications correctly (CASSANDRA-14103) Merged from 3.0: - * Prevent invoking enable/disable gossip when not in NORMAL (CASSANDRA-16146) - * Fix OOM when terminating repair session (CASSANDRA-15902) * Avoid marking shutting down nodes as up after receiving gossip shutdown message (CASSANDRA-16094) - * Check SSTables for latest version before dropping compact storage (CASSANDRA-16063) * Handle unexpected columns due to schema races (CASSANDRA-15899) * Add flag to ignore unreplicated keyspaces during repair (CASSANDRA-15160) Merged from 2.2: diff --cc build.xml index 564c967,5a8040e..a02c566 --- a/build.xml +++ b/build.xml @@@ -27,7 -25,7 +27,7 @@@ - - ++ https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --cc debian/changelog index dbbde83,3dae39e..a366395 --- a/debian/changelog +++ b/debian/changelog @@@ -1,4 -1,10 +1,10 @@@ -cassandra (3.11.10)
[cassandra] branch trunk updated (93c2d76 -> f45b1ed)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 93c2d76 Add netstats and tablestats unit tests new 140048f Increment versions to 2.2.20, 3.0.24, 3.11.10, 4.0-beta4 new b6ef9b2 Merge branch 'cassandra-2.2' into cassandra-3.0 new 3854348 Merge branch 'cassandra-3.0' into cassandra-3.11 new f45b1ed Merge branch 'cassandra-3.11' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 5 - build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 11 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 385434881fd7dbd8a678189e5399bf23fb855022 Merge: ec5e242 b6ef9b2 Author: Mick Semb Wever AuthorDate: Wed Nov 4 12:42:41 2020 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 CHANGES.txt | 8 +--- build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 12 insertions(+), 4 deletions(-) diff --cc CHANGES.txt index 2501fcb,696e50f..e46731b --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,14 -1,8 +1,16 @@@ -3.0.24: ++3.11.10 ++Merged from 3.0: + * Fix invalid cell value skipping when reading from disk (CASSANDRA-16223) + * Prevent invoking enable/disable gossip when not in NORMAL (CASSANDRA-16146) + -3.0.23: +3.11.9 + * Synchronize Keyspace instance store/clear (CASSANDRA-16210) + * Fix ColumnFilter to avoid querying cells of unselected complex columns (CASSANDRA-15977) + * Fix memory leak in CompressedChunkReader (CASSANDRA-15880) + * Don't attempt value skipping with mixed version cluster (CASSANDRA-15833) + * Avoid failing compactions with very large partitions (CASSANDRA-15164) + * Make sure LCS handles duplicate sstable added/removed notifications correctly (CASSANDRA-14103) +Merged from 3.0: - 3.0.23: - * Fix invalid cell value skipping when reading from disk (CASSANDRA-16223) - * Prevent invoking enable/disable gossip when not in NORMAL (CASSANDRA-16146) * Fix OOM when terminating repair session (CASSANDRA-15902) * Avoid marking shutting down nodes as up after receiving gossip shutdown message (CASSANDRA-16094) * Check SSTables for latest version before dropping compact storage (CASSANDRA-16063) diff --cc build.xml index 6246386,1851ee9..5a8040e --- a/build.xml +++ b/build.xml @@@ -25,7 -25,7 +25,7 @@@ - - ++ https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --cc debian/changelog index 133f3ac,71f1ac3..3dae39e --- a/debian/changelog +++ b/debian/changelog @@@ -1,4 -1,10 +1,10 @@@ -cassandra (3.0.24) UNRELEASED; urgency=medium ++cassandra (3.11.10) UNRELEASED; urgency=medium + + * New release + - -- Mick Semb Wever Thu, 29 Oct 2020 12:03:40 +0100 ++ -- Mick Semb Wever Thu, 29 Oct 2020 12:32:12 +0100 + -cassandra (3.0.23) unstable; urgency=medium +cassandra (3.11.9) unstable; urgency=medium * New release - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b6ef9b22f2857169f65f3d8ef91d338fa360ad00 Merge: 5a87472 140048f Author: Mick Semb Wever AuthorDate: Wed Nov 4 12:39:33 2020 +0100 Merge branch 'cassandra-2.2' into cassandra-3.0 CHANGES.txt | 4 +++- build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 10 insertions(+), 2 deletions(-) diff --cc CHANGES.txt index 80f5d58,166cca4..696e50f --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,28 -1,12 +1,30 @@@ - 3.0.23: -2.2.20 ++3.0.24: + * Fix invalid cell value skipping when reading from disk (CASSANDRA-16223) + * Prevent invoking enable/disable gossip when not in NORMAL (CASSANDRA-16146) + - -2.2.19 ++3.0.23: + * Fix OOM when terminating repair session (CASSANDRA-15902) + * Avoid marking shutting down nodes as up after receiving gossip shutdown message (CASSANDRA-16094) + * Check SSTables for latest version before dropping compact storage (CASSANDRA-16063) + * Handle unexpected columns due to schema races (CASSANDRA-15899) + * Avoid failing compactions with very large partitions (CASSANDRA-15164) + * Use IF NOT EXISTS for index and UDT create statements in snapshot schema files (CASSANDRA-13935) + * Add flag to ignore unreplicated keyspaces during repair (CASSANDRA-15160) +Merged from 2.2: * Package tools/bin scripts as executable (CASSANDRA-16151) - * Fix ExceptionInInitializerError when data_file_directories is not set (CASSANDRA-16008) * Fixed a NullPointerException when calling nodetool enablethrift (CASSANDRA-16127) -2.2.18 +3.0.22: + * Fix gossip shutdown order (CASSANDRA-15816) + * Remove broken 'defrag-on-read' optimization (CASSANDRA-15432) + * Check for endpoint collision with hibernating nodes (CASSANDRA-14599) + * Operational improvements and hardening for replica filtering protection (CASSANDRA-15907) + * stop_paranoid disk failure policy is ignored on CorruptSSTableException after node is up (CASSANDRA-15191) + * 3.x fails to start if commit log has range tombstones from a column which is also deleted (CASSANDRA-15970) + * Forbid altering UDTs used in partition keys (CASSANDRA-15933) + * Fix empty/null json string representation (CASSANDRA-15896) + * Handle difference in timestamp precision between java8 and java11 in LogFIle.java (CASSANDRA-16050) +Merged from 2.2: * Fix CQL parsing of collections when the column type is reversed (CASSANDRA-15814) Merged from 2.1: * Only allow strings to be passed to JMX authentication (CASSANDRA-16077) diff --cc build.xml index 76c8867,617a993..1851ee9 --- a/build.xml +++ b/build.xml @@@ -25,7 -25,7 +25,7 @@@ - - ++ https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --cc debian/changelog index 2e2a521,79753aa..71f1ac3 --- a/debian/changelog +++ b/debian/changelog @@@ -1,4 -1,10 +1,10 @@@ -cassandra (2.2.20) UNRELEASED; urgency=medium ++cassandra (3.0.24) UNRELEASED; urgency=medium + + * New release + - -- Mick Semb Wever Thu, 29 Oct 2020 11:34:29 +0100 ++ -- Mick Semb Wever Thu, 29 Oct 2020 12:03:40 +0100 + -cassandra (2.2.19) unstable; urgency=medium +cassandra (3.0.23) unstable; urgency=medium * New release - 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 (5a87472 -> b6ef9b2)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 5a87472 Merge branch cassandra-2.2 into cassandra-3.0 new 140048f Increment versions to 2.2.20, 3.0.24, 3.11.10, 4.0-beta4 new b6ef9b2 Merge branch 'cassandra-2.2' into cassandra-3.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 4 +++- build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 10 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated: Increment versions to 2.2.20, 3.0.24, 3.11.10, 4.0-beta4
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-2.2 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-2.2 by this push: new 140048f Increment versions to 2.2.20, 3.0.24, 3.11.10, 4.0-beta4 140048f is described below commit 140048f5b7ec8c75425376bbe60b50b7d41da0ec Author: Mick Semb Wever AuthorDate: Wed Nov 4 12:39:05 2020 +0100 Increment versions to 2.2.20, 3.0.24, 3.11.10, 4.0-beta4 --- CHANGES.txt | 3 +++ build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index 8a78993..166cca4 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,3 +1,6 @@ +2.2.20 + + 2.2.19 * Package tools/bin scripts as executable (CASSANDRA-16151) * Fix ExceptionInInitializerError when data_file_directories is not set (CASSANDRA-16008) diff --git a/build.xml b/build.xml index 4f3818c..617a993 100644 --- a/build.xml +++ b/build.xml @@ -25,7 +25,7 @@ - + https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf/cassandra.git"/> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=tree"/> diff --git a/debian/changelog b/debian/changelog index 6baa078..79753aa 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +cassandra (2.2.20) UNRELEASED; urgency=medium + + * New release + + -- Mick Semb Wever Thu, 29 Oct 2020 11:34:29 +0100 + cassandra (2.2.19) unstable; urgency=medium * New release - 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 (ec5e242 -> 3854348)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ec5e242 Merge branch cassandra-3.0 into cassandra-3.11 new 140048f Increment versions to 2.2.20, 3.0.24, 3.11.10, 4.0-beta4 new b6ef9b2 Merge branch 'cassandra-2.2' into cassandra-3.0 new 3854348 Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 8 +--- build.xml| 2 +- debian/changelog | 6 ++ 3 files changed, 12 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated: ninja-fix: whitespace
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/asf-site by this push: new 17526e8 ninja-fix: whitespace 17526e8 is described below commit 17526e8b9d4a341e6e4e50a26b2c16e381ad9c87 Author: mck AuthorDate: Wed Nov 4 13:16:26 2020 +0100 ninja-fix: whitespace --- content/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/index.html b/content/index.html index f027760..a4392f1 100644 --- a/content/index.html +++ b/content/index.html @@ -93,7 +93,7 @@ Download Cassandra - + https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-beta3;>Cassandra 4.0-beta3 Changelog - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (475edb3 -> ae1de50)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 475edb3 generate docs for 868ce6ba add 90be0f4 Update for new Cassandra releases 2.2.19, 3.0.23, 3.11.9, 4.0-beta3 add ae1de50 generate docs for 90be0f45 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (475edb3) \ N -- N -- N refs/heads/asf-site (ae1de50) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. No new revisions were added by this update. Summary of changes: content/download/index.html | 8 content/feed.xml| 2 +- content/index.html | 2 +- src/_data/releases.yaml | 16 4 files changed, 14 insertions(+), 14 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (475edb3 -> ae1de50)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. omit 475edb3 generate docs for 868ce6ba add 90be0f4 Update for new Cassandra releases 2.2.19, 3.0.23, 3.11.9, 4.0-beta3 new ae1de50 generate docs for 90be0f45 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (475edb3) \ N -- N -- N refs/heads/asf-staging (ae1de50) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. 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: content/download/index.html | 8 content/feed.xml| 2 +- content/index.html | 2 +- src/_data/releases.yaml | 16 4 files changed, 14 insertions(+), 14 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: Update for new Cassandra releases 2.2.19, 3.0.23, 3.11.9, 4.0-beta3
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 90be0f4 Update for new Cassandra releases 2.2.19, 3.0.23, 3.11.9, 4.0-beta3 90be0f4 is described below commit 90be0f45e9ec054980d5c2d503f8fb5d2e7214c4 Author: mck AuthorDate: Wed Nov 4 12:36:35 2020 +0100 Update for new Cassandra releases 2.2.19, 3.0.23, 3.11.9, 4.0-beta3 --- src/_data/releases.yaml | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/_data/releases.yaml b/src/_data/releases.yaml index 5a1eb61..769c127 100644 --- a/src/_data/releases.yaml +++ b/src/_data/releases.yaml @@ -1,18 +1,18 @@ latest: - name: "4.0-beta2" - date: 2020-08-31 + name: "4.0-beta3" + date: 2020-11-04 "3.11": - name: "3.11.8" - date: 2020-08-31 + name: "3.11.9" + date: 2020-11-04 "3.0": - name: "3.0.22" - date: 2020-08-31 + name: "3.0.23" + date: 2020-11-04 "2.2": - name: "2.2.18" - date: 2020-08-31 + name: "2.2.19" + date: 2020-11-04 "2.1": name: "2.1.22" - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42342 - /release/cassandra/4.0-beta3/debian/pool/
Author: mck Date: Wed Nov 4 11:28:26 2020 New Revision: 42342 Log: Apache Cassandra 4.0-beta3 debian artifacts Removed: release/cassandra/4.0-beta3/debian/pool/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42337 - in /release/cassandra: 4.0-beta3/debian/pool/main/c/cassandra/cassandra_4.0~beta3.tar.gz debian/pool/main/c/cassandra/cassandra_4.0~beta3.tar.gz
Author: mck Date: Wed Nov 4 11:28:14 2020 New Revision: 42337 Log: Apache Cassandra 4.0-beta3 debian artifact cassandra_4.0~beta3.tar.gz Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0~beta3.tar.gz - copied unchanged from r42336, release/cassandra/4.0-beta3/debian/pool/main/c/cassandra/cassandra_4.0~beta3.tar.gz Removed: release/cassandra/4.0-beta3/debian/pool/main/c/cassandra/cassandra_4.0~beta3.tar.gz - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42335 - in /release/cassandra: 4.0-beta3/debian/pool/main/c/cassandra/cassandra-tools_4.0~beta3_all.deb debian/pool/main/c/cassandra/cassandra-tools_4.0~beta3_all.deb
Author: mck Date: Wed Nov 4 11:28:05 2020 New Revision: 42335 Log: Apache Cassandra 4.0-beta3 debian artifact cassandra-tools_4.0~beta3_all.deb Added: release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_4.0~beta3_all.deb - copied unchanged from r42334, release/cassandra/4.0-beta3/debian/pool/main/c/cassandra/cassandra-tools_4.0~beta3_all.deb Removed: release/cassandra/4.0-beta3/debian/pool/main/c/cassandra/cassandra-tools_4.0~beta3_all.deb - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42341 - /release/cassandra/4.0-beta3/debian/dists/
Author: mck Date: Wed Nov 4 11:28:25 2020 New Revision: 42341 Log: Apache Cassandra 4.0-beta3 debian artifacts Removed: release/cassandra/4.0-beta3/debian/dists/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42338 - in /release/cassandra: 4.0-beta3/debian/pool/main/c/cassandra/cassandra_4.0~beta3_all.deb debian/pool/main/c/cassandra/cassandra_4.0~beta3_all.deb
Author: mck Date: Wed Nov 4 11:28:17 2020 New Revision: 42338 Log: Apache Cassandra 4.0-beta3 debian artifact cassandra_4.0~beta3_all.deb Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0~beta3_all.deb - copied unchanged from r42337, release/cassandra/4.0-beta3/debian/pool/main/c/cassandra/cassandra_4.0~beta3_all.deb Removed: release/cassandra/4.0-beta3/debian/pool/main/c/cassandra/cassandra_4.0~beta3_all.deb - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42344 - in /release/cassandra: 4.0-beta3/redhat/ redhat/40x/
Author: mck Date: Wed Nov 4 11:28:31 2020 New Revision: 42344 Log: Apache Cassandra 4.0-beta3 redhat artifacts Added: release/cassandra/redhat/40x/ - copied from r42343, release/cassandra/4.0-beta3/redhat/ Removed: release/cassandra/4.0-beta3/redhat/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42343 - /release/cassandra/redhat/40x/
Author: mck Date: Wed Nov 4 11:28:29 2020 New Revision: 42343 Log: Apache Cassandra 4.0-beta3 redhat artifacts Removed: release/cassandra/redhat/40x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42340 - in /release/cassandra: 4.0-beta3/debian/dists/40x/ debian/dists/40x/
Author: mck Date: Wed Nov 4 11:28:23 2020 New Revision: 42340 Log: Apache Cassandra 4.0-beta3 debian artifacts Added: release/cassandra/debian/dists/40x/ - copied from r42339, release/cassandra/4.0-beta3/debian/dists/40x/ Removed: release/cassandra/4.0-beta3/debian/dists/40x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42336 - in /release/cassandra: 4.0-beta3/debian/pool/main/c/cassandra/cassandra_4.0~beta3.dsc debian/pool/main/c/cassandra/cassandra_4.0~beta3.dsc
Author: mck Date: Wed Nov 4 11:28:10 2020 New Revision: 42336 Log: Apache Cassandra 4.0-beta3 debian artifact cassandra_4.0~beta3.dsc Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0~beta3.dsc - copied unchanged from r42335, release/cassandra/4.0-beta3/debian/pool/main/c/cassandra/cassandra_4.0~beta3.dsc Removed: release/cassandra/4.0-beta3/debian/pool/main/c/cassandra/cassandra_4.0~beta3.dsc - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42339 - /release/cassandra/debian/dists/40x/
Author: mck Date: Wed Nov 4 11:28:19 2020 New Revision: 42339 Log: Apache Cassandra 4.0-beta3 debian artifacts Removed: release/cassandra/debian/dists/40x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16162) Improve empty hint file handling on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-16162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16162: --- Fix Version/s: (was: 4.0-beta3) 4.0-beta > Improve empty hint file handling on startup > --- > > Key: CASSANDRA-16162 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16162 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Hints >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > Fix For: 3.0.x, 3.11.x, 4.0-beta > > > Since CASSANDRA-14080 we handle empty/corrupt hint files on startup, we > should remove empty files and rename corrupt ones to make sure we don't get > the same exception on every startup -- 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-15897) Dropping compact storage with 2.1-sstables on disk make them unreadable
[ https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15897: --- Fix Version/s: (was: 4.0-beta3) 4.0-beta > Dropping compact storage with 2.1-sstables on disk make them unreadable > --- > > Key: CASSANDRA-15897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15897 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Marcus Eriksson >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 3.0.x, 4.0-beta > > > Test reproducing: > https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage -- 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
svn commit: r42334 - /dev/cassandra/4.0-beta3/ /release/cassandra/4.0-beta3/
Author: mck Date: Wed Nov 4 11:23:00 2020 New Revision: 42334 Log: Apache Cassandra 4.0-beta3 release Added: release/cassandra/4.0-beta3/ - copied from r42333, dev/cassandra/4.0-beta3/ Removed: dev/cassandra/4.0-beta3/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0-beta3-tentative deleted (was be716b4)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.0-beta3-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag 4.0-beta3-tentative was deleted! *** was be716b4 Prepare debian changelog for 4.0-beta3 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] annotated tag cassandra-4.0-beta3 created (now 65027c9)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to annotated tag cassandra-4.0-beta3 in repository https://gitbox.apache.org/repos/asf/cassandra.git. at 65027c9 (tag) tagging be716b46f2cb3b2d1f01dc225396c6284d5a35de (commit) replaces cassandra-4.0-beta2 by Mick Semb Wever on Wed Nov 4 12:22:11 2020 +0100 - Log - Apache Cassandra 4.0-beta3 release --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42328 - /release/cassandra/debian/dists/311x/
Author: mck Date: Wed Nov 4 11:06:05 2020 New Revision: 42328 Log: Apache Cassandra 3.11.9 debian artifacts Removed: release/cassandra/debian/dists/311x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42332 - /release/cassandra/redhat/311x/
Author: mck Date: Wed Nov 4 11:06:14 2020 New Revision: 42332 Log: Apache Cassandra 3.11.9 redhat artifacts Removed: release/cassandra/redhat/311x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42330 - /release/cassandra/3.11.9/debian/dists/
Author: mck Date: Wed Nov 4 11:06:11 2020 New Revision: 42330 Log: Apache Cassandra 3.11.9 debian artifacts Removed: release/cassandra/3.11.9/debian/dists/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42327 - in /release/cassandra: 3.11.9/debian/pool/main/c/cassandra/cassandra_3.11.9_all.deb debian/pool/main/c/cassandra/cassandra_3.11.9_all.deb
Author: mck Date: Wed Nov 4 11:06:03 2020 New Revision: 42327 Log: Apache Cassandra 3.11.9 debian artifact cassandra_3.11.9_all.deb Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_3.11.9_all.deb - copied unchanged from r42326, release/cassandra/3.11.9/debian/pool/main/c/cassandra/cassandra_3.11.9_all.deb Removed: release/cassandra/3.11.9/debian/pool/main/c/cassandra/cassandra_3.11.9_all.deb - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42325 - in /release/cassandra: 3.11.9/debian/pool/main/c/cassandra/cassandra_3.11.9.dsc debian/pool/main/c/cassandra/cassandra_3.11.9.dsc
Author: mck Date: Wed Nov 4 11:05:56 2020 New Revision: 42325 Log: Apache Cassandra 3.11.9 debian artifact cassandra_3.11.9.dsc Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_3.11.9.dsc - copied unchanged from r42324, release/cassandra/3.11.9/debian/pool/main/c/cassandra/cassandra_3.11.9.dsc Removed: release/cassandra/3.11.9/debian/pool/main/c/cassandra/cassandra_3.11.9.dsc - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42329 - in /release/cassandra: 3.11.9/debian/dists/311x/ debian/dists/311x/
Author: mck Date: Wed Nov 4 11:06:09 2020 New Revision: 42329 Log: Apache Cassandra 3.11.9 debian artifacts Added: release/cassandra/debian/dists/311x/ - copied from r42328, release/cassandra/3.11.9/debian/dists/311x/ Removed: release/cassandra/3.11.9/debian/dists/311x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42331 - /release/cassandra/3.11.9/debian/pool/
Author: mck Date: Wed Nov 4 11:06:12 2020 New Revision: 42331 Log: Apache Cassandra 3.11.9 debian artifacts Removed: release/cassandra/3.11.9/debian/pool/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42333 - in /release/cassandra: 3.11.9/redhat/ redhat/311x/
Author: mck Date: Wed Nov 4 11:06:16 2020 New Revision: 42333 Log: Apache Cassandra 3.11.9 redhat artifacts Added: release/cassandra/redhat/311x/ - copied from r42332, release/cassandra/3.11.9/redhat/ Removed: release/cassandra/3.11.9/redhat/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42326 - in /release/cassandra: 3.11.9/debian/pool/main/c/cassandra/cassandra_3.11.9.tar.gz debian/pool/main/c/cassandra/cassandra_3.11.9.tar.gz
Author: mck Date: Wed Nov 4 11:06:00 2020 New Revision: 42326 Log: Apache Cassandra 3.11.9 debian artifact cassandra_3.11.9.tar.gz Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_3.11.9.tar.gz - copied unchanged from r42325, release/cassandra/3.11.9/debian/pool/main/c/cassandra/cassandra_3.11.9.tar.gz Removed: release/cassandra/3.11.9/debian/pool/main/c/cassandra/cassandra_3.11.9.tar.gz - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42324 - in /release/cassandra: 3.11.9/debian/pool/main/c/cassandra/cassandra-tools_3.11.9_all.deb debian/pool/main/c/cassandra/cassandra-tools_3.11.9_all.deb
Author: mck Date: Wed Nov 4 11:05:53 2020 New Revision: 42324 Log: Apache Cassandra 3.11.9 debian artifact cassandra-tools_3.11.9_all.deb Added: release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_3.11.9_all.deb - copied unchanged from r42323, release/cassandra/3.11.9/debian/pool/main/c/cassandra/cassandra-tools_3.11.9_all.deb Removed: release/cassandra/3.11.9/debian/pool/main/c/cassandra/cassandra-tools_3.11.9_all.deb - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 3.11.9-tentative deleted (was 5ef75dd)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 3.11.9-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag 3.11.9-tentative was deleted! *** was 5ef75dd Prepare debian changelog for 3.11.9 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42323 - /dev/cassandra/3.11.9/ /release/cassandra/3.11.9/
Author: mck Date: Wed Nov 4 11:00:53 2020 New Revision: 42323 Log: Apache Cassandra 3.11.9 release Added: release/cassandra/3.11.9/ - copied from r42322, dev/cassandra/3.11.9/ Removed: dev/cassandra/3.11.9/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] annotated tag cassandra-3.11.9 created (now 2114612)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to annotated tag cassandra-3.11.9 in repository https://gitbox.apache.org/repos/asf/cassandra.git. at 2114612 (tag) tagging 5ef75dd96cb693e4041e9ecb61a6852276f0eca4 (commit) replaces cassandra-3.11.8 by Mick Semb Wever on Wed Nov 4 12:00:09 2020 +0100 - Log - Apache Cassandra 3.11.9 release --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42317 - /release/cassandra/debian/dists/30x/
Author: mck Date: Wed Nov 4 10:56:11 2020 New Revision: 42317 Log: Apache Cassandra 3.0.23 debian artifacts Removed: release/cassandra/debian/dists/30x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42319 - /release/cassandra/3.0.23/debian/dists/
Author: mck Date: Wed Nov 4 10:56:16 2020 New Revision: 42319 Log: Apache Cassandra 3.0.23 debian artifacts Removed: release/cassandra/3.0.23/debian/dists/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42322 - in /release/cassandra: 3.0.23/redhat/ redhat/30x/
Author: mck Date: Wed Nov 4 10:56:21 2020 New Revision: 42322 Log: Apache Cassandra 3.0.23 redhat artifacts Added: release/cassandra/redhat/30x/ - copied from r42321, release/cassandra/3.0.23/redhat/ Removed: release/cassandra/3.0.23/redhat/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42320 - /release/cassandra/3.0.23/debian/pool/
Author: mck Date: Wed Nov 4 10:56:17 2020 New Revision: 42320 Log: Apache Cassandra 3.0.23 debian artifacts Removed: release/cassandra/3.0.23/debian/pool/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42318 - in /release/cassandra: 3.0.23/debian/dists/30x/ debian/dists/30x/
Author: mck Date: Wed Nov 4 10:56:14 2020 New Revision: 42318 Log: Apache Cassandra 3.0.23 debian artifacts Added: release/cassandra/debian/dists/30x/ - copied from r42317, release/cassandra/3.0.23/debian/dists/30x/ Removed: release/cassandra/3.0.23/debian/dists/30x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42314 - in /release/cassandra: 3.0.23/debian/pool/main/c/cassandra/cassandra_3.0.23.dsc debian/pool/main/c/cassandra/cassandra_3.0.23.dsc
Author: mck Date: Wed Nov 4 10:56:02 2020 New Revision: 42314 Log: Apache Cassandra 3.0.23 debian artifact cassandra_3.0.23.dsc Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.23.dsc - copied unchanged from r42313, release/cassandra/3.0.23/debian/pool/main/c/cassandra/cassandra_3.0.23.dsc Removed: release/cassandra/3.0.23/debian/pool/main/c/cassandra/cassandra_3.0.23.dsc - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42321 - /release/cassandra/redhat/30x/
Author: mck Date: Wed Nov 4 10:56:19 2020 New Revision: 42321 Log: Apache Cassandra 3.0.23 redhat artifacts Removed: release/cassandra/redhat/30x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42316 - in /release/cassandra: 3.0.23/debian/pool/main/c/cassandra/cassandra_3.0.23_all.deb debian/pool/main/c/cassandra/cassandra_3.0.23_all.deb
Author: mck Date: Wed Nov 4 10:56:10 2020 New Revision: 42316 Log: Apache Cassandra 3.0.23 debian artifact cassandra_3.0.23_all.deb Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.23_all.deb - copied unchanged from r42315, release/cassandra/3.0.23/debian/pool/main/c/cassandra/cassandra_3.0.23_all.deb Removed: release/cassandra/3.0.23/debian/pool/main/c/cassandra/cassandra_3.0.23_all.deb - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42315 - in /release/cassandra: 3.0.23/debian/pool/main/c/cassandra/cassandra_3.0.23.tar.gz debian/pool/main/c/cassandra/cassandra_3.0.23.tar.gz
Author: mck Date: Wed Nov 4 10:56:06 2020 New Revision: 42315 Log: Apache Cassandra 3.0.23 debian artifact cassandra_3.0.23.tar.gz Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_3.0.23.tar.gz - copied unchanged from r42314, release/cassandra/3.0.23/debian/pool/main/c/cassandra/cassandra_3.0.23.tar.gz Removed: release/cassandra/3.0.23/debian/pool/main/c/cassandra/cassandra_3.0.23.tar.gz - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42313 - in /release/cassandra: 3.0.23/debian/pool/main/c/cassandra/cassandra-tools_3.0.23_all.deb debian/pool/main/c/cassandra/cassandra-tools_3.0.23_all.deb
Author: mck Date: Wed Nov 4 10:55:57 2020 New Revision: 42313 Log: Apache Cassandra 3.0.23 debian artifact cassandra-tools_3.0.23_all.deb Added: release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_3.0.23_all.deb - copied unchanged from r42312, release/cassandra/3.0.23/debian/pool/main/c/cassandra/cassandra-tools_3.0.23_all.deb Removed: release/cassandra/3.0.23/debian/pool/main/c/cassandra/cassandra-tools_3.0.23_all.deb - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42312 - /dev/cassandra/3.0.23/ /release/cassandra/3.0.23/
Author: mck Date: Wed Nov 4 10:50:25 2020 New Revision: 42312 Log: Apache Cassandra 3.0.23 release Added: release/cassandra/3.0.23/ - copied from r42311, dev/cassandra/3.0.23/ Removed: dev/cassandra/3.0.23/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 3.0.23-tentative deleted (was 31530ff)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 3.0.23-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag 3.0.23-tentative was deleted! *** was 31530ff Prepare debian changelog for 3.0.23 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] annotated tag cassandra-3.0.23 created (now 2425c40)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to annotated tag cassandra-3.0.23 in repository https://gitbox.apache.org/repos/asf/cassandra.git. at 2425c40 (tag) tagging 31530ff5ac6bd3bacd4b378573a2d191bdab8cd7 (commit) replaces cassandra-3.0.22 by Mick Semb Wever on Wed Nov 4 11:49:20 2020 +0100 - Log - Apache Cassandra 3.0.23 release --- No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16011) sstableupgrade unit test hardening
[
https://issues.apache.org/jira/browse/CASSANDRA-16011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16011:
Test and Documentation Plan: See PR for CI results
Status: Patch Available (was: In Progress)
> sstableupgrade unit test hardening
> --
>
> Key: CASSANDRA-16011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16011
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> During CASSANDRA-15883 / CASSANDRA-15991 it was detected unit test coverage
> for this tool is minimal. There is a unit test to enhance upon under
> {{test/unit/org/apache/cassandra/tools}}.
--
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
svn commit: r42308 - /release/cassandra/2.2.19/debian/dists/
Author: mck Date: Wed Nov 4 10:37:36 2020 New Revision: 42308 Log: Apache Cassandra 2.2.19 debian artifacts Removed: release/cassandra/2.2.19/debian/dists/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42303 - in /release/cassandra: 2.2.19/debian/pool/main/c/cassandra/cassandra_2.2.19.dsc debian/pool/main/c/cassandra/cassandra_2.2.19.dsc
Author: mck Date: Wed Nov 4 10:37:18 2020 New Revision: 42303 Log: Apache Cassandra 2.2.19 debian artifact cassandra_2.2.19.dsc Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.19.dsc - copied unchanged from r42302, release/cassandra/2.2.19/debian/pool/main/c/cassandra/cassandra_2.2.19.dsc Removed: release/cassandra/2.2.19/debian/pool/main/c/cassandra/cassandra_2.2.19.dsc - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42309 - /release/cassandra/2.2.19/debian/pool/
Author: mck Date: Wed Nov 4 10:37:39 2020 New Revision: 42309 Log: Apache Cassandra 2.2.19 debian artifacts Removed: release/cassandra/2.2.19/debian/pool/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42304 - in /release/cassandra: 2.2.19/debian/pool/main/c/cassandra/cassandra_2.2.19.tar.gz debian/pool/main/c/cassandra/cassandra_2.2.19.tar.gz
Author: mck Date: Wed Nov 4 10:37:22 2020 New Revision: 42304 Log: Apache Cassandra 2.2.19 debian artifact cassandra_2.2.19.tar.gz Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_2.2.19.tar.gz - copied unchanged from r42303, release/cassandra/2.2.19/debian/pool/main/c/cassandra/cassandra_2.2.19.tar.gz Removed: release/cassandra/2.2.19/debian/pool/main/c/cassandra/cassandra_2.2.19.tar.gz - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r42306 - /release/cassandra/debian/dists/22x/
Author: mck Date: Wed Nov 4 10:37:29 2020 New Revision: 42306 Log: Apache Cassandra 2.2.19 debian artifacts Removed: release/cassandra/debian/dists/22x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
