[jira] [Commented] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648384#comment-17648384 ] Stefan Miklosovic commented on CASSANDRA-18061: --- https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2108/ > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17723) Add support for big endian architecture (s390x)
[ https://issues.apache.org/jira/browse/CASSANDRA-17723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648356#comment-17648356 ] Shahid Shaikh commented on CASSANDRA-17723: --- [~mck] Saw that Cassandra 4.1.0 has been GA'ed on 13 December (y) Could you please take this forward in next Cassandra release? > Add support for big endian architecture (s390x) > --- > > Key: CASSANDRA-17723 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17723 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Legacy/Testing >Reporter: Shahid Shaikh >Assignee: Shahid Shaikh >Priority: Normal > Fix For: 4.x > > Attachments: CASSANDRA-17723-4.0.patch > > > Noticed that some of the Cassandra tests are failing on big endian > architectures (s390x). Please find the attached code patch which corrects the > data handling for big endian architecture. It also corrects the byte ordering > when dealing with sun.misc.Unsafe methods. After the patch following tests > are passing for s390x which were failing earlier: > TTLTest > ScrubTest > LegacySSTableTest > SSTableExportSchemaLoadingTest > SSTableMetadataViewerTest > StandaloneUpgraderOnSStablesTest > StandaloneVerifierOnSSTablesTest > The code change ensures that Cassandra for little endian architectures remain > unaffected. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648353#comment-17648353
]
Berenguer Blasi commented on CASSANDRA-18088:
-
Are you saying you A. are going to make dtests repo 3.11 'friendly' or B. that
we will add new dtests runs for 3.11? I guess you mean B yes?
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17949) Update CCM post CASSANDRA-17379
[ https://issues.apache.org/jira/browse/CASSANDRA-17949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648351#comment-17648351 ] Berenguer Blasi commented on CASSANDRA-17949: - LGTM, just dropped a quick comment +1 for that PR. > Update CCM post CASSANDRA-17379 > --- > > Key: CASSANDRA-17949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17949 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > We updated in CASSANDRA-15234 CCM updateconf to enable it to handle > overloading of parameters Python upgrade tests. > This also allows us not to update for 4.1 the Python DTests but exercise the > backward compatibility we have in C* in our tests. > Now CASSANDRA-17379 added a few flags to opt in or out for overloading of > parameters. > The default points to -Dcassandra.allow_new_old_config_keys=false but this > does not affect our tests as CCM handles the overloading in the yaml. > But this is confusing for users and might lead to issues. > We need to bring on par one way or another ccm with the new flags introduced > in CASSANDRA-17379 > *Until then the recommendation is to use > `-Dcassandra.allow_new_old_config_keys=false` and > `-Dcassandra.allow_duplicate_config_keys=false` to prohibit any kind of > overloading when using CCM master and CCM released to prevent any confusion.* -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 4.x(current trunk)
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648344#comment-17648344 ] Ekaterina Dimitrova commented on CASSANDRA-17992: - And I still see with the latest Netty Version the mentioned classCastException. For example in bulkLoaderSuccessfullyStreamsOverSsl. I will investigate why that happens. In the meantime I was thinking that if we have Chunk implement DirectBuffer that will require add-exports. > Upgrade Netty on 4.x(current trunk) > --- > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17992) Upgrade Netty on 4.x(current trunk)
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648341#comment-17648341 ] Ekaterina Dimitrova commented on CASSANDRA-17992: - Another problem we hit with JDK17 was [this issue|https://github.com/netty/netty/issues/10317] which I resolved as suggested by adding bouncy castle as a dependency for test purposes. (I will send mail to the mailing list, first want to solve all problems here and double check all my findings/solutions). The issue was observed in SSLFactoryTest > Upgrade Netty on 4.x(current trunk) > --- > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revise the changes between the netty > versions. > Upgrading will cover also a fix in netty that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648319#comment-17648319 ] maxwellguo commented on CASSANDRA-18061: Thanks [~brandon.williams] and [~smiklosovic] and I have update the patch agagin [~smiklosovic], would mind rerun this CI to cover dtests? it seems all unit test have passed. > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - 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 (23275537e -> abd88d307)
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 discard 23275537e generate docs for 4d3ddc0d add b072ce0a2 Update Apache-Cassandra-4.1-New-SSTable-Identifiers.adoc new abd88d307 generate docs for b072ce0a 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 (23275537e) \ N -- N -- N refs/heads/asf-staging (abd88d307) 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: ...ache-Cassandra-4.1-New-SSTable-Identifiers.html | 2 +- ...ache-Cassandra-4.1-New-SSTable-Identifiers.adoc | 4 ++-- site-ui/build/ui-bundle.zip| Bin 4970898 -> 4970898 bytes 3 files changed, 3 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18117) Blog article contains outdated parameter
[ https://issues.apache.org/jira/browse/CASSANDRA-18117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18117: --- Resolution: Fixed Status: Resolved (was: Triage Needed) Committed as https://github.com/apache/cassandra-website/commit/b072ce0a2d50a6e4a443f98a80f98c4af953a123 > Blog article contains outdated parameter > > > Key: CASSANDRA-18117 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18117 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Tibor Repasi >Priority: Normal > Labels: pull-request-available > > The parameter as described in the blog article on new SSTable identifier has > been changed since the article. -- This message was sent by Atlassian Jira (v8.20.10#820010) - 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 Apache-Cassandra-4.1-New-SSTable-Identifiers.adoc
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 b072ce0a2 Update Apache-Cassandra-4.1-New-SSTable-Identifiers.adoc b072ce0a2 is described below commit b072ce0a2d50a6e4a443f98a80f98c4af953a123 Author: Tibor Répási AuthorDate: Wed Dec 14 13:05:01 2022 +0100 Update Apache-Cassandra-4.1-New-SSTable-Identifiers.adoc Parameter name was changed with CASSANDRA-17738 patch by Tibor Répási; reviewed by Mick Semb Wever for CASSANDRA-18117 --- .../ROOT/pages/blog/Apache-Cassandra-4.1-New-SSTable-Identifiers.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-New-SSTable-Identifiers.adoc b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-New-SSTable-Identifiers.adoc index ec9a57fea..669243922 100644 --- a/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-New-SSTable-Identifiers.adoc +++ b/site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-4.1-New-SSTable-Identifiers.adoc @@ -132,8 +132,8 @@ From those names, we can see that the first component of all the identifiers is === Migration -The globally unique identifier feature is enabled by switching the `enable_uuid_sstable_identifiers` flag to `true` in cassandra.yaml. It is disabled by default because once a node starts with this feature enabled, each newly stored SSTable will have an identifier created using the new mechanism. As a result, this makes downgrading process more difficult because globally unique identifiers are not readable by Apache Cassandra before 4.1. Consequently, all the SSTable files would have to [...] +The globally unique identifier feature is enabled by switching the `uuid_sstable_identifiers_enabled` flag to `true` in cassandra.yaml. It is disabled by default because once a node starts with this feature enabled, each newly stored SSTable will have an identifier created using the new mechanism. As a result, this makes downgrading process more difficult because globally unique identifiers are not readable by Apache Cassandra before 4.1. Consequently, all the SSTable files would have to [...] Note that setting the flag to `true` does not make Cassandra immediately rename the existing SSTables according to the new scheme. It only affects newly stored SSTables. Existing SSTables are eventually removed during the regular compaction process. -Support for globally unique SSTable identifiers was implemented in https://issues.apache.org/jira/browse/CASSANDRA-17048[CASSANDRA-17048^] and is part of the Apache Cassandra 4.1 release. We expect it will eliminate some problems with manual backups as each SSTable created, for any table, on any node will have a globally unique identifier. \ No newline at end of file +Support for globally unique SSTable identifiers was implemented in https://issues.apache.org/jira/browse/CASSANDRA-17048[CASSANDRA-17048^] and is part of the Apache Cassandra 4.1 release. We expect it will eliminate some problems with manual backups as each SSTable created, for any table, on any node will have a globally unique identifier. - 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&focusedCommentId=17648276#comment-17648276
]
Stefan Miklosovic edited comment on CASSANDRA-14013 at 12/15/22 10:38 PM:
--
_We did not have a test on DescriptorTest#testKeyspaceTableParsing to pick up
the scenario of a legacy "backups" table directory and keyspace, when the table
id suffix is missing so I added it here._
So, we _do_ support that, still, right? In that case, could you add a test in
SSTableLoaderTest as it was, that it is loading it just fine without uuid as
well? Just same thing as it was before.
When it comes to branches, more branches better it is :D I made the peace with
having it in 4.0+, you will have bonus points for anything older. However,
having data being lost on this kind of stuff is rather embarrassing in 2022
(almost 2023!)
was (Author: smiklosovic):
_On this commit, I added the ./* prefix to the regex which made it pick up the
case of a "backups" table in the legacy directory format without the table
uuid. I also updated SSTableLoaderTest to use the new table directory format._
Just to be sure, if you changed that test to support new table format, does
that mean that a user in 4.2 / 5.0 will not be able to import sstables in table
dir called "backups"? That is basically regression when it comes to
CASSANDRA-16235.
But I think I am wrong because here in your you write:
_We did not have a test on DescriptorTest#testKeyspaceTableParsing to pick up
the scenario of a legacy "backups" table directory and keyspace, when the table
id suffix is missing so I added it here._
So, we _do_ support that, still, right? In that case, could you add a test in
SSTableLoaderTest as it was, that it is loading it just fine without uuid as
well? Just same thing as it was before.
When it comes to branches, more branches better it is :D I made the peace with
having it in 4.0+, you will have bonus points for anything older. However,
having data being lost on this kind of stuff is rather embarrassing in 2022
(almost 2023!)
> 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, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> 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.20.10#820010)
-
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&focusedCommentId=17648276#comment-17648276
]
Stefan Miklosovic commented on CASSANDRA-14013:
---
_On this commit, I added the ./* prefix to the regex which made it pick up the
case of a "backups" table in the legacy directory format without the table
uuid. I also updated SSTableLoaderTest to use the new table directory format._
Just to be sure, if you changed that test to support new table format, does
that mean that a user in 4.2 / 5.0 will not be able to import sstables in table
dir called "backups"? That is basically regression when it comes to
CASSANDRA-16235.
But I think I am wrong because here in your you write:
_We did not have a test on DescriptorTest#testKeyspaceTableParsing to pick up
the scenario of a legacy "backups" table directory and keyspace, when the table
id suffix is missing so I added it here._
So, we _do_ support that, still, right? In that case, could you add a test in
SSTableLoaderTest as it was, that it is loading it just fine without uuid as
well? Just same thing as it was before.
When it comes to branches, more branches better it is :D I made the peace with
having it in 4.0+, you will have bonus points for anything older. However,
having data being lost on this kind of stuff is rather embarrassing in 2022
(almost 2023!)
> 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, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> 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.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18061: -- Status: Patch Available (was: Review In Progress) > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648273#comment-17648273 ] Stefan Miklosovic commented on CASSANDRA-18061: --- this failed test is suspicious https://ci-cassandra.apache.org/job/Cassandra-devbranch/2105/testReport/junit/org.apache.cassandra.distributed.upgrade/CompactionHistorySystemTableUpgradeTest/compactionHistorySystemTableTest/ > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18061: -- Fix Version/s: 4.x (was: 4.2) > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18122) when will slf4j be upgraded for CVE-2018-8088
[ https://issues.apache.org/jira/browse/CASSANDRA-18122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648269#comment-17648269 ] Brandon Williams commented on CASSANDRA-18122: -- This doesn't show as a vulnerability under OWASP, since it's not. There are no plans to upgrade for no reason other than upgrading. > when will slf4j be upgraded for CVE-2018-8088 > - > > Key: CASSANDRA-18122 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18122 > Project: Cassandra > Issue Type: Bug >Reporter: Jai Bheemsen Rao Dhanwada >Priority: Normal > > Hello Team, > I see Cassandra 4.1 GA'ed on 12/13/2022 and still uses 1.7.25 version of > slf4j and the vulnerability: [https://nvd.nist.gov/vuln/detail/CVE-2018-8088] > is fixed only in the 1.7.26 version. Do we have any details on when the slf4j > be upgraded ? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18122) when will slf4j be upgraded for CVE-2018-8088
[ https://issues.apache.org/jira/browse/CASSANDRA-18122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648267#comment-17648267 ] Jai Bheemsen Rao Dhanwada commented on CASSANDRA-18122: --- thanks [~brandon.williams] I believe it's because C* is using 1.7.25 version of slf4j the scanner detect the vulnerability: [https://github.com/apache/cassandra/blob/cassandra-4.1.0/build.xml#L534-L536] are there any plans upgrade this version in the next release? > when will slf4j be upgraded for CVE-2018-8088 > - > > Key: CASSANDRA-18122 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18122 > Project: Cassandra > Issue Type: Bug >Reporter: Jai Bheemsen Rao Dhanwada >Priority: Normal > > Hello Team, > I see Cassandra 4.1 GA'ed on 12/13/2022 and still uses 1.7.25 version of > slf4j and the vulnerability: [https://nvd.nist.gov/vuln/detail/CVE-2018-8088] > is fixed only in the 1.7.26 version. Do we have any details on when the slf4j > be upgraded ? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18122) when will slf4j be upgraded for CVE-2018-8088
[ https://issues.apache.org/jira/browse/CASSANDRA-18122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18122: - Resolution: Not A Problem Status: Resolved (was: Triage Needed) We don't use the slf4j-ext module. > when will slf4j be upgraded for CVE-2018-8088 > - > > Key: CASSANDRA-18122 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18122 > Project: Cassandra > Issue Type: Bug >Reporter: Jai Bheemsen Rao Dhanwada >Priority: Normal > > Hello Team, > I see Cassandra 4.1 GA'ed on 12/13/2022 and still uses 1.7.25 version of > slf4j and the vulnerability: [https://nvd.nist.gov/vuln/detail/CVE-2018-8088] > is fixed only in the 1.7.26 version. Do we have any details on when the slf4j > be upgraded ? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18122) when will slf4j be upgraded for CVE-2018-8088
Jai Bheemsen Rao Dhanwada created CASSANDRA-18122: - Summary: when will slf4j be upgraded for CVE-2018-8088 Key: CASSANDRA-18122 URL: https://issues.apache.org/jira/browse/CASSANDRA-18122 Project: Cassandra Issue Type: Bug Reporter: Jai Bheemsen Rao Dhanwada Hello Team, I see Cassandra 4.1 GA'ed on 12/13/2022 and still uses 1.7.25 version of slf4j and the vulnerability: [https://nvd.nist.gov/vuln/detail/CVE-2018-8088] is fixed only in the 1.7.26 version. Do we have any details on when the slf4j be upgraded ? -- This message was sent by Atlassian Jira (v8.20.10#820010) - 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&focusedCommentId=17648253#comment-17648253
]
Paulo Motta commented on CASSANDRA-14013:
-
The reason why {{SSTableLoaderTest#testLoadingBackupsTable}} was failing was
because this test was using the legacy table directory format which does not
have {{{}-{uuid{ part and the regex was failing to pick up this case.
On [this
commit|https://github.com/pauloricardomg/cassandra/commit/59f42ce2e58f7846355ebb9f3395fceb28c76631],
I added the {{./*}} prefix to the regex which made it pick up the case of a
"backups" table in the legacy directory format without the table uuid. I also
updated {{SSTableLoaderTest}} to use the new [table directory
format|https://github.com/pauloricardomg/cassandra/commit/59f42ce2e58f7846355ebb9f3395fceb28c76631#diff-7caf9acb4092d0f8da99e009b74cab5832ee797d5c9b191ab2e3b394a533812fR333].
We did not have a test on {{DescriptorTest#testKeyspaceTableParsing}} to pick
up the scenario of a legacy "backups" table directory and keyspace, when the
table id suffix is missing so I added it
[here|https://github.com/pauloricardomg/cassandra/commit/59f42ce2e58f7846355ebb9f3395fceb28c76631#diff-f1003299495ea8593e83c86e261e77d7d6d7a57a52c61f52e51e7e816fcdad5eR223].
However, neither the solutions are able to correctly parse a snapshot in a
legacy "backups" table, for example
{noformat}
/path/to/cassandra/data/dir2/dir5/dir6/backups/backups/snapshots/snapshots/na-1-big-Index.db
{noformat}
Both approaches consider this an sstable on the "snapshots" table of the
"snapshots" directory, and not a snapshot on the "backups" table of the
"backups" keyspace. However I don't think we need to fix for this case as we
should no longer support directories in the legacy format moving forward.
I have submitted a CI run for the latest branch
[here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2106/].
[~smiklosovic] if tests look good and you're ok I can prepare patch for earlier
versions with the simpler fix, and the regex fix on trunk. Should we do just
4.x or 3.X too?
> 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, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> 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.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18061: -- Reviewers: Stefan Miklosovic Status: Review In Progress (was: Patch Available) > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18061: -- Test and Documentation Plan: tests passing Status: Patch Available (was: In Progress) > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648202#comment-17648202 ] Brandon Williams edited comment on CASSANDRA-18061 at 12/15/22 6:41 PM: I don't have time to commit to a full review right now but I started a CI run that can cover dtests: [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2105/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2105/pipeline] and if you mark this patch available it will signal to committers it is ready to be looked at. was (Author: brandon.williams): I don't have time to commit to a full review right now but I started a CI run that can cover dtests: [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2105/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2105/pipeline] > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18061: - Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - 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 (3680edf51 -> 23275537e)
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 3680edf51 generate docs for 4d3ddc0d new 23275537e generate docs for 4d3ddc0d 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 (3680edf51) \ N -- N -- N refs/heads/asf-staging (23275537e) 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/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4970898 -> 4970898 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648202#comment-17648202 ] Brandon Williams commented on CASSANDRA-18061: -- I don't have time to commit to a full review right now but I started a CI run that can cover dtests: [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2105/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2105/pipeline] > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18121: - Change Category: Operability Complexity: Normal Component/s: Test/dtest/python Status: Open (was: Triage Needed) > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtest also need to support 3.11 so > the cqlsh dtests can be run. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648191#comment-17648191
]
Brandon Williams commented on CASSANDRA-18088:
--
There is too much functionality being tested in the dtests' cqlsh_tests to
easily divorce them and cqlsh from the same python version support. I've
created CASSANDRA-18121 for the dtests and will go back to looking into them.
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648191#comment-17648191
]
Brandon Williams edited comment on CASSANDRA-18088 at 12/15/22 6:14 PM:
There is too much functionality being tested in the dtests' cqlsh_tests to
easily divorce them and cqlsh from the same python versions supported. I've
created CASSANDRA-18121 for the dtests and will go back to looking into them.
was (Author: brandon.williams):
There is too much functionality being tested in the dtests' cqlsh_tests to
easily divorce them and cqlsh from the same python version support. I've
created CASSANDRA-18121 for the dtests and will go back to looking into them.
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18121) Dtests need python 3.11 support
Brandon Williams created CASSANDRA-18121: Summary: Dtests need python 3.11 support Key: CASSANDRA-18121 URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Assignee: Brandon Williams In order to have cqlsh support 3.11 the dtest also need to support 3.11 so the cqlsh dtests can be run. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648181#comment-17648181
]
Brandon Williams edited comment on CASSANDRA-18088 at 12/15/22 5:53 PM:
In the image with dependencies I didn't update the source, so it was still
built from the apache repo. I've corrected that and uploaded the new image.
There's another problem, though. Circle runs 'cqlsh_dtests' with the dtest
runner and the [regex flag with
'cql'|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L2160]
passed to it, which effectively means that cqlsh and the dtest repo must move
in lockstep with regard to the python version. If 3.11 support is added to
cqlsh, because of this, it has to be added to the dtests as well.
I looked into updating the dtests and that is going to be significant work
worthy of its own ticket (to begin with, pytest has to be updated.) I think we
should not block having cqlsh work based upon what will work with the dtests,
and instead make circle work more like Jenkins does to run the cqlsh tests.
was (Author: brandon.williams):
In the image with dependencies I didn't update the source, so it was still
built from the apache repo. I've corrected that and uploaded the new image.
There's another problem, though. Circle runs 'cqlsh_dtests' with the dtest
runner and the [regex flag with
'cql'|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L2160]
passed to it, which effectively means that cqlsh and the dtest repo must move
in lockstep with regard to the python version. If 3.11 support is added to
cqlsh, because of this, it has to be added to the dtests as well.
I looked into updating the dtests and that is going to be significant work
worth of its own ticket (to begin with, pytest has to be updated.) I think we
should not block having cqlsh work based upon what will work with the dtests,
and instead make circle work more like Jenkins does to run the cqlsh tests.
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648181#comment-17648181
]
Brandon Williams commented on CASSANDRA-18088:
--
In the image with dependencies I didn't update the source, so it was still
built from the apache repo. I've corrected that and uploaded the new image.
There's another problem, though. Circle runs 'cqlsh_dtests' with the dtest
runner and the [regex flag with
'cql'|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L2160]
passed to it, which effectively means that cqlsh and the dtest repo must move
in lockstep with regard to the python version. If 3.11 support is added to
cqlsh, because of this, it has to be added to the dtests as well.
I looked into updating the dtests and that is going to be significant work
worth of its own ticket (to begin with, pytest has to be updated.) I think we
should not block having cqlsh work based upon what will work with the dtests,
and instead make circle work more like Jenkins does to run the cqlsh tests.
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.11.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
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&focusedCommentId=17648152#comment-17648152
]
Paulo Motta commented on CASSANDRA-14013:
-
bq. If you scroll up enough, there is my original PR which was also trying to
base the solution to this problem on regexp (1) but then we kind of abandoned
that in favor of more concise and "less invasive" patch.
Sorry, I missed that.
bq. If yes, why do you want to have simpler in 4.0 and 4.1 and this new stuff
in trunk only? Is not it better to just have one approach committed everywhere?
The simpler fix is less invasive so less riskier for released versions, we
probably will no longer touch this code. The regex fix changes the way
directories are parsed but is more robust and future-proof so we would adopt
that moving forward in trunk, at least until we have the proper fix of encoding
keyspace/table/index info in the sstable metadata.
bq. Also, SSTableLoaderTest#testLoadingBackupsTable is failing for me locally
while testLoadingSnapshotsTable is not. Maybe your patch is not covering
something?
I haven't checked tests other than \{{DescriptorTest}}, I'll take a look and
submit a full CI run.
> 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, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> 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.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17977) CME in STCS/DTCS/TWCS.getSSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-17977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17977: -- Reviewers: Aleksey Yeschenko, Aleksey Yeschenko (was: Jon Meredith) Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko) Status: Review In Progress (was: Patch Available) +1 > CME in STCS/DTCS/TWCS.getSSTables > - > > Key: CASSANDRA-17977 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17977 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > This method should be synchronized to avoid ConcurrentModificationException -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17977) CME in STCS/DTCS/TWCS.getSSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-17977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17977: -- Status: Ready to Commit (was: Review In Progress) > CME in STCS/DTCS/TWCS.getSSTables > - > > Key: CASSANDRA-17977 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17977 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.1.x, 4.x > > > This method should be synchronized to avoid ConcurrentModificationException -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17949) Update CCM post CASSANDRA-17379
[ https://issues.apache.org/jira/browse/CASSANDRA-17949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648129#comment-17648129 ] Ekaterina Dimitrova commented on CASSANDRA-17949: - CC [~b.le...@gmail.com] > Update CCM post CASSANDRA-17379 > --- > > Key: CASSANDRA-17949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17949 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > We updated in CASSANDRA-15234 CCM updateconf to enable it to handle > overloading of parameters Python upgrade tests. > This also allows us not to update for 4.1 the Python DTests but exercise the > backward compatibility we have in C* in our tests. > Now CASSANDRA-17379 added a few flags to opt in or out for overloading of > parameters. > The default points to -Dcassandra.allow_new_old_config_keys=false but this > does not affect our tests as CCM handles the overloading in the yaml. > But this is confusing for users and might lead to issues. > We need to bring on par one way or another ccm with the new flags introduced > in CASSANDRA-17379 > *Until then the recommendation is to use > `-Dcassandra.allow_new_old_config_keys=false` and > `-Dcassandra.allow_duplicate_config_keys=false` to prohibit any kind of > overloading when using CCM master and CCM released to prevent any confusion.* -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17949) Update CCM post CASSANDRA-17379
[ https://issues.apache.org/jira/browse/CASSANDRA-17949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648127#comment-17648127 ] Ekaterina Dimitrova commented on CASSANDRA-17949: - There are several discussions around CCM and until a decision is taken I opened a [PR|https://github.com/riptano/ccm/pull/748] to add a warning for users to the CCM README. > Update CCM post CASSANDRA-17379 > --- > > Key: CASSANDRA-17949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17949 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > We updated in CASSANDRA-15234 CCM updateconf to enable it to handle > overloading of parameters Python upgrade tests. > This also allows us not to update for 4.1 the Python DTests but exercise the > backward compatibility we have in C* in our tests. > Now CASSANDRA-17379 added a few flags to opt in or out for overloading of > parameters. > The default points to -Dcassandra.allow_new_old_config_keys=false but this > does not affect our tests as CCM handles the overloading in the yaml. > But this is confusing for users and might lead to issues. > We need to bring on par one way or another ccm with the new flags introduced > in CASSANDRA-17379 > *Until then the recommendation is to use > `-Dcassandra.allow_new_old_config_keys=false` and > `-Dcassandra.allow_duplicate_config_keys=false` to prohibit any kind of > overloading when using CCM master and CCM released to prevent any confusion.* -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17949) Update CCM post CASSANDRA-17379
[ https://issues.apache.org/jira/browse/CASSANDRA-17949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17949: Description: We updated in CASSANDRA-15234 CCM updateconf to enable it to handle overloading of parameters Python upgrade tests. This also allows us not to update for 4.1 the Python DTests but exercise the backward compatibility we have in C* in our tests. Now CASSANDRA-17379 added a few flags to opt in or out for overloading of parameters. The default points to -Dcassandra.allow_new_old_config_keys=false but this does not affect our tests as CCM handles the overloading in the yaml. But this is confusing for users and might lead to issues. We need to bring on par one way or another ccm with the new flags introduced in CASSANDRA-17379 *Until then the recommendation is to use `-Dcassandra.allow_new_old_config_keys=false` and `-Dcassandra.allow_duplicate_config_keys=false` to prohibit any kind of overloading when using CCM master and CCM released to prevent any confusion.* was: We updated in CASSANDRA-15234 CCM to enable it to handle overloading of parameters the way that SnakeYAML works. As we have matching and backward compatibility between old and new keys in 4.1 (look into this write up for more information [https://cassandra.apache.org/doc/4.1/cassandra/configuration/configuration.html).] This also allows us not to update for 4.1 the Python DTests but exercise the backward compatibility we have in C* in our tests. Now CASSANDRA-17379 added a few flags to opt in or out for overloading of parameters. The default points to -Dcassandra.allow_new_old_config_keys=false but this does not affect our tests as CCM handles the overloading in the yaml. But this is confusing for users and might lead to issues. We need to bring on par one way or another ccm with the new flags introduced in CASSANDRA-17379 > Update CCM post CASSANDRA-17379 > --- > > Key: CASSANDRA-17949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17949 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > We updated in CASSANDRA-15234 CCM updateconf to enable it to handle > overloading of parameters Python upgrade tests. > This also allows us not to update for 4.1 the Python DTests but exercise the > backward compatibility we have in C* in our tests. > Now CASSANDRA-17379 added a few flags to opt in or out for overloading of > parameters. > The default points to -Dcassandra.allow_new_old_config_keys=false but this > does not affect our tests as CCM handles the overloading in the yaml. > But this is confusing for users and might lead to issues. > We need to bring on par one way or another ccm with the new flags introduced > in CASSANDRA-17379 > *Until then the recommendation is to use > `-Dcassandra.allow_new_old_config_keys=false` and > `-Dcassandra.allow_duplicate_config_keys=false` to prohibit any kind of > overloading when using CCM master and CCM released to prevent any confusion.* -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18120) Single slow node dramatically reduces cluster write throughput regardless of CL
Dan Sarisky created CASSANDRA-18120: --- Summary: Single slow node dramatically reduces cluster write throughput regardless of CL Key: CASSANDRA-18120 URL: https://issues.apache.org/jira/browse/CASSANDRA-18120 Project: Cassandra Issue Type: Improvement Reporter: Dan Sarisky We issue writes to Cassandra as logged batches(RF=3, Consistency levels=TWO, QUORUM, or LOCAL_QUORUM) On clusters of any size - a single extremely slow node causes a ~90% loss of cluster-wide throughput using batched writes. We can replicate this in the lab via CPU or disk throttling. I observe this in 3.11, 4.0, and 4.1. It appears the mechanism in play is: Those logged batches are immediately written to two replica nodes and the actual mutations aren't processed until those two nodes acknowledge the batch statements. Those replica nodes are selected randomly from all nodes in the local data center currently up in gossip. If a single node is slow, but still thought to be up in gossip, this eventually causes every other node to have all of its MutationStages to be waiting while the slow replica accepts batch writes. The code in play appears to be: See [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/ReplicaPlans.java#L245]. In the method filterBatchlogEndpoints() there is a Collections.shuffle() to order the endpoints and a FailureDetector.isEndpointAlive() to test if the endpoint is acceptable. This behavior causes Cassandra to move from a multi-node fault tolerant system toa collection of single points of failure. We try to take administrator actions to kill off the extremely slow nodes, but it would be great to have some notion of "what node is a bad choice" when writing log batches to replica nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17874) Only reload compaction strategies if disk boundaries change
[ https://issues.apache.org/jira/browse/CASSANDRA-17874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17874: Fix Version/s: 4.2 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/94bcb4e5ec4fb99b73276d90b9d08def6f3b4d30 Resolution: Fixed Status: Resolved (was: Ready to Commit) And committed, thanks test run; https://app.circleci.com/pipelines/github/krummas/cassandra/847/workflows/ac3511aa-9c61-4c2f-b7cb-c1853c7014a7 > Only reload compaction strategies if disk boundaries change > --- > > Key: CASSANDRA-17874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17874 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > Fix For: 4.2 > > > We currently reload compaction strategies every time ringVersion changes - we > should change this to only reload if the ring version change actually changes > the disk boundaries. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Only reload compaction strategies if disk boundaries change
This is an automated email from the ASF dual-hosted git repository.
marcuse pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 94bcb4e5ec Only reload compaction strategies if disk boundaries change
94bcb4e5ec is described below
commit 94bcb4e5ec4fb99b73276d90b9d08def6f3b4d30
Author: Marcus Eriksson
AuthorDate: Thu Sep 1 09:43:47 2022 +0200
Only reload compaction strategies if disk boundaries change
Patch by Aleksey Yeschenko and marcuse; reviewed by Aleksey Yeschenko for
CASSANDRA-17874
Co-authored-by: Aleksey Yeschenko
---
CHANGES.txt| 1 +
.../org/apache/cassandra/db/ColumnFamilyStore.java | 4 +-
.../org/apache/cassandra/db/DiskBoundaries.java| 8 ++
.../db/compaction/CompactionStrategyManager.java | 153 +
...ompactionStrategyManagerBoundaryReloadTest.java | 103 ++
5 files changed, 213 insertions(+), 56 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 04ff21265a..160ecef46b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * Only reload compaction strategies if disk boundaries change
(CASSANDRA-17874)
* CEP-10: Simulator Java11 Support (CASSANDRA-17178)
* Set the major compaction type correctly for compactionstats
(CASSANDRA-18055)
* Print exception message without stacktrace when nodetool commands fail on
probe.getOwnershipWithPort() (CASSANDRA-18079)
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index cb164a030f..b00a77ab40 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -385,7 +385,7 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean, Memtable.Owner
for (ColumnFamilyStore cfs : concatWithIndexes())
cfs.crcCheckChance = new
DefaultValue(metadata().params.crcCheckChance);
-compactionStrategyManager.maybeReload(metadata());
+
compactionStrategyManager.maybeReloadParamsFromSchema(metadata().params.compaction);
indexManager.reload();
@@ -418,7 +418,7 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean, Memtable.Owner
{
CompactionParams compactionParams =
CompactionParams.fromMap(options);
compactionParams.validate();
-
compactionStrategyManager.setNewLocalCompactionStrategy(compactionParams);
+compactionStrategyManager.overrideLocalParams(compactionParams);
}
catch (Throwable t)
{
diff --git a/src/java/org/apache/cassandra/db/DiskBoundaries.java
b/src/java/org/apache/cassandra/db/DiskBoundaries.java
index c340d2703d..32edcac433 100644
--- a/src/java/org/apache/cassandra/db/DiskBoundaries.java
+++ b/src/java/org/apache/cassandra/db/DiskBoundaries.java
@@ -20,6 +20,7 @@ package org.apache.cassandra.db;
import java.util.Collections;
import java.util.List;
+import java.util.Objects;
import com.google.common.annotations.VisibleForTesting;
import com.google.common.collect.ImmutableList;
@@ -163,4 +164,11 @@ public class DiskBoundaries
int lastIndex = getDiskIndex(last);
return directories.subList(firstIndex, lastIndex + 1);
}
+
+public boolean isEquivalentTo(DiskBoundaries oldBoundaries)
+{
+return oldBoundaries != null &&
+ Objects.equals(positions, oldBoundaries.positions) &&
+ Objects.equals(directories, oldBoundaries.directories);
+}
}
diff --git
a/src/java/org/apache/cassandra/db/compaction/CompactionStrategyManager.java
b/src/java/org/apache/cassandra/db/compaction/CompactionStrategyManager.java
index e98e4dd10f..bc0fc0dc81 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionStrategyManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionStrategyManager.java
@@ -42,7 +42,6 @@ import com.google.common.collect.ImmutableList;
import com.google.common.collect.Iterables;
import com.google.common.collect.Lists;
import com.google.common.primitives.Longs;
-import org.apache.cassandra.io.util.File;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@@ -67,6 +66,7 @@ import org.apache.cassandra.io.sstable.SSTableMultiWriter;
import org.apache.cassandra.io.sstable.format.SSTableReader;
import org.apache.cassandra.io.sstable.metadata.MetadataCollector;
import org.apache.cassandra.io.sstable.metadata.StatsMetadata;
+import org.apache.cassandra.io.util.File;
import org.apache.cassandra.notifications.INotification;
import org.apache.cassandra.notifications.INotificationConsumer;
import org.apache.cassandra.notifications.SSTableAddedNotification;
@@ -76,7 +76,6 @@ import
org.apache.cassandra.notifications.SSTableMetadataChanged;
import org.apache.cassandra.notifications.SS
[jira] [Updated] (CASSANDRA-18119) Handle sstable metadata stats file getting a new mtime after compaction has finished
[
https://issues.apache.org/jira/browse/CASSANDRA-18119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-18119:
Fix Version/s: 4.x
> Handle sstable metadata stats file getting a new mtime after compaction has
> finished
>
>
> Key: CASSANDRA-18119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18119
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/Startup and Shutdown
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Due to a race between compaction finishing and compaction strategies getting
> reloaded there is a chance that we try to add both the new sstable and the
> old compacted sstable to the compaction strategy, and in the LCS case this
> can cause the old sstable to get sent to L0 to avoid overlap. This changes
> the mtime of the stats metadata file and if the node is shut down before the
> sstable is actually deleted from disk, we fail starting with the following
> exception:
> {code}
> .../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
> REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
> ***Unexpected files detected for sstable [nb-0-big-]: last update
> time [Thu Dec 15 10:24:09 CET 2022] (1671096249000) should have been [Thu Dec
> 15 10:24:07 CET 2022] (1671096247000)
> ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
> {code}
> A workaround for this (until we properly fix the way compaction strategies
> get notified about sstable changes) is to ignore the timestamp of the STATS
> component when cleaning up compaction leftovers on startup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18118) Do not leak 2015 memtable synthetic Epoch
[
https://issues.apache.org/jira/browse/CASSANDRA-18118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18118:
Fix Version/s: 3.11.x
4.0.x
> Do not leak 2015 memtable synthetic Epoch
> -
>
> Key: CASSANDRA-18118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18118
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> This
> [Epoch|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> can
> [leak|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/Memtable.java#L392]
> affecting all the timestamps logic. It has been observed in a production
> env it can i.e. prevent proper sstable and tombstone cleanup.
> To reproduce create the following table:
> {noformat}
> drop keyspace test;
> create keyspace test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> id text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '2', 'tombstone_compaction_interval':
> '3000', 'tombstone_threshold': '0.1', 'unchecked_tombstone_compaction':
> 'true'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 10
> AND gc_grace_seconds = 10
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> CREATE INDEX id_idx ON test.test (id);
> {noformat}
> And stress load it with:
> {noformat}
> insert into test.test (key,id) values('$RANDOM_UUID $RANDOM_UUID',
> 'eaca36a1-45f1-469c-a3f6-3ba54220363f') USING TTL 10
> {noformat}
> Notice how all inserts have a 10s TTL, the default 10s TTL and gc_grace is
> also at 10s. This is to speed up the repro:
> - Run the load for a couple minutes and track sstables disk usage. You will
> see it does only increase, nothing gets cleaned up and it doesn't stop
> growing (notice all this is well past the 10s gc_grace and TTL)
> - Running a flush and a compaction while under load against the keyspace,
> table or index doesn't solve the issue.
> - Stopping the load and running a compaction doesn't solve the issue.
> Flushing does though.
> - On the original observation where TTL was around 600s and gc_grace around
> 1800s we could get GBs of sstables that weren't cleaned up or compacted away
> after hours of work.
> - Reproduction can also happen on plain sstables by repeatedly
> inserting/deleting/overwriting the same values over and over again without 2i
> indices or TTL being involved.
> The problem seems to be
> [EncodingStats|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> using a synthetic Epoch in 2015 which plays nice with Vint serialization.
> Unfortunately {{Memtable}} is using that to keep track of the
> {{minTimestamp}} which can leak the 2015 Epoch. This confuses any logic
> consuming that timestamp. In this particular case purge and fully expired
> sstables weren't properly detected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18118) Do not leak 2015 memtable synthetic Epoch
[
https://issues.apache.org/jira/browse/CASSANDRA-18118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18118:
Test and Documentation Plan: See PR
Status: Patch Available (was: Open)
> Do not leak 2015 memtable synthetic Epoch
> -
>
> Key: CASSANDRA-18118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18118
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
>
> This
> [Epoch|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> can
> [leak|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/Memtable.java#L392]
> affecting all the timestamps logic. It has been observed in a production
> env it can i.e. prevent proper sstable and tombstone cleanup.
> To reproduce create the following table:
> {noformat}
> drop keyspace test;
> create keyspace test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> id text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '2', 'tombstone_compaction_interval':
> '3000', 'tombstone_threshold': '0.1', 'unchecked_tombstone_compaction':
> 'true'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.0
> AND default_time_to_live = 10
> AND gc_grace_seconds = 10
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> CREATE INDEX id_idx ON test.test (id);
> {noformat}
> And stress load it with:
> {noformat}
> insert into test.test (key,id) values('$RANDOM_UUID $RANDOM_UUID',
> 'eaca36a1-45f1-469c-a3f6-3ba54220363f') USING TTL 10
> {noformat}
> Notice how all inserts have a 10s TTL, the default 10s TTL and gc_grace is
> also at 10s. This is to speed up the repro:
> - Run the load for a couple minutes and track sstables disk usage. You will
> see it does only increase, nothing gets cleaned up and it doesn't stop
> growing (notice all this is well past the 10s gc_grace and TTL)
> - Running a flush and a compaction while under load against the keyspace,
> table or index doesn't solve the issue.
> - Stopping the load and running a compaction doesn't solve the issue.
> Flushing does though.
> - On the original observation where TTL was around 600s and gc_grace around
> 1800s we could get GBs of sstables that weren't cleaned up or compacted away
> after hours of work.
> - Reproduction can also happen on plain sstables by repeatedly
> inserting/deleting/overwriting the same values over and over again without 2i
> indices or TTL being involved.
> The problem seems to be
> [EncodingStats|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> using a synthetic Epoch in 2015 which plays nice with Vint serialization.
> Unfortunately {{Memtable}} is using that to keep track of the
> {{minTimestamp}} which can leak the 2015 Epoch. This confuses any logic
> consuming that timestamp. In this particular case purge and fully expired
> sstables weren't properly detected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
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&focusedCommentId=17647978#comment-17647978
]
Stefan Miklosovic commented on CASSANDRA-14013:
---
That is all fine for me, [~paulo] . If you scroll up enough, there is my
original PR which was also trying to base the solution to this problem on
regexp (1) but then we kind of abandoned that in favor of more concise and
"less invasive" patch. What I see is that you managed to still do regexp but it
looks way shorter which I am glad for.
What do you consider to be the simpler fix? The one I put together without your
stuff on top? If yes, why do you want to have simpler in 4.0 and 4.1 and this
new stuff in trunk only? Is not it better to just have one approach committed
everywhere?
Also, SSTableLoaderTest#testLoadingBackupsTable is failing for me locally
while testLoadingSnapshotsTable is not. Maybe your patch is not covering
something?
(1) https://github.com/apache/cassandra/pull/798/files
> 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, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> 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.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18119) Handle sstable metadata stats file getting a new mtime after compaction has finished
[
https://issues.apache.org/jira/browse/CASSANDRA-18119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-18119:
Authors: Josh McKenzie (was: Marcus Eriksson)
> Handle sstable metadata stats file getting a new mtime after compaction has
> finished
>
>
> Key: CASSANDRA-18119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18119
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/Startup and Shutdown
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Due to a race between compaction finishing and compaction strategies getting
> reloaded there is a chance that we try to add both the new sstable and the
> old compacted sstable to the compaction strategy, and in the LCS case this
> can cause the old sstable to get sent to L0 to avoid overlap. This changes
> the mtime of the stats metadata file and if the node is shut down before the
> sstable is actually deleted from disk, we fail starting with the following
> exception:
> {code}
> .../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
> REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
> ***Unexpected files detected for sstable [nb-0-big-]: last update
> time [Thu Dec 15 10:24:09 CET 2022] (1671096249000) should have been [Thu Dec
> 15 10:24:07 CET 2022] (1671096247000)
> ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
> {code}
> A workaround for this (until we properly fix the way compaction strategies
> get notified about sstable changes) is to ignore the timestamp of the STATS
> component when cleaning up compaction leftovers on startup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18119) Handle sstable metadata stats file getting a new mtime after compaction has finished
[
https://issues.apache.org/jira/browse/CASSANDRA-18119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-18119:
Test and Documentation Plan: cci run, new unit tests
Status: Patch Available (was: Open)
3.11:
https://github.com/apache/cassandra/pull/2052
https://app.circleci.com/pipelines/github/krummas/cassandra/844/workflows/f50c031c-61ff-466c-898b-dac02165879a
4.0:
https://github.com/apache/cassandra/pull/2054
https://app.circleci.com/pipelines/github/krummas/cassandra/845/workflows/e6b198b3-d091-4e55-a937-983345bf2901
4.1:
https://github.com/apache/cassandra/pull/2053
https://app.circleci.com/pipelines/github/krummas/cassandra/846/workflows/f9ff701a-22f6-463b-b356-c37a61d24a75
trunk:
https://github.com/apache/cassandra/pull/2055
https://app.circleci.com/pipelines/github/krummas/cassandra/843/workflows/e1001039-060b-47d6-bd6d-2ee4747b343f
seems we have some flakiness here, will check
> Handle sstable metadata stats file getting a new mtime after compaction has
> finished
>
>
> Key: CASSANDRA-18119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18119
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/Startup and Shutdown
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Due to a race between compaction finishing and compaction strategies getting
> reloaded there is a chance that we try to add both the new sstable and the
> old compacted sstable to the compaction strategy, and in the LCS case this
> can cause the old sstable to get sent to L0 to avoid overlap. This changes
> the mtime of the stats metadata file and if the node is shut down before the
> sstable is actually deleted from disk, we fail starting with the following
> exception:
> {code}
> .../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
> REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
> ***Unexpected files detected for sstable [nb-0-big-]: last update
> time [Thu Dec 15 10:24:09 CET 2022] (1671096249000) should have been [Thu Dec
> 15 10:24:07 CET 2022] (1671096247000)
> ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
> {code}
> A workaround for this (until we properly fix the way compaction strategies
> get notified about sstable changes) is to ignore the timestamp of the STATS
> component when cleaning up compaction leftovers on startup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18119) Handle sstable metadata stats file getting a new mtime after compaction has finished
[
https://issues.apache.org/jira/browse/CASSANDRA-18119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-18119:
Description:
Due to a race between compaction finishing and compaction strategies getting
reloaded there is a chance that we try to add both the new sstable and the old
compacted sstable to the compaction strategy, and in the LCS case this can
cause the old sstable to get sent to L0 to avoid overlap. This changes the
mtime of the stats metadata file and if the node is shut down before the
sstable is actually deleted from disk, we fail starting with the following
exception:
{code}
.../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
***Unexpected files detected for sstable [nb-0-big-]: last update time
[Thu Dec 15 10:24:09 CET 2022] (1671096249000) should have been [Thu Dec 15
10:24:07 CET 2022] (1671096247000)
ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
{code}
A workaround for this (until we properly fix the way compaction strategies get
notified about sstable changes) is to ignore the timestamp of the STATS
component when cleaning up compaction leftovers on startup.
was:
Due to a race between compaction finishing and compaction strategies getting
reloaded there is a chance that we try to add both the new sstable and the old
compacted sstable to the compaction strategy, and in the LCS case this can
cause the old sstable to get sent to L0 to avoid overlap. This changes the
mtime of the stats metadata file and if the node is shut down before the
sstable is actually deleted from disk, we fail starting with the following
exception:
{code}
.../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
[junit-timeout]
REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
[junit-timeout] ***Unexpected files detected for sstable
[nb-0-big-]: last update time [Thu Dec 15 10:24:09 CET 2022] (1671096249000)
should have been [Thu Dec 15 10:24:07 CET 2022] (1671096247000)
[junit-timeout]
ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
{code}
A workaround for this (until we properly fix the way compaction strategies get
notified about sstable changes) is to ignore the timestamp of the STATS
component when cleaning up compaction leftovers on startup.
> Handle sstable metadata stats file getting a new mtime after compaction has
> finished
>
>
> Key: CASSANDRA-18119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18119
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/Startup and Shutdown
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x
>
>
> Due to a race between compaction finishing and compaction strategies getting
> reloaded there is a chance that we try to add both the new sstable and the
> old compacted sstable to the compaction strategy, and in the LCS case this
> can cause the old sstable to get sent to L0 to avoid overlap. This changes
> the mtime of the stats metadata file and if the node is shut down before the
> sstable is actually deleted from disk, we fail starting with the following
> exception:
> {code}
> .../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
> REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
> ***Unexpected files detected for sstable [nb-0-big-]: last update
> time [Thu Dec 15 10:24:09 CET 2022] (1671096249000) should have been [Thu Dec
> 15 10:24:07 CET 2022] (1671096247000)
> ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
> {code}
> A workaround for this (until we properly fix the way compaction strategies
> get notified about sstable changes) is to ignore the timestamp of the STATS
> component when cleaning up compaction leftovers on startup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18119) Handle sstable metadata stats file getting a new mtime after compaction has finished
[
https://issues.apache.org/jira/browse/CASSANDRA-18119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-18119:
Bug Category: Parent values: Degradation(12984)Level 1 values: Other
Exception(12998)
Complexity: Normal
Component/s: Local/Compaction
Local/Startup and Shutdown
Discovered By: Adhoc Test
Fix Version/s: 3.11.x
4.0.x
4.1.x
Reviewers: Jon Meredith, Josh McKenzie
Severity: Normal
Assignee: Marcus Eriksson
Status: Open (was: Triage Needed)
> Handle sstable metadata stats file getting a new mtime after compaction has
> finished
>
>
> Key: CASSANDRA-18119
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18119
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/Startup and Shutdown
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.1.x
>
>
> Due to a race between compaction finishing and compaction strategies getting
> reloaded there is a chance that we try to add both the new sstable and the
> old compacted sstable to the compaction strategy, and in the LCS case this
> can cause the old sstable to get sent to L0 to avoid overlap. This changes
> the mtime of the stats metadata file and if the node is shut down before the
> sstable is actually deleted from disk, we fail starting with the following
> exception:
> {code}
> .../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
> [junit-timeout]
> REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
> [junit-timeout] ***Unexpected files detected for sstable
> [nb-0-big-]: last update time [Thu Dec 15 10:24:09 CET 2022] (1671096249000)
> should have been [Thu Dec 15 10:24:07 CET 2022] (1671096247000)
> [junit-timeout]
> ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
> {code}
> A workaround for this (until we properly fix the way compaction strategies
> get notified about sstable changes) is to ignore the timestamp of the STATS
> component when cleaning up compaction leftovers on startup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18119) Handle sstable metadata stats file getting a new mtime after compaction has finished
Marcus Eriksson created CASSANDRA-18119:
---
Summary: Handle sstable metadata stats file getting a new mtime
after compaction has finished
Key: CASSANDRA-18119
URL: https://issues.apache.org/jira/browse/CASSANDRA-18119
Project: Cassandra
Issue Type: Bug
Reporter: Marcus Eriksson
Due to a race between compaction finishing and compaction strategies getting
reloaded there is a chance that we try to add both the new sstable and the old
compacted sstable to the compaction strategy, and in the LCS case this can
cause the old sstable to get sent to L0 to avoid overlap. This changes the
mtime of the stats metadata file and if the node is shut down before the
sstable is actually deleted from disk, we fail starting with the following
exception:
{code}
.../mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb_txn_compaction_3983c030-7c5a-11ed-8c66-2f5760cb10b3.log
[junit-timeout]
REMOVE:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-0-big-,1671096247000,5][4003386800]
[junit-timeout] ***Unexpected files detected for sstable
[nb-0-big-]: last update time [Thu Dec 15 10:24:09 CET 2022] (1671096249000)
should have been [Thu Dec 15 10:24:07 CET 2022] (1671096247000)
[junit-timeout]
ADD:[.../data/TransactionLogsTest/mockcf1-392b3ff07c5a11ed8c662f5760cb10b3/nb-2-big-,0,5][319189529]
{code}
A workaround for this (until we properly fix the way compaction strategies get
notified about sstable changes) is to ignore the timestamp of the STATS
component when cleaning up compaction leftovers on startup.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18118) Do not leak 2015 memtable synthetic Epoch
[
https://issues.apache.org/jira/browse/CASSANDRA-18118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-18118:
Description:
This
[Epoch|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
can
[leak|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/Memtable.java#L392]
affecting all the timestamps logic. It has been observed in a production env
it can i.e. prevent proper sstable and tombstone cleanup.
To reproduce create the following table:
{noformat}
drop keyspace test;
create keyspace test WITH replication = {'class':'SimpleStrategy',
'replication_factor' : 1};
CREATE TABLE test.test (
key text PRIMARY KEY,
id text
) WITH bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '2', 'tombstone_compaction_interval':
'3000', 'tombstone_threshold': '0.1', 'unchecked_tombstone_compaction': 'true'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.0
AND default_time_to_live = 10
AND gc_grace_seconds = 10
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
CREATE INDEX id_idx ON test.test (id);
{noformat}
And stress load it with:
{noformat}
insert into test.test (key,id) values('$RANDOM_UUID $RANDOM_UUID',
'eaca36a1-45f1-469c-a3f6-3ba54220363f') USING TTL 10
{noformat}
Notice how all inserts have a 10s TTL, the default 10s TTL and gc_grace is also
at 10s. This is to speed up the repro:
- Run the load for a couple minutes and track sstables disk usage. You will see
it does only increase, nothing gets cleaned up and it doesn't stop growing
(notice all this is well past the 10s gc_grace and TTL)
- Running a flush and a compaction while under load against the keyspace, table
or index doesn't solve the issue.
- Stopping the load and running a compaction doesn't solve the issue. Flushing
does though.
- On the original observation where TTL was around 600s and gc_grace around
1800s we could get GBs of sstables that weren't cleaned up or compacted away
after hours of work.
- Reproduction can also happen on plain sstables by repeatedly
inserting/deleting/overwriting the same values over and over again without 2i
indices or TTL being involved.
The problem seems to be
[EncodingStats|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
using a synthetic Epoch in 2015 which plays nice with Vint serialization.
Unfortunately {{Memtable}} is using that to keep track of the {{minTimestamp}}
which can leak the 2015 Epoch. This confuses any logic consuming that
timestamp. In this particular case purge and fully expired sstables weren't
properly detected.
was:
This Epoch can leak affecting all the timestamps logic. It has been observed
in a production env it can i.e. prevent proper sstable and tombstone cleanup.
> Do not leak 2015 memtable synthetic Epoch
> -
>
> Key: CASSANDRA-18118
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18118
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
>
> This
> [Epoch|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/rows/EncodingStats.java#L48]
> can
> [leak|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/db/Memtable.java#L392]
> affecting all the timestamps logic. It has been observed in a production
> env it can i.e. prevent proper sstable and tombstone cleanup.
> To reproduce create the following table:
> {noformat}
> drop keyspace test;
> create keyspace test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> CREATE TABLE test.test (
> key text PRIMARY KEY,
> id text
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '2', 'tombstone_compaction_interval':
> '3000', 'tombstone_threshold': '0.1', 'unchecked_tombstone_compaction':
> 'true'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compr
[jira] [Updated] (CASSANDRA-18118) Do not leak 2015 memtable synthetic Epoch
[ https://issues.apache.org/jira/browse/CASSANDRA-18118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18118: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Local/Memtable Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Do not leak 2015 memtable synthetic Epoch > - > > Key: CASSANDRA-18118 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18118 > Project: Cassandra > Issue Type: Bug > Components: Local/Memtable >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > > This Epoch can leak affecting all the timestamps logic. It has been observed > in a production env it can i.e. prevent proper sstable and tombstone cleanup. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18118) Do not leak 2015 memtable synthetic Epoch
Berenguer Blasi created CASSANDRA-18118: --- Summary: Do not leak 2015 memtable synthetic Epoch Key: CASSANDRA-18118 URL: https://issues.apache.org/jira/browse/CASSANDRA-18118 Project: Cassandra Issue Type: Bug Reporter: Berenguer Blasi Assignee: Berenguer Blasi This Epoch can leak affecting all the timestamps logic. It has been observed in a production env it can i.e. prevent proper sstable and tombstone cleanup. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
