[jira] [Updated] (CASSANDRA-16101) Make sure we don't throw any uncaught exceptions during in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16101: Test and Documentation Plan: cci run Status: Patch Available (was: Open) in-jvm dtest PR: https://github.com/apache/cassandra-in-jvm-dtest-api/pull/14 patch: https://github.com/krummas/cassandra/commits/marcuse/16101 I'll post test results once the in-jvm-dtest pr has been merged > Make sure we don't throw any uncaught exceptions during in-jvm dtests > - > > Key: CASSANDRA-16101 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16101 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > We should assert that we don't throw any uncaught exceptions when running > in-jvm dtests -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16109) Don't adjust nodeCount when setting node id topology in in-jvm dtests
Marcus Eriksson created CASSANDRA-16109: --- Summary: Don't adjust nodeCount when setting node id topology in in-jvm dtests Key: CASSANDRA-16109 URL: https://issues.apache.org/jira/browse/CASSANDRA-16109 Project: Cassandra Issue Type: Improvement Components: Test/dtest/java Reporter: Marcus Eriksson Assignee: Marcus Eriksson We update the node count when setting the node id topology in in-jvm dtests, this should only happen if node count is smaller than the node id topology, otherwise bootstrap tests error out. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16109) Don't adjust nodeCount when setting node id topology in in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16109: Test and Documentation Plan: cci run Status: Patch Available (was: Open) https://github.com/apache/cassandra-in-jvm-dtest-api/pull/15 > Don't adjust nodeCount when setting node id topology in in-jvm dtests > - > > Key: CASSANDRA-16109 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16109 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > > We update the node count when setting the node id topology in in-jvm dtests, > this should only happen if node count is smaller than the node id topology, > otherwise bootstrap tests error out. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16109) Don't adjust nodeCount when setting node id topology in in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16109: Change Category: Quality Assurance Complexity: Low Hanging Fruit Reviewers: Alex Petrov Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Don't adjust nodeCount when setting node id topology in in-jvm dtests > - > > Key: CASSANDRA-16109 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16109 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Low > > We update the node count when setting the node id topology in in-jvm dtests, > this should only happen if node count is smaller than the node id topology, > otherwise bootstrap tests error out. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16110) Avoid "involved in several compactions" exception
Marcus Eriksson created CASSANDRA-16110: --- Summary: Avoid "involved in several compactions" exception Key: CASSANDRA-16110 URL: https://issues.apache.org/jira/browse/CASSANDRA-16110 Project: Cassandra Issue Type: Bug Components: Local/Compaction Reporter: Marcus Eriksson Assignee: Marcus Eriksson When aborting compactions we check if the sstable is involved in other anticompactions by grabbing all compactions for a given sstable from ActiveCompactions, it asserts that an sstable is only involved in a single "compaction" here, which is wrong - it can be in several, for example a validation + a regular compaction. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16110) Avoid "involved in several compactions" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16110: Bug Category: Parent values: Degradation(12984)Level 1 values: Other Exception(12998) Complexity: Low Hanging Fruit Discovered By: Code Inspection Fix Version/s: 4.0-beta Severity: Low Status: Open (was: Triage Needed) > Avoid "involved in several compactions" exception > -- > > Key: CASSANDRA-16110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16110 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > When aborting compactions we check if the sstable is involved in other > anticompactions by grabbing all compactions for a given sstable from > ActiveCompactions, it asserts that an sstable is only involved in a single > "compaction" here, which is wrong - it can be in several, for example a > validation + a regular compaction. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16110) Avoid "involved in several compactions" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16110: Test and Documentation Plan: cci run Status: Patch Available (was: Open) cci: https://app.circleci.com/pipelines/github/krummas/cassandra/494/workflows/e33cf891-a041-4bc8-8858-b9089771a157 patch: https://github.com/krummas/cassandra/commits/marcuse/16110 > Avoid "involved in several compactions" exception > -- > > Key: CASSANDRA-16110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16110 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > When aborting compactions we check if the sstable is involved in other > anticompactions by grabbing all compactions for a given sstable from > ActiveCompactions, it asserts that an sstable is only involved in a single > "compaction" here, which is wrong - it can be in several, for example a > validation + a regular compaction. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16110) Avoid "involved in several compactions" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191592#comment-17191592 ] Marcus Eriksson commented on CASSANDRA-16110: - seems I filed this last year, dupe > Avoid "involved in several compactions" exception > -- > > Key: CASSANDRA-16110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16110 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > When aborting compactions we check if the sstable is involved in other > anticompactions by grabbing all compactions for a given sstable from > ActiveCompactions, it asserts that an sstable is only involved in a single > "compaction" here, which is wrong - it can be in several, for example a > validation + a regular compaction. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16110) Avoid "involved in several compactions" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-16110: --- Resolution: Duplicate Status: Resolved (was: Open) > Avoid "involved in several compactions" exception > -- > > Key: CASSANDRA-16110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16110 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > When aborting compactions we check if the sstable is involved in other > anticompactions by grabbing all compactions for a given sstable from > ActiveCompactions, it asserts that an sstable is only involved in a single > "compaction" here, which is wrong - it can be in several, for example a > validation + a regular compaction. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16110) Avoid "involved in several compactions" exception
[ https://issues.apache.org/jira/browse/CASSANDRA-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-16110: --- Status: Open (was: Patch Available) > Avoid "involved in several compactions" exception > -- > > Key: CASSANDRA-16110 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16110 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > When aborting compactions we check if the sstable is involved in other > anticompactions by grabbing all compactions for a given sstable from > ActiveCompactions, it asserts that an sstable is only involved in a single > "compaction" here, which is wrong - it can be in several, for example a > validation + a regular compaction. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15457) Remove bad assert when getting active compactions for an sstable
[ https://issues.apache.org/jira/browse/CASSANDRA-15457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191595#comment-17191595 ] Marcus Eriksson commented on CASSANDRA-15457: - ping [~bdeggleston] new cci run: https://app.circleci.com/pipelines/github/krummas/cassandra/494/workflows/e33cf891-a041-4bc8-8858-b9089771a157 > Remove bad assert when getting active compactions for an sstable > > > Key: CASSANDRA-15457 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15457 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > > CASSANDRA-14935 added a check that an sstable can only be in a single > 'compaction', this is wrong. An sstable can be in a validation and a normal > compaction at the same time for example. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14103) Fix potential race during compaction strategy reload
[
https://issues.apache.org/jira/browse/CASSANDRA-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14103:
Status: Open (was: Patch Available)
> Fix potential race during compaction strategy reload
>
>
> Key: CASSANDRA-14103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14103
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Low
> Attachments: 3.11-14103-dtest.png, 3.11-14103-testall.png,
> trunk-14103-dtest.png, trunk-14103-testall.png
>
>
> When the compaction strategies are reloaded after disk boundary changes
> (CASSANDRA-13948), it's possible that a recently finished SSTable is added
> twice to the compaction strategy: once when the compaction strategies are
> reloaded due to the disk boundary change ({{maybeReloadDiskBoundarie}}), and
> another when the {{CompactionStrategyManager}} is processing the
> {{SSTableAddedNotification}}.
> This should be quite unlikely because a compaction must finish as soon as the
> disk boundary changes, and even if it happens most compaction strategies
> would not be affected by it since they deduplicate sstables internally, but
> we should protect against such scenario.
> For more context see [this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-13948?focusedCommentId=16280448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280448]
> from Marcus.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14103) Fix potential race during compaction strategy reload
[
https://issues.apache.org/jira/browse/CASSANDRA-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson reassigned CASSANDRA-14103:
---
Assignee: Marcus Eriksson (was: Paulo Motta)
> Fix potential race during compaction strategy reload
>
>
> Key: CASSANDRA-14103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14103
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Paulo Motta
>Assignee: Marcus Eriksson
>Priority: Low
> Attachments: 3.11-14103-dtest.png, 3.11-14103-testall.png,
> trunk-14103-dtest.png, trunk-14103-testall.png
>
>
> When the compaction strategies are reloaded after disk boundary changes
> (CASSANDRA-13948), it's possible that a recently finished SSTable is added
> twice to the compaction strategy: once when the compaction strategies are
> reloaded due to the disk boundary change ({{maybeReloadDiskBoundarie}}), and
> another when the {{CompactionStrategyManager}} is processing the
> {{SSTableAddedNotification}}.
> This should be quite unlikely because a compaction must finish as soon as the
> disk boundary changes, and even if it happens most compaction strategies
> would not be affected by it since they deduplicate sstables internally, but
> we should protect against such scenario.
> For more context see [this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-13948?focusedCommentId=16280448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280448]
> from Marcus.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14103) Fix potential race during compaction strategy reload
[
https://issues.apache.org/jira/browse/CASSANDRA-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14103:
Authors: Marcus Eriksson (was: Paulo Motta)
Reviewers: (was: Marcus Eriksson)
Cancelling patch available
It is probably a better idea to make sure LCS correctly handles duplicate
notifications instead of introducing a third place where we track sstables.
> Fix potential race during compaction strategy reload
>
>
> Key: CASSANDRA-14103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14103
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Low
> Attachments: 3.11-14103-dtest.png, 3.11-14103-testall.png,
> trunk-14103-dtest.png, trunk-14103-testall.png
>
>
> When the compaction strategies are reloaded after disk boundary changes
> (CASSANDRA-13948), it's possible that a recently finished SSTable is added
> twice to the compaction strategy: once when the compaction strategies are
> reloaded due to the disk boundary change ({{maybeReloadDiskBoundarie}}), and
> another when the {{CompactionStrategyManager}} is processing the
> {{SSTableAddedNotification}}.
> This should be quite unlikely because a compaction must finish as soon as the
> disk boundary changes, and even if it happens most compaction strategies
> would not be affected by it since they deduplicate sstables internally, but
> we should protect against such scenario.
> For more context see [this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-13948?focusedCommentId=16280448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280448]
> from Marcus.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14103) Fix potential race during compaction strategy reload
[
https://issues.apache.org/jira/browse/CASSANDRA-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14103:
Severity: Critical (was: Low)
> Fix potential race during compaction strategy reload
>
>
> Key: CASSANDRA-14103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14103
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Paulo Motta
>Assignee: Marcus Eriksson
>Priority: Urgent
> Attachments: 3.11-14103-dtest.png, 3.11-14103-testall.png,
> trunk-14103-dtest.png, trunk-14103-testall.png
>
>
> When the compaction strategies are reloaded after disk boundary changes
> (CASSANDRA-13948), it's possible that a recently finished SSTable is added
> twice to the compaction strategy: once when the compaction strategies are
> reloaded due to the disk boundary change ({{maybeReloadDiskBoundarie}}), and
> another when the {{CompactionStrategyManager}} is processing the
> {{SSTableAddedNotification}}.
> This should be quite unlikely because a compaction must finish as soon as the
> disk boundary changes, and even if it happens most compaction strategies
> would not be affected by it since they deduplicate sstables internally, but
> we should protect against such scenario.
> For more context see [this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-13948?focusedCommentId=16280448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280448]
> from Marcus.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14103) Fix potential race during compaction strategy reload
[
https://issues.apache.org/jira/browse/CASSANDRA-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-14103:
Authors: (was: Marcus Eriksson)
> Fix potential race during compaction strategy reload
>
>
> Key: CASSANDRA-14103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14103
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Paulo Motta
>Assignee: Marcus Eriksson
>Priority: Low
> Attachments: 3.11-14103-dtest.png, 3.11-14103-testall.png,
> trunk-14103-dtest.png, trunk-14103-testall.png
>
>
> When the compaction strategies are reloaded after disk boundary changes
> (CASSANDRA-13948), it's possible that a recently finished SSTable is added
> twice to the compaction strategy: once when the compaction strategies are
> reloaded due to the disk boundary change ({{maybeReloadDiskBoundarie}}), and
> another when the {{CompactionStrategyManager}} is processing the
> {{SSTableAddedNotification}}.
> This should be quite unlikely because a compaction must finish as soon as the
> disk boundary changes, and even if it happens most compaction strategies
> would not be affected by it since they deduplicate sstables internally, but
> we should protect against such scenario.
> For more context see [this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-13948?focusedCommentId=16280448&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280448]
> from Marcus.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13935) Indexes and UDTs creation should have IF NOT EXISTS on its String representation
[
https://issues.apache.org/jira/browse/CASSANDRA-13935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191610#comment-17191610
]
Benjamin Lerer commented on CASSANDRA-13935:
The patch for 4.0 looks good to me. I think we would need one for 3.0 and 3.11.
> Indexes and UDTs creation should have IF NOT EXISTS on its String
> representation
>
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/CQL
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I came across something that bothers me a lot. I'm using snapshots to backup
> data from my Cassandra cluster in case something really bad happens (like
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the
> schema put on the file "schema.cql" as a result of the snapshot has the
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas
> to build up the table structure, everything seems fine for tables without
> secondary indexes, but for the ones that make use of them, the execution of
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
> id text PRIMARY KEY,
> content text,
> last_update_date date,
> last_update_date_time timestamp)
> WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
> AND bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.1
> AND crc_check_chance = 1.0
> AND default_time_to_live = 864
> AND gc_grace_seconds = 864000
> AND min_index_interval = 128
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE'
> AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
> AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
> AND compression = { 'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
> AND cdc = false
> AND extensions = { };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> // edit by Stefan Miklosovic
> PR: https://github.com/apache/cassandra/pull/731
> I have added UDTs as part of this patch as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index
[ https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhaoYang updated CASSANDRA-16092: - Source Control Link: https://github.com/apache/cassandra/pull/735 > Add Index Group Interface for Storage Attached Index > > > Key: CASSANDRA-16092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16092 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SASI >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > > [Index > group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634] > interface allows: > * indexes on the same table to receive centralized lifecycle events called > secondary index groups. Sharing of data between multiple column indexes on > the same table allows SAI disk usage to realise significant space savings > over other index implementations. > * index-group to analyze user query and provide a query plan that leverages > all available indexes within the group. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index
[
https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191625#comment-17191625
]
ZhaoYang commented on CASSANDRA-16092:
--
I have ported [Index interface
changes|https://github.com/apache/cassandra/pull/735] for Storage Attached
Index:
* {{Index#Group}} to manage lifecycle of multiple indexes that can communicate
with each other.
* {{Index#QueryPlan}} to provide a set of indexes that can work together for a
given query.
* {{Index#Searcher}} to perform actual index searching.
* Enhanced {{SSTableFlushObserver}} to pass partition deletion, static row,
unfilter separately.
* Moved {{UpdateTransaction}} into {{CFS}} so that we can make sure memtable
and index memtable are in-sync.
cc [~adelapena] [~maedhroz]
> Add Index Group Interface for Storage Attached Index
>
>
> Key: CASSANDRA-16092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16092
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/SASI
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
>
> [Index
> group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634]
> interface allows:
> * indexes on the same table to receive centralized lifecycle events called
> secondary index groups. Sharing of data between multiple column indexes on
> the same table allows SAI disk usage to realise significant space savings
> over other index implementations.
> * index-group to analyze user query and provide a query plan that leverages
> all available indexes within the group.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index
[ https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhaoYang updated CASSANDRA-16092: - Change Category: Code Clarity Complexity: Normal Fix Version/s: 4.x Status: Open (was: Triage Needed) > Add Index Group Interface for Storage Attached Index > > > Key: CASSANDRA-16092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16092 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SASI >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.x > > > [Index > group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634] > interface allows: > * indexes on the same table to receive centralized lifecycle events called > secondary index groups. Sharing of data between multiple column indexes on > the same table allows SAI disk usage to realise significant space savings > over other index implementations. > * index-group to analyze user query and provide a query plan that leverages > all available indexes within the group. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13935) Indexes and UDTs creation should have IF NOT EXISTS on its String representation
[
https://issues.apache.org/jira/browse/CASSANDRA-13935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191668#comment-17191668
]
Robert Stupp commented on CASSANDRA-13935:
--
Sorry, I'll probably not have time to review.
> Indexes and UDTs creation should have IF NOT EXISTS on its String
> representation
>
>
> Key: CASSANDRA-13935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13935
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Legacy/CQL
> Environment: Ubuntu 16.04.2 LTS
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Javier Canillas
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0-beta
>
> Attachments: 13935-3.0.txt, 13935-3.11.txt, 13935-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I came across something that bothers me a lot. I'm using snapshots to backup
> data from my Cassandra cluster in case something really bad happens (like
> dropping a table or a keyspace).
> Exercising the recovery actions from those backups, I discover that the
> schema put on the file "schema.cql" as a result of the snapshot has the
> "CREATE IF NOT EXISTS" for the table, but not for the indexes.
> When restoring from snapshots, and relying on the execution of these schemas
> to build up the table structure, everything seems fine for tables without
> secondary indexes, but for the ones that make use of them, the execution of
> these statements fail miserably.
> Here I paste a generated schema.cql content for a table with indexes:
> CREATE TABLE IF NOT EXISTS keyspace1.table1 (
> id text PRIMARY KEY,
> content text,
> last_update_date date,
> last_update_date_time timestamp)
> WITH ID = f1045fc0-2f59-11e7-95ec-295c3c064920
> AND bloom_filter_fp_chance = 0.01
> AND dclocal_read_repair_chance = 0.1
> AND crc_check_chance = 1.0
> AND default_time_to_live = 864
> AND gc_grace_seconds = 864000
> AND min_index_interval = 128
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE'
> AND caching = { 'keys': 'NONE', 'rows_per_partition': 'NONE' }
> AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
> 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
> AND compression = { 'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor' }
> AND cdc = false
> AND extensions = { };
> CREATE INDEX table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> I think the last part should be:
> CREATE INDEX IF NOT EXISTS table1_last_update_date_idx ON keyspace1.table1
> (last_update_date);
> // edit by Stefan Miklosovic
> PR: https://github.com/apache/cassandra/pull/731
> I have added UDTs as part of this patch as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16109) Don't adjust nodeCount when setting node id topology in in-jvm dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191679#comment-17191679
]
Alex Petrov commented on CASSANDRA-16109:
-
+1, this looks good to me, assuming it doesn't break any tests.
That said, should we change the name of {{nodeCount}}, or at least document
somewhere that {{nodeCount}}, in combination with {{topology}}, will have a
meaning of "start X nodes" only, and the rest of the nodes should be started
manually, or something like that.
> Don't adjust nodeCount when setting node id topology in in-jvm dtests
> -
>
> Key: CASSANDRA-16109
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16109
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Low
>
> We update the node count when setting the node id topology in in-jvm dtests,
> this should only happen if node count is smaller than the node id topology,
> otherwise bootstrap tests error out.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16102) Build target for shaded in-JVM dtest jar
[ https://issues.apache.org/jira/browse/CASSANDRA-16102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191680#comment-17191680 ] Alex Petrov edited comment on CASSANDRA-16102 at 9/7/20, 12:27 PM: --- Branch: https://github.com/ifesdjeen/cassandra/tree/16102-trunk was (Author: ifesdjeen): Patch: https://github.com/ifesdjeen/cassandra/tree/16102-trunk > Build target for shaded in-JVM dtest jar > > > Key: CASSANDRA-16102 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16102 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > > Several small changes that are required as a prerequisite for releasing > [Harry|https://issues.apache.org/jira/browse/CASSANDRA-15348]: > 1. Update snakeYaml in Cassandra > 2. Add a shade maven target and packaging script for shaded dtest artifacts -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16102) Build target for shaded in-JVM dtest jar
[ https://issues.apache.org/jira/browse/CASSANDRA-16102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191680#comment-17191680 ] Alex Petrov commented on CASSANDRA-16102: - Patch: https://github.com/ifesdjeen/cassandra/tree/16102-trunk > Build target for shaded in-JVM dtest jar > > > Key: CASSANDRA-16102 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16102 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > > Several small changes that are required as a prerequisite for releasing > [Harry|https://issues.apache.org/jira/browse/CASSANDRA-15348]: > 1. Update snakeYaml in Cassandra > 2. Add a shade maven target and packaging script for shaded dtest artifacts -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16102) Build target for shaded in-JVM dtest jar
[ https://issues.apache.org/jira/browse/CASSANDRA-16102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16102: Description: Several small changes that are required as a prerequisite for releasing [Harry|https://issues.apache.org/jira/browse/CASSANDRA-15348]: 1. Update snakeYaml in Cassandra 2. Add a shade maven target and packaging script for shaded dtest artifacts This patch is only a bridge for everyone to test out Harry with trunk/4.0, before we're ready to build in-JVM dtest jars for every version, and stop depending on java-driver (and, subsequently, on Netty and Guava) in Harry. was: Several small changes that are required as a prerequisite for releasing [Harry|https://issues.apache.org/jira/browse/CASSANDRA-15348]: 1. Update snakeYaml in Cassandra 2. Add a shade maven target and packaging script for shaded dtest artifacts > Build target for shaded in-JVM dtest jar > > > Key: CASSANDRA-16102 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16102 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > > Several small changes that are required as a prerequisite for releasing > [Harry|https://issues.apache.org/jira/browse/CASSANDRA-15348]: > 1. Update snakeYaml in Cassandra > 2. Add a shade maven target and packaging script for shaded dtest artifacts > This patch is only a bridge for everyone to test out Harry with trunk/4.0, > before we're ready to build in-JVM dtest jars for every version, and stop > depending on java-driver (and, subsequently, on Netty and Guava) in Harry. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16102) Build target for shaded in-JVM dtest jar
[ https://issues.apache.org/jira/browse/CASSANDRA-16102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16102: Reviewers: Marcus Eriksson > Build target for shaded in-JVM dtest jar > > > Key: CASSANDRA-16102 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16102 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > > Several small changes that are required as a prerequisite for releasing > [Harry|https://issues.apache.org/jira/browse/CASSANDRA-15348]: > 1. Update snakeYaml in Cassandra > 2. Add a shade maven target and packaging script for shaded dtest artifacts > This patch is only a bridge for everyone to test out Harry with trunk/4.0, > before we're ready to build in-JVM dtest jars for every version, and stop > depending on java-driver (and, subsequently, on Netty and Guava) in Harry. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16101) Make sure we don't throw any uncaught exceptions during in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191690#comment-17191690 ] Alex Petrov commented on CASSANDRA-16101: - +1, both patches LGTM. > Make sure we don't throw any uncaught exceptions during in-jvm dtests > - > > Key: CASSANDRA-16101 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16101 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > We should assert that we don't throw any uncaught exceptions when running > in-jvm dtests -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16102) Build target for shaded in-JVM dtest jar
[ https://issues.apache.org/jira/browse/CASSANDRA-16102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16102: Test and Documentation Plan: manual testing Status: Patch Available (was: Open) > Build target for shaded in-JVM dtest jar > > > Key: CASSANDRA-16102 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16102 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > > Several small changes that are required as a prerequisite for releasing > [Harry|https://issues.apache.org/jira/browse/CASSANDRA-15348]: > 1. Update snakeYaml in Cassandra > 2. Add a shade maven target and packaging script for shaded dtest artifacts > This patch is only a bridge for everyone to test out Harry with trunk/4.0, > before we're ready to build in-JVM dtest jars for every version, and stop > depending on java-driver (and, subsequently, on Netty and Guava) in Harry. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16102) Build target for shaded in-JVM dtest jar
[ https://issues.apache.org/jira/browse/CASSANDRA-16102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16102: Reviewers: Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson) Marcus Eriksson, Marcus Eriksson (was: Marcus Eriksson) Status: Review In Progress (was: Patch Available) > Build target for shaded in-JVM dtest jar > > > Key: CASSANDRA-16102 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16102 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > > Several small changes that are required as a prerequisite for releasing > [Harry|https://issues.apache.org/jira/browse/CASSANDRA-15348]: > 1. Update snakeYaml in Cassandra > 2. Add a shade maven target and packaging script for shaded dtest artifacts > This patch is only a bridge for everyone to test out Harry with trunk/4.0, > before we're ready to build in-JVM dtest jars for every version, and stop > depending on java-driver (and, subsequently, on Netty and Guava) in Harry. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16102) Build target for shaded in-JVM dtest jar
[ https://issues.apache.org/jira/browse/CASSANDRA-16102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16102: Status: Ready to Commit (was: Review In Progress) 2 small comments inline - feel free to fix on commit > Build target for shaded in-JVM dtest jar > > > Key: CASSANDRA-16102 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16102 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > > Several small changes that are required as a prerequisite for releasing > [Harry|https://issues.apache.org/jira/browse/CASSANDRA-15348]: > 1. Update snakeYaml in Cassandra > 2. Add a shade maven target and packaging script for shaded dtest artifacts > This patch is only a bridge for everyone to test out Harry with trunk/4.0, > before we're ready to build in-JVM dtest jars for every version, and stop > depending on java-driver (and, subsequently, on Netty and Guava) in Harry. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191705#comment-17191705
]
Stefan Miklosovic commented on CASSANDRA-15158:
---
I am getting this exception on totally clean node, I am bootstrapping a cluster
of 3 nodes:
{code:java}
cassandra_node_1| INFO [ScheduledTasks:1] 2020-09-07 15:10:13,037
TokenMetadata.java:517 - Updating topology for all endpoints that have changed
cassandra_node_1| INFO [HANDSHAKE-spark-master-1/172.19.0.5] 2020-09-07
15:10:13,311 OutboundTcpConnection.java:561 - Handshaking version with
spark-master-1/172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,870
Gossiper.java:1141 - Node /172.19.0.5 is now part of the cluster
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,904
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,907
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:14,052
Gossiper.java:1103 - InetAddress /172.19.0.5 is now UP
cassandra_node_1| WARN [MessagingService-Incoming-/172.19.0.5] 2020-09-07
15:10:14,119 IncomingTcpConnection.java:103 - UnknownColumnFamilyException
reading from socket; closing
cassandra_node_1| org.apache.cassandra.db.UnknownColumnFamilyException:
Couldn't find table for cfId 5bc52802-de25-35ed-aeab-188eecebb090. If a table
was just created, this is likely due to the schema not being fully propagated.
Please wait for schema agreement on table creation.
cassandra_node_1| at
org.apache.cassandra.config.CFMetaData$Serializer.deserialize(CFMetaData.java:1578)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize30(PartitionUpdate.java:899)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize(PartitionUpdate.java:874)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:415)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:434)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:371)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.net.MessageIn.read(MessageIn.java:123)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:195)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:183)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
{code}
That cfId stands for system_roles. It seems like we are applying changes before
schema agreement has occured so that table is not there yet to apply mutations
against.
> Wait for schema agreement rather than in flight schema requests when
> bootstrapping
> --
>
> Key: CASSANDRA-15158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15158
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Schema
>Reporter: Vincent White
>Assignee: Blake Eggleston
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a node is bootstrapping we use a set of latches
> (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of
> in-flight schema pull requests, and we don't proceed with
> bootstrapping/stream until all the latches are released (or we timeout
> waiting for each one). One issue with this is that if we have a large schema,
> or the retrieval of the schema from the other nodes was unexpectedly slow
> then we have no explicit check in place to ensure we have actually received a
> schema before we proceed.
> While it's possible to increase "migration_task_wait_in_seconds" to force the
> node to wait on each latche longer, there are cases where this doesn't help
> because the callbacks for the schema pull requests have expired off the
> messaging service's callback map
> (org.apache.cassandra.net.MessagingService#callbacks) after
> request_timeout_in_ms (default 10 seconds) before the other nodes were able
> to respond
[jira] [Comment Edited] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191705#comment-17191705
]
Stefan Miklosovic edited comment on CASSANDRA-15158 at 9/7/20, 1:18 PM:
I am getting this exception on totally clean node, I am bootstrapping a cluster
of 3 nodes:
{code:java}
cassandra_node_1| INFO [ScheduledTasks:1] 2020-09-07 15:10:13,037
TokenMetadata.java:517 - Updating topology for all endpoints that have changed
cassandra_node_1| INFO [HANDSHAKE-spark-master-1/172.19.0.5] 2020-09-07
15:10:13,311 OutboundTcpConnection.java:561 - Handshaking version with
spark-master-1/172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,870
Gossiper.java:1141 - Node /172.19.0.5 is now part of the cluster
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,904
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,907
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:14,052
Gossiper.java:1103 - InetAddress /172.19.0.5 is now UP
cassandra_node_1| WARN [MessagingService-Incoming-/172.19.0.5] 2020-09-07
15:10:14,119 IncomingTcpConnection.java:103 - UnknownColumnFamilyException
reading from socket; closing
cassandra_node_1| org.apache.cassandra.db.UnknownColumnFamilyException:
Couldn't find table for cfId 5bc52802-de25-35ed-aeab-188eecebb090. If a table
was just created, this is likely due to the schema not being fully propagated.
Please wait for schema agreement on table creation.
cassandra_node_1| at
org.apache.cassandra.config.CFMetaData$Serializer.deserialize(CFMetaData.java:1578)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize30(PartitionUpdate.java:899)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize(PartitionUpdate.java:874)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:415)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:434)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:371)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.net.MessageIn.read(MessageIn.java:123)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:195)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:183)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
{code}
That cfId stands for system_auth/roles. It seems like we are applying changes
before schema agreement has occured so that table is not there yet to apply
mutations against.
was (Author: stefan.miklosovic):
I am getting this exception on totally clean node, I am bootstrapping a cluster
of 3 nodes:
{code:java}
cassandra_node_1| INFO [ScheduledTasks:1] 2020-09-07 15:10:13,037
TokenMetadata.java:517 - Updating topology for all endpoints that have changed
cassandra_node_1| INFO [HANDSHAKE-spark-master-1/172.19.0.5] 2020-09-07
15:10:13,311 OutboundTcpConnection.java:561 - Handshaking version with
spark-master-1/172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,870
Gossiper.java:1141 - Node /172.19.0.5 is now part of the cluster
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,904
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,907
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:14,052
Gossiper.java:1103 - InetAddress /172.19.0.5 is now UP
cassandra_node_1| WARN [MessagingService-Incoming-/172.19.0.5] 2020-09-07
15:10:14,119 IncomingTcpConnection.java:103 - UnknownColumnFamilyException
reading from socket; closing
cassandra_node_1| org.apache.cassandra.db.UnknownColumnFamilyException:
Couldn't find table for cfId 5bc52802-de25-35ed-aeab-188eecebb090. If a table
was just created, this is likely due to the schema not being fully propagated.
Please wait for schema agreement on table creation.
cassandra_node_1| at
o
[jira] [Commented] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191711#comment-17191711 ] Stefan Miklosovic commented on CASSANDRA-15158: --- There is also a runtime error as that concurrent hash map from that package is not a class path. I removed it here, I just squashed all changes in Blakes branch + this one fix: https://github.com/instaclustr/cassandra/commit/af82bc2f1a4f9eff09458101c63027e919873af9 > Wait for schema agreement rather than in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Blake Eggleston >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191711#comment-17191711 ] Stefan Miklosovic edited comment on CASSANDRA-15158 at 9/7/20, 1:37 PM: There is also a runtime error as that concurrent hash map from that package is not on the class path. I removed it here, I just squashed all changes in Blakes branch + this one fix: https://github.com/instaclustr/cassandra/commit/af82bc2f1a4f9eff09458101c63027e919873af9 was (Author: stefan.miklosovic): There is also a runtime error as that concurrent hash map from that package is not a class path. I removed it here, I just squashed all changes in Blakes branch + this one fix: https://github.com/instaclustr/cassandra/commit/af82bc2f1a4f9eff09458101c63027e919873af9 > Wait for schema agreement rather than in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Blake Eggleston >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16107) Remove duplicate line in Cassandra docs about virtual tables limitations
[ https://issues.apache.org/jira/browse/CASSANDRA-16107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16107: --- Bug Category: Parent values: Documentation(13562) (was: Parent values: Correctness(12982)Level 1 values: API / Semantic Definition(13162)) > Remove duplicate line in Cassandra docs about virtual tables limitations > > > Key: CASSANDRA-16107 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16107 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Fábio Takeo Ueno >Assignee: Fábio Takeo Ueno >Priority: Normal > Fix For: 4.0-beta3 > > Time Spent: 20m > Remaining Estimate: 0h > > Lines 81 and 84 of cassandra/doc/source/new/virtualtable.rst are exactly the > same. This should just remove one of them. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191711#comment-17191711 ] Stefan Miklosovic edited comment on CASSANDRA-15158 at 9/7/20, 1:42 PM: There is also a runtime error as that concurrent hash map from that package is not on the class path. I removed it here, I just squashed all changes in Blakes branch + this one fix: https://github.com/instaclustr/cassandra/commit/e23677deeb7c836b4b7c80f98009353668351620 was (Author: stefan.miklosovic): There is also a runtime error as that concurrent hash map from that package is not on the class path. I removed it here, I just squashed all changes in Blakes branch + this one fix: https://github.com/instaclustr/cassandra/commit/af82bc2f1a4f9eff09458101c63027e919873af9 > Wait for schema agreement rather than in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Blake Eggleston >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16093) Cassandra website is building/including the wrong versioned nodetool docs
[ https://issues.apache.org/jira/browse/CASSANDRA-16093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16093: --- Bug Category: Parent values: Documentation(13562) (was: Parent values: Correctness(12982)Level 1 values: API / Semantic Definition(13162)) > Cassandra website is building/including the wrong versioned nodetool docs > - > > Key: CASSANDRA-16093 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16093 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 3.11.9, 4.0-beta3 > > > For example > https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html > shouldn't be under the 3.11 documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191705#comment-17191705
]
Stefan Miklosovic edited comment on CASSANDRA-15158 at 9/7/20, 1:49 PM:
I am getting this exception on totally clean node, I am bootstrapping a cluster
of 3 nodes:
{code:java}
cassandra_node_1| INFO [ScheduledTasks:1] 2020-09-07 15:10:13,037
TokenMetadata.java:517 - Updating topology for all endpoints that have changed
cassandra_node_1| INFO [HANDSHAKE-spark-master-1/172.19.0.5] 2020-09-07
15:10:13,311 OutboundTcpConnection.java:561 - Handshaking version with
spark-master-1/172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,870
Gossiper.java:1141 - Node /172.19.0.5 is now part of the cluster
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,904
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,907
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:14,052
Gossiper.java:1103 - InetAddress /172.19.0.5 is now UP
cassandra_node_1| WARN [MessagingService-Incoming-/172.19.0.5] 2020-09-07
15:10:14,119 IncomingTcpConnection.java:103 - UnknownColumnFamilyException
reading from socket; closing
cassandra_node_1| org.apache.cassandra.db.UnknownColumnFamilyException:
Couldn't find table for cfId 5bc52802-de25-35ed-aeab-188eecebb090. If a table
was just created, this is likely due to the schema not being fully propagated.
Please wait for schema agreement on table creation.
cassandra_node_1| at
org.apache.cassandra.config.CFMetaData$Serializer.deserialize(CFMetaData.java:1578)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize30(PartitionUpdate.java:899)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.partitions.PartitionUpdate$PartitionUpdateSerializer.deserialize(PartitionUpdate.java:874)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:415)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:434)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.db.Mutation$MutationSerializer.deserialize(Mutation.java:371)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.net.MessageIn.read(MessageIn.java:123)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:195)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
cassandra_node_1| at
org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:183)
~[apache-cassandra-3.11.9-SNAPSHOT.jar:3.11.9-SNAPSHOT]
{code}
That cfId stands for system_auth/roles. It seems like we are applying changes
before schema agreement has occured so that table is not there yet to apply
mutations against.
This is the log from the second node. The first one booted fine, the second one
throws this, the third one boots fine. It seems like eventually everything is
just fine however that exception is ... concerning.
was (Author: stefan.miklosovic):
I am getting this exception on totally clean node, I am bootstrapping a cluster
of 3 nodes:
{code:java}
cassandra_node_1| INFO [ScheduledTasks:1] 2020-09-07 15:10:13,037
TokenMetadata.java:517 - Updating topology for all endpoints that have changed
cassandra_node_1| INFO [HANDSHAKE-spark-master-1/172.19.0.5] 2020-09-07
15:10:13,311 OutboundTcpConnection.java:561 - Handshaking version with
spark-master-1/172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,870
Gossiper.java:1141 - Node /172.19.0.5 is now part of the cluster
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,904
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:13,907
TokenMetadata.java:497 - Updating topology for /172.19.0.5
cassandra_node_1| INFO [GossipStage:1] 2020-09-07 15:10:14,052
Gossiper.java:1103 - InetAddress /172.19.0.5 is now UP
cassandra_node_1| WARN [MessagingService-Incoming-/172.19.0.5] 2020-09-07
15:10:14,119 IncomingTcpConnection.java:103 - UnknownColumnFamilyException
reading from socket; closing
cassandra_node_1| org.apache.cassandra.db.UnknownColumnFamilyException:
Couldn't find table for cfId
[jira] [Updated] (CASSANDRA-16108) Concurrent Index Memtable implementation using Trie
[
https://issues.apache.org/jira/browse/CASSANDRA-16108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-16108:
-
Fix Version/s: 4.x
> Concurrent Index Memtable implementation using Trie
> ---
>
> Key: CASSANDRA-16108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16108
> Project: Cassandra
> Issue Type: New Feature
>Reporter: ZhaoYang
>Assignee: ratcharod
>Priority: Normal
> Fix For: 4.x
>
>
> Replace existing \{{ConcurrentRadixTree}} with Trie implementation for both
> numeric index and string index to reduce memory usage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index
[ https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhaoYang updated CASSANDRA-16092: - Test and Documentation Plan: https://app.circleci.com/pipelines/github/jasonstack/cassandra/305/workflows/6c813342-2bdb-4740-8599-6a8c34ab97da Status: Patch Available (was: In Progress) > Add Index Group Interface for Storage Attached Index > > > Key: CASSANDRA-16092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16092 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SASI >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.x > > > [Index > group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634] > interface allows: > * indexes on the same table to receive centralized lifecycle events called > secondary index groups. Sharing of data between multiple column indexes on > the same table allows SAI disk usage to realise significant space savings > over other index implementations. > * index-group to analyze user query and provide a query plan that leverages > all available indexes within the group. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index
[ https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ZhaoYang updated CASSANDRA-16092: - Change Category: Semantic (was: Code Clarity) > Add Index Group Interface for Storage Attached Index > > > Key: CASSANDRA-16092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16092 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SASI >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.x > > > [Index > group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634] > interface allows: > * indexes on the same table to receive centralized lifecycle events called > secondary index groups. Sharing of data between multiple column indexes on > the same table allows SAI disk usage to realise significant space savings > over other index implementations. > * index-group to analyze user query and provide a query plan that leverages > all available indexes within the group. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15158) Wait for schema agreement rather than in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191793#comment-17191793 ] Stefan Miklosovic commented on CASSANDRA-15158: --- These tests are failing https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/4/#showFailuresLink > Wait for schema agreement rather than in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Blake Eggleston >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index
[ https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16092: Reviewers: Caleb Rackliffe > Add Index Group Interface for Storage Attached Index > > > Key: CASSANDRA-16092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16092 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SASI >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.x > > > [Index > group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634] > interface allows: > * indexes on the same table to receive centralized lifecycle events called > secondary index groups. Sharing of data between multiple column indexes on > the same table allows SAI disk usage to realise significant space savings > over other index implementations. > * index-group to analyze user query and provide a query plan that leverages > all available indexes within the group. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16092) Add Index Group Interface for Storage Attached Index
[ https://issues.apache.org/jira/browse/CASSANDRA-16092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191919#comment-17191919 ] Caleb Rackliffe commented on CASSANDRA-16092: - Not that it's going to be a top priority for you ATM, but CC [~samt] just for visibility. > Add Index Group Interface for Storage Attached Index > > > Key: CASSANDRA-16092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16092 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SASI >Reporter: ZhaoYang >Assignee: ZhaoYang >Priority: Normal > Fix For: 4.x > > > [Index > group|https://github.com/datastax/cassandra/blob/storage_attached_index/src/java/org/apache/cassandra/index/Index.java#L634] > interface allows: > * indexes on the same table to receive centralized lifecycle events called > secondary index groups. Sharing of data between multiple column indexes on > the same table allows SAI disk usage to realise significant space savings > over other index implementations. > * index-group to analyze user query and provide a query plan that leverages > all available indexes within the group. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15502) In Tree Tooling with Java 11
[ https://issues.apache.org/jira/browse/CASSANDRA-15502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191926#comment-17191926 ] Berenguer Blasi commented on CASSANDRA-15502: - [~dcapwell] as you are reviewing CASSANDRA-15991 you'll notice we have some basic j11 tooling testing there. I am not sure if that covers already what you intended to test or if you wanted to go much deeper in this ticket. Do you think we can close this ticket? > In Tree Tooling with Java 11 > > > Key: CASSANDRA-15502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15502 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python, Test/fuzz, Tool/bulk > load, Tool/cqlsh, Tool/diff, Tool/fql, Tool/nodetool, Tool/sstable, > Tool/stress >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > This is to cover testing the various tools running on java 11. > The scope of this testing is manual testing and not automated, different > JIRAs should cover automation testing these tool. > The tools in question are: nodetool, sstableloader, sstablescrub, > sstableupgrade, sstableutil, sstableverify, fqltool, stress, auditlogviewer, > compaction-stress, sstabledump, sstableexpiredblockers, sstablemetadata, > sstableofflinerelevel, sstablesplit, and sstablerepairedset (many of these > may be tested already in dtest) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15880) Memory leak in CompressedChunkReader
[ https://issues.apache.org/jira/browse/CASSANDRA-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-15880: --- Assignee: Berenguer Blasi > Memory leak in CompressedChunkReader > > > Key: CASSANDRA-15880 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15880 > Project: Cassandra > Issue Type: Bug > Components: Feature/Compression >Reporter: Jaroslaw Grabowski >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0, 3.11.x > > > CompressedChunkReader uses java.lang.ThreadLocal to reuse ByteBuffer for > compressed data. ByteBuffers leak due to peculiar ThreadLocal quality. > ThreadLocals are stored in a map, where the key is a weak reference to a > ThreadLocal and the value is the user's object (ByteBuffer in this case). > When a last strong reference to a ThreadLocal is lost, weak reference to > ThreadLocal (key) is removed but the value (ByteBuffer) is kept until cleaned > by ThreadLocal heuristic expunge mechanism. See ThreadLocal's "stale entries" > for details. > When a number of long-living threads is high enough this results in thousands > of ByteBuffers stored as stale entries in ThreadLocals. In a not-so-lucky > scenario we get OutOfMemoryException. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16111) Cassandra support add more thant one new nodes at the same time
maxwellguo created CASSANDRA-16111: -- Summary: Cassandra support add more thant one new nodes at the same time Key: CASSANDRA-16111 URL: https://issues.apache.org/jira/browse/CASSANDRA-16111 Project: Cassandra Issue Type: Improvement Components: Cluster/Gossip, Consistency/Bootstrap and Decommission, Consistency/Streaming Reporter: maxwellguo Assignee: maxwellguo We know that cassandra can not support more than node bootstrap at one time, while the cassandra.consistent.rangemovement is true and cassandra.consistent.simultaneousmoves.allow is false and if there exist one node be of bootstrapping/leaving/moving status . If more thant one node doing boostrap, there may exist replica data being not consistent. But actually add new node one by one is time cost , especially when adding a new node will cost very long time. So we want to add more than one node at one time. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15880) Memory leak in CompressedChunkReader
[
https://issues.apache.org/jira/browse/CASSANDRA-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191949#comment-17191949
]
Berenguer Blasi commented on CASSANDRA-15880:
-
Note for the reviewer: {{CompressedChunkReader.Standard}} is a
{{RebuffererFactory}} where the main method at use is
{{CompressedChunkReader.instantiateRebufferer()}}. That one wraps the reader in
a {{BufferManagingRebufferer}} which will call {{close()}} and also is
{{AutoClosable}}. I have checked for uses of the reader in the code and as
expected it is being closed/auto closed so I expect the {{ThreadLocal}} to be
properly removed and not leak now.
> Memory leak in CompressedChunkReader
>
>
> Key: CASSANDRA-15880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15880
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Compression
>Reporter: Jaroslaw Grabowski
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CompressedChunkReader uses java.lang.ThreadLocal to reuse ByteBuffer for
> compressed data. ByteBuffers leak due to peculiar ThreadLocal quality.
> ThreadLocals are stored in a map, where the key is a weak reference to a
> ThreadLocal and the value is the user's object (ByteBuffer in this case).
> When a last strong reference to a ThreadLocal is lost, weak reference to
> ThreadLocal (key) is removed but the value (ByteBuffer) is kept until cleaned
> by ThreadLocal heuristic expunge mechanism. See ThreadLocal's "stale entries"
> for details.
> When a number of long-living threads is high enough this results in thousands
> of ByteBuffers stored as stale entries in ThreadLocals. In a not-so-lucky
> scenario we get OutOfMemoryException.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15880) Memory leak in CompressedChunkReader
[
https://issues.apache.org/jira/browse/CASSANDRA-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191949#comment-17191949
]
Berenguer Blasi edited comment on CASSANDRA-15880 at 9/8/20, 5:33 AM:
--
Note for the reviewer: {{CompressedChunkReader.Standard}} is a
{{RebuffererFactory}} where the main method at use is
{{CompressedChunkReader.instantiateRebufferer()}}. That one wraps the reader in
a {{BufferManagingRebufferer}} which will call {{close()}} and it's
{{AutoClosable}} also. I have checked for uses of the reader in the code and as
expected it is being closed/auto closed so I expect the {{ThreadLocal}} to be
properly removed and not leak now.
was (Author: bereng):
Note for the reviewer: {{CompressedChunkReader.Standard}} is a
{{RebuffererFactory}} where the main method at use is
{{CompressedChunkReader.instantiateRebufferer()}}. That one wraps the reader in
a {{BufferManagingRebufferer}} which will call {{close()}} and also is
{{AutoClosable}}. I have checked for uses of the reader in the code and as
expected it is being closed/auto closed so I expect the {{ThreadLocal}} to be
properly removed and not leak now.
> Memory leak in CompressedChunkReader
>
>
> Key: CASSANDRA-15880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15880
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Compression
>Reporter: Jaroslaw Grabowski
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 3.11.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CompressedChunkReader uses java.lang.ThreadLocal to reuse ByteBuffer for
> compressed data. ByteBuffers leak due to peculiar ThreadLocal quality.
> ThreadLocals are stored in a map, where the key is a weak reference to a
> ThreadLocal and the value is the user's object (ByteBuffer in this case).
> When a last strong reference to a ThreadLocal is lost, weak reference to
> ThreadLocal (key) is removed but the value (ByteBuffer) is kept until cleaned
> by ThreadLocal heuristic expunge mechanism. See ThreadLocal's "stale entries"
> for details.
> When a number of long-living threads is high enough this results in thousands
> of ByteBuffers stored as stale entries in ThreadLocals. In a not-so-lucky
> scenario we get OutOfMemoryException.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
