[jira] [Commented] (CASSANDRA-16944) Single partition reads can read more SSTables than required
[
https://issues.apache.org/jira/browse/CASSANDRA-16944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17414213#comment-17414213
]
Benjamin Lerer commented on CASSANDRA-16944:
[~maedhroz] Would you have some time to review those patches?
> Single partition reads can read more SSTables than required
>
>
> Key: CASSANDRA-16944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16944
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> For some scenarios involving row deletions, range deletions or static
> columns, the logic of
> {{SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder}} might
> trigger more SSTables reads that expected.
> For row deletions and range deletions the reasons is that the logic do not
> take them into account. Once we hit a deleted row (caused by a row deletion
> or a range deletion) with a timestamp higher than the one of the next SStable
> we know that we can stop reading more SSTables.
> For static columns the problems seems to have been introduced by the changes
> in CASSANDRA-16671.
--
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-16944) Single partition reads can read more SSTables than required
[
https://issues.apache.org/jira/browse/CASSANDRA-16944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16944:
---
Test and Documentation Plan: The patches add new unit tests and distributed
tests. It also update existing unit tests.
Status: Patch Available (was: In Progress)
|| Branche || CI ||
| [3.0|https://github.com/apache/cassandra/pull/1200] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra?branch=CASSANDRA-16944-3.0]
|
| [3.11|https://github.com/apache/cassandra/pull/1198] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/207/workflows/cc17987b-b70f-433b-b005-3a9bb2705363]
|
| [4.0|https://github.com/apache/cassandra/pull/1199]
|[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/208/workflows/c2224be7-d0ab-4b4a-af9e-48c25cb1849b],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/208/workflows/d3a6c41c-152f-4a4b-8327-7ffe7e12e71e]
|
The 3.0 patch unit tests slightly differ from the other branches as the 3.0
require the static columns to always be read even if they are not queried.
The 4.0 patch logic handle range deletion in a different way than the other
branches due to CASSANDRA-15369 that modified the logic in the 4.0 branch.
> Single partition reads can read more SSTables than required
>
>
> Key: CASSANDRA-16944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16944
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> For some scenarios involving row deletions, range deletions or static
> columns, the logic of
> {{SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder}} might
> trigger more SSTables reads that expected.
> For row deletions and range deletions the reasons is that the logic do not
> take them into account. Once we hit a deleted row (caused by a row deletion
> or a range deletion) with a timestamp higher than the one of the next SStable
> we know that we can stop reading more SSTables.
> For static columns the problems seems to have been introduced by the changes
> in CASSANDRA-16671.
--
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-16944) Single partition reads can read more SSTables than required
[
https://issues.apache.org/jira/browse/CASSANDRA-16944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16944:
---
Bug Category: Parent values: Code(13163)
Complexity: Normal
Discovered By: Code Inspection
Fix Version/s: 4.0.x
3.11.x
3.0.x
Severity: Low
Status: Open (was: Triage Needed)
> Single partition reads can read more SSTables than required
>
>
> Key: CASSANDRA-16944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16944
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> For some scenarios involving row deletions, range deletions or static
> columns, the logic of
> {{SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder}} might
> trigger more SSTables reads that expected.
> For row deletions and range deletions the reasons is that the logic do not
> take them into account. Once we hit a deleted row (caused by a row deletion
> or a range deletion) with a timestamp higher than the one of the next SStable
> we know that we can stop reading more SSTables.
> For static columns the problems seems to have been introduced by the changes
> in CASSANDRA-16671.
--
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-16944) Single partition reads can read more SSTables than required
Benjamin Lerer created CASSANDRA-16944:
--
Summary: Single partition reads can read more SSTables than
required
Key: CASSANDRA-16944
URL: https://issues.apache.org/jira/browse/CASSANDRA-16944
Project: Cassandra
Issue Type: Bug
Components: Legacy/Local Write-Read Paths
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
For some scenarios involving row deletions, range deletions or static columns,
the logic of
{{SinglePartitionReadCommand.queryMemtableAndSSTablesInTimestampOrder}} might
trigger more SSTables reads that expected.
For row deletions and range deletions the reasons is that the logic do not take
them into account. Once we hit a deleted row (caused by a row deletion or a
range deletion) with a timestamp higher than the one of the next SStable we
know that we can stop reading more SSTables.
For static columns the problems seems to have been introduced by the changes in
CASSANDRA-16671.
--
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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16806:
---
Status: Review In Progress (was: Needs Committer)
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413044#comment-17413044
]
Benjamin Lerer commented on CASSANDRA-16806:
[~stefan.miklosovic] In my opinion the patch should be ready. I just want to
give it a last look + run CI before committing it.
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14752:
---
Reviewers: Benjamin Lerer, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16886) Reduce native_transport_max_frame_size_in_mb
[ https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412569#comment-17412569 ] Benjamin Lerer commented on CASSANDRA-16886: The patch looks good to me. > Reduce native_transport_max_frame_size_in_mb > > > Key: CASSANDRA-16886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16886 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > There is really no point in having this set to 256MB when the commitlog > segment size defaults to 32MB, effectively capping the largest insertable > mutation to 16MB. > The native transport can provide a good first line of defense against large > mutations that would otherwise hit the heap if left to be rejected by the > commitlog. -- 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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411897#comment-17411897
]
Benjamin Lerer edited comment on CASSANDRA-16806 at 9/8/21, 12:26 PM:
--
{quote}Firing an exception with the message DELETE statements must restrict all
PRIMARY KEY columns with equality relations in order to use IF condition on non
static columns when it is not supported by the table seems a bit weird to
me.{quote}
Sorry, for the confusion. What is not supported on Virtual tables is
conditional updates/deletions. Static columns are. We just do not have any
virtual tables that use them so far.
[~cnlwsu] We are looking for a second reviewer. Would you have the time for it?
The PR is [here|https://github.com/apache/cassandra/pull/1117]
was (Author: blerer):
{quote}Firing an exception with the message DELETE statements must restrict all
PRIMARY KEY columns with equality relations in order to use IF condition on non
static columns when it is not supported by the table seems a bit weird to
me.{quote}
Sorry, for the confusion. What is not supported on Virtual tables is
conditional updates/deletions. Static columns are. We just do not have any
virtual tables that use them so far.
[~cnlwsu] We are looking for a second reviewer. Would you have the time for it?
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411897#comment-17411897
]
Benjamin Lerer commented on CASSANDRA-16806:
{quote}Firing an exception with the message DELETE statements must restrict all
PRIMARY KEY columns with equality relations in order to use IF condition on non
static columns when it is not supported by the table seems a bit weird to
me.{quote}
Sorry, for the confusion. What is not supported on Virtual tables is
conditional updates/deletions. Static columns are. We just do not have any
virtual tables that use them so far.
[~cnlwsu] We are looking for a second reviewer. Would you have the time for it?
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16806:
---
Status: Needs Committer (was: Patch Available)
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16806:
---
Status: Patch Available (was: In Progress)
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-11479) BatchlogManager unit tests failing on truncate race condition
[ https://issues.apache.org/jira/browse/CASSANDRA-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-11479: --- Resolution: Cannot Reproduce Status: Resolved (was: Open) > BatchlogManager unit tests failing on truncate race condition > - > > Key: CASSANDRA-11479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11479 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Joel Knighton >Assignee: Yuki Morishita >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x > > Attachments: > TEST-org.apache.cassandra.batchlog.BatchlogManagerTest.log > > > Example on CI > [here|http://cassci.datastax.com/job/trunk_testall/818/testReport/junit/org.apache.cassandra.batchlog/BatchlogManagerTest/testLegacyReplay_compression/]. > This seems to have only started happening relatively recently (within the > last month or two). > As far as I can tell, this is only showing up on BatchlogManagerTests purely > because it is an aggressive user of truncate. The assertion is hit in the > setUp method, so it can happen before any of the test methods. The assertion > occurs because a compaction is happening when truncate wants to discard > SSTables; trace level logs suggest that this compaction is submitted after > the pause on the CompactionStrategyManager. > This should be reproducible by running BatchlogManagerTest in a loop - it > takes up to half an hour in my experience. A trace-level log from such a run > is attached - grep for my added log message "SSTABLES COMPACTING WHEN > DISCARDING" to find when the assert is hit. -- 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-11479) BatchlogManager unit tests failing on truncate race condition
[ https://issues.apache.org/jira/browse/CASSANDRA-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-11479: --- Status: Open (was: Patch Available) > BatchlogManager unit tests failing on truncate race condition > - > > Key: CASSANDRA-11479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11479 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Joel Knighton >Assignee: Yuki Morishita >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x > > Attachments: > TEST-org.apache.cassandra.batchlog.BatchlogManagerTest.log > > > Example on CI > [here|http://cassci.datastax.com/job/trunk_testall/818/testReport/junit/org.apache.cassandra.batchlog/BatchlogManagerTest/testLegacyReplay_compression/]. > This seems to have only started happening relatively recently (within the > last month or two). > As far as I can tell, this is only showing up on BatchlogManagerTests purely > because it is an aggressive user of truncate. The assertion is hit in the > setUp method, so it can happen before any of the test methods. The assertion > occurs because a compaction is happening when truncate wants to discard > SSTables; trace level logs suggest that this compaction is submitted after > the pause on the CompactionStrategyManager. > This should be reproducible by running BatchlogManagerTest in a loop - it > takes up to half an hour in my experience. A trace-level log from such a run > is attached - grep for my added log message "SSTABLES COMPACTING WHEN > DISCARDING" to find when the assert is hit. -- 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-11479) BatchlogManager unit tests failing on truncate race condition
[ https://issues.apache.org/jira/browse/CASSANDRA-11479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411791#comment-17411791 ] Benjamin Lerer commented on CASSANDRA-11479: It does not seems to be a problem anymore. > BatchlogManager unit tests failing on truncate race condition > - > > Key: CASSANDRA-11479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11479 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Joel Knighton >Assignee: Yuki Morishita >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x > > Attachments: > TEST-org.apache.cassandra.batchlog.BatchlogManagerTest.log > > > Example on CI > [here|http://cassci.datastax.com/job/trunk_testall/818/testReport/junit/org.apache.cassandra.batchlog/BatchlogManagerTest/testLegacyReplay_compression/]. > This seems to have only started happening relatively recently (within the > last month or two). > As far as I can tell, this is only showing up on BatchlogManagerTests purely > because it is an aggressive user of truncate. The assertion is hit in the > setUp method, so it can happen before any of the test methods. The assertion > occurs because a compaction is happening when truncate wants to discard > SSTables; trace level logs suggest that this compaction is submitted after > the pause on the CompactionStrategyManager. > This should be reproducible by running BatchlogManagerTest in a loop - it > takes up to half an hour in my experience. A trace-level log from such a run > is attached - grep for my added log message "SSTABLES COMPACTING WHEN > DISCARDING" to find when the assert is hit. -- 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-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator
[ https://issues.apache.org/jira/browse/CASSANDRA-15533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15533: --- Status: In Progress (was: Patch Available) > Don't allocate unneeded MergeIterator in OnDiskToken#iterator > -- > > Key: CASSANDRA-15533 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15533 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SASI >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.x > > > When reviewing CASSANDRA-15392 it became apparent that the MergeIterator > allocated by OnDiskToken#iterator is rarely necessary and so we should avoid > allocating one when not needed and skip the MergeIterator pool when needed > because its unlikely to be sized correctly. -- 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-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator
[
https://issues.apache.org/jira/browse/CASSANDRA-15533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411790#comment-17411790
]
Benjamin Lerer commented on CASSANDRA-15533:
The patch does not apply cleanly anymore and need to be updated.
Moving back the ticket to {{IN PROGRESS}}
> Don't allocate unneeded MergeIterator in OnDiskToken#iterator
> --
>
> Key: CASSANDRA-15533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15533
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SASI
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.x
>
>
> When reviewing CASSANDRA-15392 it became apparent that the MergeIterator
> allocated by OnDiskToken#iterator is rarely necessary and so we should avoid
> allocating one when not needed and skip the MergeIterator pool when needed
> because its unlikely to be sized correctly.
--
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-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411767#comment-17411767
]
Benjamin Lerer commented on CASSANDRA-11323:
{quote}I am not sure how merge markers were both introduced and removed in this
PR{quote}
Sorry, I forgot to squash my commits.
CI runs for
[3.11|https://app.circleci.com/pipelines/github/blerer/cassandra?branch=CASSANDRA-11323-3.11-REVIEW]
and
[4.0|https://app.circleci.com/pipelines/github/blerer/cassandra?branch=CASSANDRA-11323-4.0-REVIEW]
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Low
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.0.txt,
> 11323-3.11.txt, 11323-3.11.txt, 11323-trunk.txt, 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
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-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411762#comment-17411762
]
Benjamin Lerer commented on CASSANDRA-14344:
[~n.v.harikrishna] Thanks a lot for the patch and sorry it took so long for it
to be committed.
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.1
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
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-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14344:
---
Fix Version/s: (was: 4.x)
4.1
Source Control Link:
https://github.com/apache/cassandra/commit/dcee430e57f3fd37e4bc6652ad7180361e31444e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into trunk at dcee430e57f3fd37e4bc6652ad7180361e31444e
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.1
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
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-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14344:
---
Status: Ready to Commit (was: Review In Progress)
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
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-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-12988:
---
Status: Review In Progress (was: Patch Available)
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-12988:
---
Reviewers: Benjamin Lerer (was: Robert Stupp)
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16886) Reduce native_transport_max_frame_size_in_mb
[
https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411413#comment-17411413
]
Benjamin Lerer edited comment on CASSANDRA-16886 at 9/8/21, 6:51 AM:
-
{quote}I can switch to ByteUnit here if you prefer{quote}
Yes, I would prefer. Thanks :-)
was (Author: blerer):
{quote}I can switch to ByteUnit here if you prefer{quote}
Yes, it would prefer. Thanks :-)
> Reduce native_transport_max_frame_size_in_mb
>
>
> Key: CASSANDRA-16886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16886
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> There is really no point in having this set to 256MB when the commitlog
> segment size defaults to 32MB, effectively capping the largest insertable
> mutation to 16MB.
> The native transport can provide a good first line of defense against large
> mutations that would otherwise hit the heap if left to be rejected by the
> commitlog.
--
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-16886) Reduce native_transport_max_frame_size_in_mb
[
https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411413#comment-17411413
]
Benjamin Lerer commented on CASSANDRA-16886:
{quote}I can switch to ByteUnit here if you prefer{quote}
Yes, it would prefer. Thanks :-)
> Reduce native_transport_max_frame_size_in_mb
>
>
> Key: CASSANDRA-16886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16886
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> There is really no point in having this set to 256MB when the commitlog
> segment size defaults to 32MB, effectively capping the largest insertable
> mutation to 16MB.
> The native transport can provide a good first line of defense against large
> mutations that would otherwise hit the heap if left to be rejected by the
> commitlog.
--
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-15975) SEP.shutdownAndWait does not wait for termination and SEPExecutor.awaitTermination may hang
[ https://issues.apache.org/jira/browse/CASSANDRA-15975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411272#comment-17411272 ] Benjamin Lerer commented on CASSANDRA-15975: [~jmeredithco] This ticket look ready to commit. Anything blocking you ? > SEP.shutdownAndWait does not wait for termination and > SEPExecutor.awaitTermination may hang > --- > > Key: CASSANDRA-15975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15975 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > > SharedExecutorPool.shutdownAndWait calls shutdownNow on the executors it > owns, which has the side effect of removing the executor from the list, then > uses the same emptied list to try and wait for them to complete shutting > down, which completes immediately. > > Once fixed by copying the list in SEP.shutdownAndWait, the SEPExecutorTest > suite fails with a timeout due to a startup race in SEPWorker. > > If a SEPExecutor is shutdown immediately after maybeSchedule creates a new > SEPWorker, > but before it is able to execute the first task then it exits immediately on > entering the work loop with a work and task permit reserved for it, which > invalidates the work/task permit accounting and prevents calling the shutdown > SimpleCondition.signalAll when the last SEPWorker exits. -- 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-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14344:
---
Status: Review In Progress (was: Needs Committer)
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
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-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16918:
---
Fix Version/s: (was: 4.x)
4.1
Source Control Link:
https://github.com/apache/cassandra/commit/138569b079b3d17b1020a24463adabecd903b79f
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed in trunk at 138569b079b3d17b1020a24463adabecd903b79f
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
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-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411242#comment-17411242
]
Benjamin Lerer commented on CASSANDRA-16918:
Thanks for the review.
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
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-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411216#comment-17411216
]
Benjamin Lerer commented on CASSANDRA-11323:
I had some look at the patch and I have the following comments:
* The approach to compute the commitlog dir freespace do not handle large file
system
* Logging a separate error message is confusing as the 2 error messages can end
up being separated in the log file. It is probably better in my opinion to
merge the 2 messages together when needed. That will remove the need for the
{{SpamLogger}} as the messages are always logged anyway.
The PR for the modified version on 3.0 can be found
[here|https://github.com/apache/cassandra/pull/1188] and the CI results are
[here|https://app.circleci.com/pipelines/github/blerer/cassandra/200/workflows/c62fb6ed-7bdf-42f6-9e97-aa4a5c4b738d].
[~brandon.williams] Would you mind reviewing my changes?
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Low
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.0.txt,
> 11323-3.11.txt, 11323-3.11.txt, 11323-trunk.txt, 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
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-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-11323:
---
Reviewers: Ariel Weisberg, Benjamin Lerer, Benjamin Lerer (was: Ariel
Weisberg, Benjamin Lerer)
Ariel Weisberg, Benjamin Lerer, Benjamin Lerer (was: Ariel
Weisberg)
Status: Review In Progress (was: Patch Available)
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Low
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.0.txt,
> 11323-3.11.txt, 11323-3.11.txt, 11323-trunk.txt, 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
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-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-11323:
---
Status: Patch Available (was: Ready to Commit)
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Low
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.0.txt,
> 11323-3.11.txt, 11323-3.11.txt, 11323-trunk.txt, 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
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-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-16916:
--
Assignee: Jogesh Anand
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
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-16886) Reduce native_transport_max_frame_size_in_mb
[ https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16886: --- Reviewers: Benjamin Lerer > Reduce native_transport_max_frame_size_in_mb > > > Key: CASSANDRA-16886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16886 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > There is really no point in having this set to 256MB when the commitlog > segment size defaults to 32MB, effectively capping the largest insertable > mutation to 16MB. > The native transport can provide a good first line of defense against large > mutations that would otherwise hit the heap if left to be rejected by the > commitlog. -- 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-16886) Reduce native_transport_max_frame_size_in_mb
[ https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16886: --- Status: Review In Progress (was: Patch Available) > Reduce native_transport_max_frame_size_in_mb > > > Key: CASSANDRA-16886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16886 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > There is really no point in having this set to 256MB when the commitlog > segment size defaults to 32MB, effectively capping the largest insertable > mutation to 16MB. > The native transport can provide a good first line of defense against large > mutations that would otherwise hit the heap if left to be rejected by the > commitlog. -- 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-16886) Reduce native_transport_max_frame_size_in_mb
[
https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411030#comment-17411030
]
Benjamin Lerer commented on CASSANDRA-16886:
The patch look good to me. The only nit I have is regarding the use of numeric
values for bytes to/from MB converversions.
Even if we rely on CASSANDRA-15234 to fix that later on we should probably use
{{org.apache.cassandra.io.util.FileUtils.ONE_MB}} instead of {{1048576}}. An
other optrion would be to use {{ByteUnit}} and add a {{fromBytes}} method to
it.
> Reduce native_transport_max_frame_size_in_mb
>
>
> Key: CASSANDRA-16886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16886
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> There is really no point in having this set to 256MB when the commitlog
> segment size defaults to 32MB, effectively capping the largest insertable
> mutation to 16MB.
> The native transport can provide a good first line of defense against large
> mutations that would otherwise hit the heap if left to be rejected by the
> commitlog.
--
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-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401731#comment-17401731
]
Benjamin Lerer edited comment on CASSANDRA-14344 at 9/6/21, 1:40 PM:
-
[~n.v.harikrishna] I rebased your patch and modified it a bit to allow {{IN}}
filtering on all types of columns (partition key, clustering, regular and
static columns) not only on clustering columns. I also added support for
multi-column {{IN}} restrictions with a single column. I hope it is fine with
you.
|| Branch || CircleCi ||
| [trunk|https://github.com/apache/cassandra/pull/1159] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/199/workflows/8862efff-0c6a-40a1-818c-0468db38d28b],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/199/workflows/77349b59-4baf-467f-90bc-8811b207323b]|
was (Author: blerer):
[~n.v.harikrishna] I rebased your patch and modified it a bit to allow {{IN}}
filtering on all types of columns (partition key, clustering, regular and
static columns) not only on clustering columns. I also added support for
multi-column {{IN}} restrictions with a single column. I hope it is fine with
you.
|| Branch || CircleCi ||
| [trunk|https://github.com/apache/cassandra/pull/1159] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/189/workflows/7735aea2-e12b-436e-9280-bf41d5501589],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/189/workflows/63daa4fc-e553-45f1-93bf-db5223c8b806]|
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
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-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16918:
---
Test and Documentation Plan: The change impact CQLTester and does not
require additional tests.
Status: Patch Available (was: Open)
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
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-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17410607#comment-17410607
]
Benjamin Lerer commented on CASSANDRA-16918:
|| PR || CI ||
|[trunk|https://github.com/apache/cassandra/pull/1187] |
[J8|https://app.circleci.com/pipelines/github/blerer/cassandra/198/workflows/fa37d888-dabb-4633-b747-bf39af157c90]
,
[J11|https://app.circleci.com/pipelines/github/blerer/cassandra/198/workflows/73cb131e-daf3-4f4d-9ad8-8951d5d48107]
|
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
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-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16918:
---
Change Category: Quality Assurance
Complexity: Normal
Component/s: Test/unit
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
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-16918) CQLTester open more java driver connections than required by the tests
Benjamin Lerer created CASSANDRA-16918:
--
Summary: CQLTester open more java driver connections than required
by the tests
Key: CASSANDRA-16918
URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
Project: Cassandra
Issue Type: Improvement
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
{{CQLTester}} unit test the test will open 4 connections to the server (one for
each protocol version) even if the test only require a single connection.
There are no good reasons for that behavior and the connections can simply be
opened on a lazy way.
--
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-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17410410#comment-17410410
]
Benjamin Lerer commented on CASSANDRA-15269:
{quote}I can move this forward across the finish line if you're busy somewhere
else.{quote}
It would be nice.
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-16892) Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16892: --- Status: Ready to Commit (was: Review In Progress) > Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests > --- > > Key: CASSANDRA-16892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I noticed that tests for dtest in upgrade_tests/thrift_upgrade_test.py are > flaky. > The reason this flakiness happens is that we are stopping and starting a node > too fast without waiting for its full initialisation and then next attempt to > connect to rpc port fails and whole test fails. > The fix is rather easy, we just need to wait until it is full started. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16892) Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409579#comment-17409579
]
Benjamin Lerer edited comment on CASSANDRA-16892 at 9/3/21, 3:50 PM:
-
I ran the patched {{upgrade_tests/thrift_upgrade_test.py}} using the
repeated_upgrade_dtest runner 100 times and did not get any failure. Results
are
[here|https://app.circleci.com/pipelines/github/blerer/cassandra/195/workflows/a9c26e1f-01e6-4af5-84c3-a0314c08ed59].
The fix looks good. +1
Thanks for the patch [~stefan.miklosovic]
was (Author: blerer):
I ran the patched {{upgrade_tests/thrift_upgrade_test.py}} using the
repeated_upgrade_dtest runner 100 times and did not get any failure. Results
are
[here|https://app.circleci.com/pipelines/github/blerer/cassandra/195/workflows/a9c26e1f-01e6-4af5-84c3-a0314c08ed59].
The fix looks good. +1
> Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests
> ---
>
> Key: CASSANDRA-16892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16892
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: NA
>
>
> I noticed that tests for dtest in upgrade_tests/thrift_upgrade_test.py are
> flaky.
> The reason this flakiness happens is that we are stopping and starting a node
> too fast without waiting for its full initialisation and then next attempt to
> connect to rpc port fails and whole test fails.
> The fix is rather easy, we just need to wait until it is full started.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16892) Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409579#comment-17409579
]
Benjamin Lerer commented on CASSANDRA-16892:
I ran the patched {{upgrade_tests/thrift_upgrade_test.py}} using the
repeated_upgrade_dtest runner 100 times and did not get any failure. Results
are
[here|https://app.circleci.com/pipelines/github/blerer/cassandra/195/workflows/a9c26e1f-01e6-4af5-84c3-a0314c08ed59].
The fix looks good. +1
> Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests
> ---
>
> Key: CASSANDRA-16892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16892
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: NA
>
>
> I noticed that tests for dtest in upgrade_tests/thrift_upgrade_test.py are
> flaky.
> The reason this flakiness happens is that we are stopping and starting a node
> too fast without waiting for its full initialisation and then next attempt to
> connect to rpc port fails and whole test fails.
> The fix is rather easy, we just need to wait until it is full started.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409575#comment-17409575
]
Benjamin Lerer commented on CASSANDRA-16916:
[~djanand] I understood that you were interested in working on low-hanging
fruits ticket. This one might be interesting for you. If you have some
questions do not hesitate to ping me.
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
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-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16916:
---
Change Category: Semantic
Complexity: Low Hanging Fruit
Status: Open (was: Triage Needed)
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
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-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
Benjamin Lerer created CASSANDRA-16916:
--
Summary: Add support for IF EXISTS and IF NOT EXISTS in ALTER
statements
Key: CASSANDRA-16916
URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
Project: Cassandra
Issue Type: Improvement
Components: CQL/Syntax
Reporter: Benjamin Lerer
It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
the different {{ALTER}} statements.
For example:
* {{ALTER TABLE IF EXISTS myTable ...}}
* {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
* {{ALTER TABLE myTable DROP IF EXISTS ...}}
* {{ALTER TYPE IF EXISTS myType ...}}
* {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
+Additional info for newcomers:+
In order to implement this change you will need to change the {{Parser.g}}
ANTLR file located in the src/antlr directory and the java classes
corresponding to the different alter statements located in the
{{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
CreateTableStatement class to see how it was done there.
The unit test for the CQL logic are located under
{{org.apache.cassandra.cql3.validation}}
--
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-16892) Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16892: --- Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer) Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer) Status: Review In Progress (was: Patch Available) > Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests > --- > > Key: CASSANDRA-16892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I noticed that tests for dtest in upgrade_tests/thrift_upgrade_test.py are > flaky. > The reason this flakiness happens is that we are stopping and starting a node > too fast without waiting for its full initialisation and then next attempt to > connect to rpc port fails and whole test fails. > The fix is rather easy, we just need to wait until it is full started. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16790) Add auto_snapshot_ttl configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-16790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409391#comment-17409391
]
Benjamin Lerer commented on CASSANDRA-16790:
[~stefan.miklosovic] we need a second reviewer for this ticket. Would you have
some time for it?
> Add auto_snapshot_ttl configuration
> ---
>
> Key: CASSANDRA-16790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16790
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Config
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> This property should take a human readable parameter (ie. 6h, 3days). When
> specified and {{auto_snapshot: true}}, auto snapshots created should use the
> specified TTL.
--
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-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409352#comment-17409352
]
Benjamin Lerer commented on CASSANDRA-15269:
Sorry, I realize that my commit description was confusing. The
{{ClassCastException}} is happening on the server NOT on the driver side but it
is occuring while the sever serialize the message to the driver. The new unit
test check exactly the code path that was leading to the
{{ClassCastException}} .
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-12734) Materialized View schema file for snapshots created as tables
[ https://issues.apache.org/jira/browse/CASSANDRA-12734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409354#comment-17409354 ] Benjamin Lerer commented on CASSANDRA-12734: The patches look good to me. Thanks :-) > Materialized View schema file for snapshots created as tables > - > > Key: CASSANDRA-12734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12734 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Tools >Reporter: Hau Phan >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > The materialized view schema file that gets created and stored with the > sstables is created as a table instead of a materialized view. > Can the materialized view be created and added to the corresponding table's > schema file? -- 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-12734) Materialized View schema file for snapshots created as tables
[ https://issues.apache.org/jira/browse/CASSANDRA-12734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-12734: --- Status: Ready to Commit (was: Review In Progress) > Materialized View schema file for snapshots created as tables > - > > Key: CASSANDRA-12734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12734 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Tools >Reporter: Hau Phan >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > The materialized view schema file that gets created and stored with the > sstables is created as a table instead of a materialized view. > Can the materialized view be created and added to the corresponding table's > schema file? -- 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-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409325#comment-17409325
]
Benjamin Lerer commented on CASSANDRA-15269:
The old PR was relying on a hack for testing the fix. The new PR unit reproduce
the scenario that lead to the {{ClassCastException}} without relying on any
hack.
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408823#comment-17408823
]
Benjamin Lerer commented on CASSANDRA-16806:
{quote}restrictions for static columns, secondary indexes and materialized
views (at least need to check that they exist, I found none of them){quote}
It is not possible to create index or Materialized view on Virtual table. It is
ensured by the fact that virtual keyspaces are not user modifiable.
I do not think that there are any reason to restrict static columns. Why do you
want to do it?
{quote}support for complex type cell deletes{quote}
I am not sure that we need that for the moment as we have not been using
complex columns in virtual tables for now.
We can implement that the day were we will have this need.
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408670#comment-17408670
]
Benjamin Lerer commented on CASSANDRA-15269:
[~bereng] Sorry, for the delay. There are a simple way to trigger the
{{ClassCastException}} without changing anything to the code.
I pushed a new version of the patch
[here|https://github.com/apache/cassandra/commit/473e67199eb29f831000782ab25cdf56629af1c8].
CI results:
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/191/workflows/d85e9e9f-7b7e-4d4b-83d2-53a6515a7c50]
and
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/191/workflows/4b73dbbb-1451-426e-8217-0af2fef0bf55]
Tell me if the changes look good to you.
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15269:
---
Reviewers: Benjamin Lerer, Sam Tunnicliffe (was: Sam Tunnicliffe)
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-16894) Java 11 support - remove the experimental flag
[ https://issues.apache.org/jira/browse/CASSANDRA-16894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16894: --- Reviewers: Michael Semb Wever > Java 11 support - remove the experimental flag > -- > > Key: CASSANDRA-16894 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16894 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > > As per this [thread. > |https://lists.apache.org/thread.html/r06a4768bae215dc19469491a1faec64dd90e1c3d4d10ed34b85ba248%40%3Cdev.cassandra.apache.org%3E]the > goal of this ticket is to remove the experimental flag for Java 11 support. > -- 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-16894) Java 11 support - remove the experimental flag
[ https://issues.apache.org/jira/browse/CASSANDRA-16894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16894: --- Status: Review In Progress (was: Patch Available) > Java 11 support - remove the experimental flag > -- > > Key: CASSANDRA-16894 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16894 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x > > > As per this [thread. > |https://lists.apache.org/thread.html/r06a4768bae215dc19469491a1faec64dd90e1c3d4d10ed34b85ba248%40%3Cdev.cassandra.apache.org%3E]the > goal of this ticket is to remove the experimental flag for Java 11 support. > -- 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-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-13874: --- Status: Ready to Commit (was: Review In Progress) > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Berenguer Blasi >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- 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-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-13874: --- Reviewers: Benjamin Lerer, Berenguer Blasi (was: Benjamin Lerer, Berenguer Blasi, Jon Haddad) > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Berenguer Blasi >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- 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-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-13874: --- Reviewers: Benjamin Lerer, Berenguer Blasi, Jon Haddad, Benjamin Lerer (was: Benjamin Lerer, Berenguer Blasi, Jon Haddad) Benjamin Lerer, Berenguer Blasi, Jon Haddad, Benjamin Lerer (was: Benjamin Lerer, Berenguer Blasi, Jon Haddad) Status: Review In Progress (was: Patch Available) > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Berenguer Blasi >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- 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-12734) Materialized View schema file for snapshots created as tables
[ https://issues.apache.org/jira/browse/CASSANDRA-12734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-12734: --- Test and Documentation Plan: The patches add additional unit tests Status: Patch Available (was: In Progress) > Materialized View schema file for snapshots created as tables > - > > Key: CASSANDRA-12734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12734 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Tools >Reporter: Hau Phan >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > The materialized view schema file that gets created and stored with the > sstables is created as a table instead of a materialized view. > Can the materialized view be created and added to the corresponding table's > schema file? -- 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-12734) Materialized View schema file for snapshots created as tables
[ https://issues.apache.org/jira/browse/CASSANDRA-12734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-12734: --- Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer) Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer) Status: Review In Progress (was: Patch Available) > Materialized View schema file for snapshots created as tables > - > > Key: CASSANDRA-12734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12734 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Tools >Reporter: Hau Phan >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > The materialized view schema file that gets created and stored with the > sstables is created as a table instead of a materialized view. > Can the materialized view be created and added to the corresponding table's > schema file? -- 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-12734) Materialized View schema file for snapshots created as tables
[ https://issues.apache.org/jira/browse/CASSANDRA-12734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408121#comment-17408121 ] Benjamin Lerer commented on CASSANDRA-12734: The underlying issue on 4.0 is now fixed (see CASSANDRA-16898). The patch for 3.0 and 3.11 LGTM. We probably just need to make a patch for 4.0 and trunk with only the unit tests. > Materialized View schema file for snapshots created as tables > - > > Key: CASSANDRA-12734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12734 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Tools >Reporter: Hau Phan >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > The materialized view schema file that gets created and stored with the > sstables is created as a table instead of a materialized view. > Can the materialized view be created and added to the corresponding table's > schema file? -- 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-16898) The clustering order logic in Materialized view creation changed in 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16898:
---
Fix Version/s: (was: 4.0.x)
4.0.2
Since Version: 4.0-rc1
Source Control Link:
https://github.com/apache/cassandra/commit/af17f136e58910fa23f1b8c6b8f13de62787e823
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into cassandra-4.0 at af17f136e58910fa23f1b8c6b8f13de62787e823 and
merged into trunk
> The clustering order logic in Materialized view creation changed in 4.0
> ---
>
> Key: CASSANDRA-16898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16898
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.2
>
>
> Before 4.0, when a Materialized view was created with no {{CLUSTERING ORDER}}
> specified the clustering order was based on the base table clustering order
> (see [3.11
> code|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L108]).
> In 4.0 this behaviour changed and the clustering order was defaulted to ASC
> for all columns.
--
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-16902) A user should be able to view permissions of role they created
[
https://issues.apache.org/jira/browse/CASSANDRA-16902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16902:
---
Reviewers: Benjamin Lerer
> A user should be able to view permissions of role they created
> --
>
> Key: CASSANDRA-16902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16902
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Currently users are denied to view permissions to see a role they created:
> {code}
> CREATE ROLE parent WITH PASSWORD = 'x' AND LOGIN = true;
> GRANT CREATE ON ALL ROLES TO parent;
> LOGIN parent;
> CREATE ROLE child WITH PASSWORD = 'x' AND LOGIN = true;
> LIST ALL PERMISSIONS OF 'child'; -- You are not authorized to view child's
> permissions
> {code}
> When a user creates a role they should get the {{DESCRIBE}} permission on
> that role by default.
--
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-12734) Materialized View schema file for snapshots created as tables
[ https://issues.apache.org/jira/browse/CASSANDRA-12734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-12734: --- Reviewers: Benjamin Lerer > Materialized View schema file for snapshots created as tables > - > > Key: CASSANDRA-12734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12734 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Tools >Reporter: Hau Phan >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > The materialized view schema file that gets created and stored with the > sstables is created as a table instead of a materialized view. > Can the materialized view be created and added to the corresponding table's > schema file? -- 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-16898) The clustering order logic in Materialized view creation changed in 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16898:
---
Test and Documentation Plan: The patch add additional unit tests
Status: Patch Available (was: Open)
> The clustering order logic in Materialized view creation changed in 4.0
> ---
>
> Key: CASSANDRA-16898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16898
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.x
>
>
> Before 4.0, when a Materialized view was created with no {{CLUSTERING ORDER}}
> specified the clustering order was based on the base table clustering order
> (see [3.11
> code|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L108]).
> In 4.0 this behaviour changed and the clustering order was defaulted to ASC
> for all columns.
--
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-16898) The clustering order logic in Materialized view creation changed in 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16898:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Discovered By: Unit Test
Fix Version/s: 4.0.x
Severity: Low
Status: Open (was: Triage Needed)
> The clustering order logic in Materialized view creation changed in 4.0
> ---
>
> Key: CASSANDRA-16898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16898
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.x
>
>
> Before 4.0, when a Materialized view was created with no {{CLUSTERING ORDER}}
> specified the clustering order was based on the base table clustering order
> (see [3.11
> code|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L108]).
> In 4.0 this behaviour changed and the clustering order was defaulted to ASC
> for all columns.
--
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-16898) The clustering order logic in Materialized view creation changed in 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406771#comment-17406771
]
Benjamin Lerer commented on CASSANDRA-16898:
|| Branch || CI ||
| [PR|https://github.com/apache/cassandra/pull/1175] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/190/workflows/e5f4d1a7-4c7c-43ff-a20b-111ca209e3cb]
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/190/workflows/9c18ded2-e9fe-497c-acb2-bc565e45dc5e]
|
> The clustering order logic in Materialized view creation changed in 4.0
> ---
>
> Key: CASSANDRA-16898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16898
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> Before 4.0, when a Materialized view was created with no {{CLUSTERING ORDER}}
> specified the clustering order was based on the base table clustering order
> (see [3.11
> code|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L108]).
> In 4.0 this behaviour changed and the clustering order was defaulted to ASC
> for all columns.
--
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-16898) The clustering order logic in Materialized view creation changed in 4.0
Benjamin Lerer created CASSANDRA-16898:
--
Summary: The clustering order logic in Materialized view creation
changed in 4.0
Key: CASSANDRA-16898
URL: https://issues.apache.org/jira/browse/CASSANDRA-16898
Project: Cassandra
Issue Type: Bug
Components: Feature/Materialized Views
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
Before 4.0, when a Materialized view was created with no {{CLUSTERING ORDER}}
specified the clustering order was based on the base table clustering order
see[3.11
code|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L108].
In 4.0 this behaviour changed and the clustering order was defaulted to ASC
for all columns.
--
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-16898) The clustering order logic in Materialized view creation changed in 4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16898:
---
Description: Before 4.0, when a Materialized view was created with no
{{CLUSTERING ORDER}} specified the clustering order was based on the base table
clustering order (see [3.11
code|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L108]).
In 4.0 this behaviour changed and the clustering order was defaulted to ASC
for all columns. (was: Before 4.0, when a Materialized view was created with
no {{CLUSTERING ORDER}} specified the clustering order was based on the base
table clustering order see[3.11
code|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L108].
In 4.0 this behaviour changed and the clustering order was defaulted to ASC
for all columns. )
> The clustering order logic in Materialized view creation changed in 4.0
> ---
>
> Key: CASSANDRA-16898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16898
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> Before 4.0, when a Materialized view was created with no {{CLUSTERING ORDER}}
> specified the clustering order was based on the base table clustering order
> (see [3.11
> code|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L108]).
> In 4.0 this behaviour changed and the clustering order was defaulted to ASC
> for all columns.
--
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-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406640#comment-17406640 ] Benjamin Lerer commented on CASSANDRA-13874: Thanks [~bereng]. Your fix look good to me. > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Michal Szczepanski >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- 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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406593#comment-17406593
]
Benjamin Lerer commented on CASSANDRA-16806:
It is clearly an oversight. Thank for spotting that. :-)
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-16892) Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-16892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16892: --- Reviewers: Benjamin Lerer > Fix flakiness in upgrade_tests/thrift_upgrade_test.py in dtests > --- > > Key: CASSANDRA-16892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: NA > > > I noticed that tests for dtest in upgrade_tests/thrift_upgrade_test.py are > flaky. > The reason this flakiness happens is that we are stopping and starting a node > too fast without waiting for its full initialisation and then next attempt to > connect to rpc port fails and whole test fails. > The fix is rather easy, we just need to wait until it is full started. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405692#comment-17405692
]
Benjamin Lerer commented on CASSANDRA-16806:
[~azotcsit] The current design of {{VirtualTable}} allow the person
implementing it to easily convert its internal data (that are usually String
and Numbers) into some Partitions and Rows through the use of a
{{SimpleDataSet}}. The current code of {{AbstractWritableVirtualTable}} is good
but force every person implementing it to have to deal with the conversion from
the Cassandra objects to some internal data. An example of it is the unit test
where a big part of the new code is conversion code. It would be nice if the
patch could provide that conversion layer, in a similar way to what was done
with {{SimpleDataSet}}.
What do you think?
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-12734) Materialized View schema file for snapshots created as tables
[ https://issues.apache.org/jira/browse/CASSANDRA-12734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404277#comment-17404277 ] Benjamin Lerer commented on CASSANDRA-12734: [~e.dimitrova] I ran some tests on 4.0 and hit another issue related to DESCRIBE. I need to dig a deeper. > Materialized View schema file for snapshots created as tables > - > > Key: CASSANDRA-12734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12734 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Tools >Reporter: Hau Phan >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > The materialized view schema file that gets created and stored with the > sstables is created as a table instead of a materialized view. > Can the materialized view be created and added to the corresponding table's > schema file? -- 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-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403907#comment-17403907
]
Benjamin Lerer commented on CASSANDRA-16806:
[~azotcsit] I had a look at your changes and I need to think a bit about them.
I have forgotten a bit that part of the code and need to refresh my memory. I
will be back to you as soon as I can.
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
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-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402259#comment-17402259 ] Benjamin Lerer commented on CASSANDRA-15297: [~maxwellguo] The fix look good but there is no test for it. Would you mind adding a nodetool test for that scenario? > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- 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-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15297: --- Reviewers: Chris Lohfink, Benjamin Lerer (was: Benjamin Lerer, Chris Lohfink) Chris Lohfink, Benjamin Lerer (was: Chris Lohfink) Status: Review In Progress (was: Patch Available) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- 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-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15297: --- Status: Patch Available (was: Ready to Commit) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- 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-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-13874: --- Status: Open (was: Patch Available) > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Michal Szczepanski >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- 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-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402258#comment-17402258 ] Benjamin Lerer commented on CASSANDRA-13874: Moving the patch to open. > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Michal Szczepanski >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- 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-13874) nodetool setcachecapacity behaves oddly when cache disabled
[ https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-13874: --- Reviewers: Benjamin Lerer, Berenguer Blasi, Jon Haddad (was: Berenguer Blasi, Jon Haddad) > nodetool setcachecapacity behaves oddly when cache disabled > --- > > Key: CASSANDRA-13874 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13874 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Local/Config >Reporter: Jon Haddad >Assignee: Michal Szczepanski >Priority: Low > Labels: lhf, user-experience > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: 13874-trunk.txt > > > If a node has row cache disabled, trying to turn it on via setcachecapacity > doesn't issue an error, and doesn't turn it on, it just silently doesn't work. -- 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-13874) nodetool setcachecapacity behaves oddly when cache disabled
[
https://issues.apache.org/jira/browse/CASSANDRA-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402257#comment-17402257
]
Benjamin Lerer commented on CASSANDRA-13874:
The ticket is about the behavior of nodetool when we call {{setcachecapacity}}
on a disabled cache. By consequence, I think it will be good to also have a
nodetool test that check that scenario.
> nodetool setcachecapacity behaves oddly when cache disabled
> ---
>
> Key: CASSANDRA-13874
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13874
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Config
>Reporter: Jon Haddad
>Assignee: Michal Szczepanski
>Priority: Low
> Labels: lhf, user-experience
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Attachments: 13874-trunk.txt
>
>
> If a node has row cache disabled, trying to turn it on via setcachecapacity
> doesn't issue an error, and doesn't turn it on, it just silently doesn't work.
--
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-16868) Secondary indexes on primary key columns can miss some writes
[
https://issues.apache.org/jira/browse/CASSANDRA-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402242#comment-17402242
]
Benjamin Lerer commented on CASSANDRA-16868:
Thanks for all the extra testing :-). The patches look good.
> Secondary indexes on primary key columns can miss some writes
> -
>
> Key: CASSANDRA-16868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16868
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Secondary indexes on primary key columns can miss some writes. For example,
> an update after a deletion won't create an index entry:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> INSERT INTO t(pk, ck, v) VALUES (1, 2, 3); -- creates an index entry (right)
> DELETE FROM t WHERE pk = 1 AND ck = 2; -- deletes the previous index entry
> (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create a new index
> entry (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> This happens because the update uses the {{LivenssInfo}} of the previously
> deleted row (see
> [here|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L439]).
> The same happens when updating an expired row:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> UPDATE t USING TTL 1 SET v = 3 WHERE pk = 1 AND ck = 2; -- creates a
> non-expiring index entry (right)
> -- wait for the expiration of the above row
> SELECT * FROM t WHERE ck = 2; -- deletes the index entry (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create an index entry
> (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> I think that the fix for this is just using the
> {{getPrimaryKeyIndexLiveness}} in {{updateRow}}, as it's used in
> {{insertRow}}.
> Another related problem is that {{getPrimaryKeyIndexLiveness}} uses [the most
> recent TTL in the columns contained on the indexed row
> fragment|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L519]
> as the TTL of the index entry, producing an expiring index entry that
> ignores the columns without TTL that are already present in flushed sstables.
> So we can find this other error when setting a TTL over flushed indexed data:
> {code:java}
> CREATE TABLE t(k1 int, k2 int, v int, PRIMARY KEY ((k1, k2)));
> CREATE INDEX idx ON t(k1);
> INSERT INTO t (k1, k2, v) VALUES (1, 2, 3);
> -- flush
> UPDATE t USING TTL 1 SET v=0 WHERE k1=1 AND k2=2; -- creates an index entry
> with TTL (wrong)
> -- wait for TTL expiration
> SELECT TTL(v) FROM t WHERE k1=1; -- doesn't find the row (wrong)
> {code}
> The straightforward fix is just ignoring the TTL of the columns for indexes
> on primary key components, so we don't produce expiring index entries in that
> case. The index entries will be eventually deleted during index reads, when
> we are sure that they are not pointing to any live data.
>
--
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-16868) Secondary indexes on primary key columns can miss some writes
[
https://issues.apache.org/jira/browse/CASSANDRA-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16868:
---
Status: Ready to Commit (was: Review In Progress)
> Secondary indexes on primary key columns can miss some writes
> -
>
> Key: CASSANDRA-16868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16868
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Secondary indexes on primary key columns can miss some writes. For example,
> an update after a deletion won't create an index entry:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> INSERT INTO t(pk, ck, v) VALUES (1, 2, 3); -- creates an index entry (right)
> DELETE FROM t WHERE pk = 1 AND ck = 2; -- deletes the previous index entry
> (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create a new index
> entry (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> This happens because the update uses the {{LivenssInfo}} of the previously
> deleted row (see
> [here|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L439]).
> The same happens when updating an expired row:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> UPDATE t USING TTL 1 SET v = 3 WHERE pk = 1 AND ck = 2; -- creates a
> non-expiring index entry (right)
> -- wait for the expiration of the above row
> SELECT * FROM t WHERE ck = 2; -- deletes the index entry (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create an index entry
> (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> I think that the fix for this is just using the
> {{getPrimaryKeyIndexLiveness}} in {{updateRow}}, as it's used in
> {{insertRow}}.
> Another related problem is that {{getPrimaryKeyIndexLiveness}} uses [the most
> recent TTL in the columns contained on the indexed row
> fragment|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L519]
> as the TTL of the index entry, producing an expiring index entry that
> ignores the columns without TTL that are already present in flushed sstables.
> So we can find this other error when setting a TTL over flushed indexed data:
> {code:java}
> CREATE TABLE t(k1 int, k2 int, v int, PRIMARY KEY ((k1, k2)));
> CREATE INDEX idx ON t(k1);
> INSERT INTO t (k1, k2, v) VALUES (1, 2, 3);
> -- flush
> UPDATE t USING TTL 1 SET v=0 WHERE k1=1 AND k2=2; -- creates an index entry
> with TTL (wrong)
> -- wait for TTL expiration
> SELECT TTL(v) FROM t WHERE k1=1; -- doesn't find the row (wrong)
> {code}
> The straightforward fix is just ignoring the TTL of the columns for indexes
> on primary key components, so we don't produce expiring index entries in that
> case. The index entries will be eventually deleted during index reads, when
> we are sure that they are not pointing to any live data.
>
--
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-16868) Secondary indexes on primary key columns can miss some writes
[
https://issues.apache.org/jira/browse/CASSANDRA-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16868:
---
Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Benjamin Lerer, Benjamin Lerer
Status: Review In Progress (was: Patch Available)
> Secondary indexes on primary key columns can miss some writes
> -
>
> Key: CASSANDRA-16868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16868
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Secondary indexes on primary key columns can miss some writes. For example,
> an update after a deletion won't create an index entry:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> INSERT INTO t(pk, ck, v) VALUES (1, 2, 3); -- creates an index entry (right)
> DELETE FROM t WHERE pk = 1 AND ck = 2; -- deletes the previous index entry
> (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create a new index
> entry (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> This happens because the update uses the {{LivenssInfo}} of the previously
> deleted row (see
> [here|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L439]).
> The same happens when updating an expired row:
> {code:java}
> CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
> CREATE INDEX ON t(ck);
> UPDATE t USING TTL 1 SET v = 3 WHERE pk = 1 AND ck = 2; -- creates a
> non-expiring index entry (right)
> -- wait for the expiration of the above row
> SELECT * FROM t WHERE ck = 2; -- deletes the index entry (right)
> UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create an index entry
> (wrong)
> SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
> {code}
> I think that the fix for this is just using the
> {{getPrimaryKeyIndexLiveness}} in {{updateRow}}, as it's used in
> {{insertRow}}.
> Another related problem is that {{getPrimaryKeyIndexLiveness}} uses [the most
> recent TTL in the columns contained on the indexed row
> fragment|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L519]
> as the TTL of the index entry, producing an expiring index entry that
> ignores the columns without TTL that are already present in flushed sstables.
> So we can find this other error when setting a TTL over flushed indexed data:
> {code:java}
> CREATE TABLE t(k1 int, k2 int, v int, PRIMARY KEY ((k1, k2)));
> CREATE INDEX idx ON t(k1);
> INSERT INTO t (k1, k2, v) VALUES (1, 2, 3);
> -- flush
> UPDATE t USING TTL 1 SET v=0 WHERE k1=1 AND k2=2; -- creates an index entry
> with TTL (wrong)
> -- wait for TTL expiration
> SELECT TTL(v) FROM t WHERE k1=1; -- doesn't find the row (wrong)
> {code}
> The straightforward fix is just ignoring the TTL of the columns for indexes
> on primary key components, so we don't produce expiring index entries in that
> case. The index entries will be eventually deleted during index reads, when
> we are sure that they are not pointing to any live data.
>
--
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-16865) Avoid logging full stack trace when index summary redistribution is cancelled
[ https://issues.apache.org/jira/browse/CASSANDRA-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402230#comment-17402230 ] Benjamin Lerer commented on CASSANDRA-16865: The patch looks good to me. > Avoid logging full stack trace when index summary redistribution is cancelled > - > > Key: CASSANDRA-16865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16865 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.x > > > When a compaction process is interrupted in an expected fashion, we don't > need to dump full stack. Clutters up the logs. -- 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-16865) Avoid logging full stack trace when index summary redistribution is cancelled
[ https://issues.apache.org/jira/browse/CASSANDRA-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16865: --- Status: Ready to Commit (was: Review In Progress) > Avoid logging full stack trace when index summary redistribution is cancelled > - > > Key: CASSANDRA-16865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16865 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.x > > > When a compaction process is interrupted in an expected fashion, we don't > need to dump full stack. Clutters up the logs. -- 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-16865) Avoid logging full stack trace when index summary redistribution is cancelled
[ https://issues.apache.org/jira/browse/CASSANDRA-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16865: --- Status: Review In Progress (was: Patch Available) > Avoid logging full stack trace when index summary redistribution is cancelled > - > > Key: CASSANDRA-16865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16865 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.x > > > When a compaction process is interrupted in an expected fashion, we don't > need to dump full stack. Clutters up the logs. -- 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-16865) Avoid logging full stack trace when index summary redistribution is cancelled
[ https://issues.apache.org/jira/browse/CASSANDRA-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16865: --- Reviewers: Benjamin Lerer > Avoid logging full stack trace when index summary redistribution is cancelled > - > > Key: CASSANDRA-16865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16865 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.x > > > When a compaction process is interrupted in an expected fashion, we don't > need to dump full stack. Clutters up the logs. -- 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-16863) Ignore repair requests in mixed mode
[
https://issues.apache.org/jira/browse/CASSANDRA-16863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16863:
---
Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Benjamin Lerer, Benjamin Lerer
Status: Review In Progress (was: Patch Available)
> Ignore repair requests in mixed mode
>
>
> Key: CASSANDRA-16863
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16863
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x
>
>
> Repairs in mixed mode are not supported. On 4.0 we have CASSANDRA-13944 but
> <4.0 there is nothing preventing NPE and other scares in the logs. These
> cause unnecessary noise to operators.
> {noformat}
> java.lang.RuntimeException: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at
> org.apache.cassandra.service.ActiveRepairService.getParentRepairSession(ActiveRepairService.java:423)
> at
> org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:93)
> {noformat}
--
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-14564) Adding regular column to COMPACT tables without clustering columns should trigger an InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402226#comment-17402226
]
Benjamin Lerer commented on CASSANDRA-14564:
Thanks Stefan, the patches look good. Feel free to commit if the CI results are
good.
> Adding regular column to COMPACT tables without clustering columns should
> trigger an InvalidRequestException
> -
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables
> with COMPACT STORAGE enabled. We see some weird behaviour of cassandra
> while adding a column into it.
> Cassandra does not give any error while altering however the added column is
> invisible.
> Same behaviour when we create a new table with compact storage and try to
> alter it. Below is the commands ran in sequence:
>
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND 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': '4'}
> 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.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> 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';{code}
> Now altering the table by adding a new column:
>
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND 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': '4'}
> 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.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> 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';
> {code}
> notice that above desc table result does not have newly added column profile.
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
> emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5,
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
> emp_id | emp_city | emp_name | emp_phone | emp_sal
> +--+--+---+-
> (0 rows)
> {code}
> *How to solve that ticket*
> ([~blerer])--
>
> Adding regular columns to non-dense compact tables should be forbidden as it
> is the case for other column types. To do that
[jira] [Updated] (CASSANDRA-16859) allow blocking IPs from updating metrics about traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16859: --- Reviewers: Benjamin Lerer, Caleb Rackliffe, Jon Meredith (was: Caleb Rackliffe, Jon Meredith) > allow blocking IPs from updating metrics about traffic > -- > > Key: CASSANDRA-16859 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16859 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1 > > Time Spent: 4h > Remaining Estimate: 0h > > It is common that network scans happen for some companies, and when these > scans happen they will send packets to the Cassandra ports which do not match > our protocol; when this happens we fail and increment metrics to show this. > To avoid these scans polluting our metrics, we should allow users to block > their own IP subnets from updating these metrics. -- 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-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14344:
---
Status: Needs Reviewer (was: Review In Progress)
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
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-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401731#comment-17401731
]
Benjamin Lerer commented on CASSANDRA-14344:
[~n.v.harikrishna] I rebased your patch and modified it a bit to allow {{IN}}
filtering on all types of columns (partition key, clustering, regular and
static columns) not only on clustering columns. I also added support for
multi-column {{IN}} restrictions with a single column. I hope it is fine with
you.
|| Branch || CircleCi ||
| [trunk|https://github.com/apache/cassandra/pull/1159] |
[j8|https://app.circleci.com/pipelines/github/blerer/cassandra/189/workflows/7735aea2-e12b-436e-9280-bf41d5501589],
[j11|https://app.circleci.com/pipelines/github/blerer/cassandra/189/workflows/63daa4fc-e553-45f1-93bf-db5223c8b806]|
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
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-14564) Adding regular column to COMPACT tables without clustering columns should trigger an InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14564:
---
Reviewers: Benjamin Lerer
Status: Review In Progress (was: Needs Reviewer)
> Adding regular column to COMPACT tables without clustering columns should
> trigger an InvalidRequestException
> -
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables
> with COMPACT STORAGE enabled. We see some weird behaviour of cassandra
> while adding a column into it.
> Cassandra does not give any error while altering however the added column is
> invisible.
> Same behaviour when we create a new table with compact storage and try to
> alter it. Below is the commands ran in sequence:
>
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND 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': '4'}
> 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.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> 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';{code}
> Now altering the table by adding a new column:
>
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND 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': '4'}
> 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.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> 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';
> {code}
> notice that above desc table result does not have newly added column profile.
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
> emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5,
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
> emp_id | emp_city | emp_name | emp_phone | emp_sal
> +--+--+---+-
> (0 rows)
> {code}
> *How to solve that ticket*
> ([~blerer])--
>
> Adding regular columns to non-dense compact tables should be forbidden as it
> is the case for other column types. To do that {{AlterTableStatement}} should
> be modified to fire an
[jira] [Commented] (CASSANDRA-14564) Adding regular column to COMPACT tables without clustering columns should trigger an InvalidRequestException
[
https://issues.apache.org/jira/browse/CASSANDRA-14564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17401662#comment-17401662
]
Benjamin Lerer commented on CASSANDRA-14564:
Hi [~stefan.miklosovic],
Thanks for taking over the patch and sorry for the delay of my response. A
{{dense}} table is a compact table without clustering columns (see
[here|https://github.com/instaclustr/cassandra/blob/ce7b54a37a2aca7fe2da2f04a425a5c282574443/src/java/org/apache/cassandra/cql3/statements/CreateTableStatement.java#L277]).
By consequence, you can simply replace {{if (meta.isDense()) by {{if
(meta.isCompactTable())}}.
> Adding regular column to COMPACT tables without clustering columns should
> trigger an InvalidRequestException
> -
>
> Key: CASSANDRA-14564
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14564
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Laxmikant Upadhyay
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> I have upgraded my system from cassandra 2.1.16 to 3.11.2. We had some tables
> with COMPACT STORAGE enabled. We see some weird behaviour of cassandra
> while adding a column into it.
> Cassandra does not give any error while altering however the added column is
> invisible.
> Same behaviour when we create a new table with compact storage and try to
> alter it. Below is the commands ran in sequence:
>
> {code:java}
> x@cqlsh:xuser> CREATE TABLE xuser.employee(emp_id int PRIMARY KEY,emp_name
> text, emp_city text, emp_sal varint, emp_phone varint ) WITH COMPACT STORAGE;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND 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': '4'}
> 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.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> 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';{code}
> Now altering the table by adding a new column:
>
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> x@cqlsh:xuser> desc table xuser.employee ;
> CREATE TABLE xuser.employee (
> emp_id int PRIMARY KEY,
> emp_city text,
> emp_name text,
> emp_phone varint,
> emp_sal varint
> ) WITH COMPACT STORAGE
> AND 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': '4'}
> 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.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> 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';
> {code}
> notice that above desc table result does not have newly added column profile.
> However when i try to add it again it gives column already exist;
> {code:java}
> x@cqlsh:xuser> alter table employee add profile text;
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid
> column name profile because it conflicts with an existing column"
> x@cqlsh:xuser> select emp_name,profile from employee;
> emp_name | profile
> --+-
> (0 rows)
> x@cqlsh:xuser>
> {code}
> Inserting also behaves strange:
> {code:java}
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile) VALUES ( 1, 'ggn', 'john', 123456, 5, 'SE');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Some
> clustering keys are missing: column1"
> x@cqlsh:xuser> INSERT INTO employee (emp_id , emp_city , emp_name , emp_phone
> , emp_sal ,profile,column1) VALUES ( 1, 'ggn', 'john', 123456, 5,
> 'SE',null);
> x@cqlsh:xuser> select * from employee;
> emp_id | emp_city | emp_name | emp_phone | emp_sal
>
