[jira] [Updated] (CASSANDRA-18543) Waiting for gossip to settle does not wait for live endpoints
[ https://issues.apache.org/jira/browse/CASSANDRA-18543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Zemek updated CASSANDRA-18543: -- Attachment: gossip.patch > Waiting for gossip to settle does not wait for live endpoints > - > > Key: CASSANDRA-18543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18543 > Project: Cassandra > Issue Type: Bug >Reporter: Cameron Zemek >Priority: Normal > Attachments: gossip.patch > > > When a node starts it will get endpoint states (via shadow round) but have > all nodes marked as down. The problem is the wait to settle only checks the > size of endpoint states is stable before starting Native transport. Once > native transport starts it will receive queries and fail consistency levels > such as LOCAL_QUORUM since it still thinks nodes are down. > My initial solution to this was to also check live endpoints size in addition > to size of endpoint states. This worked but I noticed in testing this fix > that there also a lot of duplication of checking the same node (via Echo > messages) for liveness. So the patch also removes this duplication of > checking node is UP. > The final problem I found while testing is sometimes could still not see a > change in live endpoints due to only 1 second polling, so the patch allows > for overridding the settle parameters. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18543) Waiting for gossip to settle does not wait for live endpoints
[ https://issues.apache.org/jira/browse/CASSANDRA-18543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cameron Zemek updated CASSANDRA-18543: -- Attachment: (was: gossip.patch) > Waiting for gossip to settle does not wait for live endpoints > - > > Key: CASSANDRA-18543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18543 > Project: Cassandra > Issue Type: Bug >Reporter: Cameron Zemek >Priority: Normal > > When a node starts it will get endpoint states (via shadow round) but have > all nodes marked as down. The problem is the wait to settle only checks the > size of endpoint states is stable before starting Native transport. Once > native transport starts it will receive queries and fail consistency levels > such as LOCAL_QUORUM since it still thinks nodes are down. > My initial solution to this was to also check live endpoints size in addition > to size of endpoint states. This worked but I noticed in testing this fix > that there also a lot of duplication of checking the same node (via Echo > messages) for liveness. So the patch also removes this duplication of > checking node is UP. > The final problem I found while testing is sometimes could still not see a > change in live endpoints due to only 1 second polling, so the patch allows > for overridding the settle parameters. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15046: -- Status: Review In Progress (was: Changes Suggested) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15046: -- Status: Needs Committer (was: Review In Progress) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725230#comment-17725230 ] Stefan Miklosovic commented on CASSANDRA-15046: --- https://app.circleci.com/pipelines/github/instaclustr/cassandra/2275/workflows/76456e6f-521f-4e51-984e-15067fd8ec8a I think it is enough to build this for j8 as we are not touching any Java code. +1 on this branch https://github.com/instaclustr/cassandra/tree/CASSANDRA-15046 > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725228#comment-17725228
]
Stefan Miklosovic commented on CASSANDRA-18453:
---
j11 precommit
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2277/workflows/6d0d282b-0a05-4852-b067-a4c12390051c
j8 precommit
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2277/workflows/c0557226-1353-4705-9073-35758be14422
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18543) Waiting for gossip to settle does not wait for live endpoints
[ https://issues.apache.org/jira/browse/CASSANDRA-18543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725142#comment-17725142 ] Cameron Zemek commented on CASSANDRA-18543: --- Another potential solution might be to allow shadow round to allow marking nodes as alive (ie UP). That is if you are just starting up and talk to another seed who has view of state of cluster, why can it not just use that as initial state for alive state? > Waiting for gossip to settle does not wait for live endpoints > - > > Key: CASSANDRA-18543 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18543 > Project: Cassandra > Issue Type: Bug >Reporter: Cameron Zemek >Priority: Normal > Attachments: gossip.patch > > > When a node starts it will get endpoint states (via shadow round) but have > all nodes marked as down. The problem is the wait to settle only checks the > size of endpoint states is stable before starting Native transport. Once > native transport starts it will receive queries and fail consistency levels > such as LOCAL_QUORUM since it still thinks nodes are down. > My initial solution to this was to also check live endpoints size in addition > to size of endpoint states. This worked but I noticed in testing this fix > that there also a lot of duplication of checking the same node (via Echo > messages) for liveness. So the patch also removes this duplication of > checking node is UP. > The final problem I found while testing is sometimes could still not see a > change in live endpoints due to only 1 second polling, so the patch allows > for overridding the settle parameters. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18543) Waiting for gossip to settle does not wait for live endpoints
Cameron Zemek created CASSANDRA-18543: - Summary: Waiting for gossip to settle does not wait for live endpoints Key: CASSANDRA-18543 URL: https://issues.apache.org/jira/browse/CASSANDRA-18543 Project: Cassandra Issue Type: Bug Reporter: Cameron Zemek Attachments: gossip.patch When a node starts it will get endpoint states (via shadow round) but have all nodes marked as down. The problem is the wait to settle only checks the size of endpoint states is stable before starting Native transport. Once native transport starts it will receive queries and fail consistency levels such as LOCAL_QUORUM since it still thinks nodes are down. My initial solution to this was to also check live endpoints size in addition to size of endpoint states. This worked but I noticed in testing this fix that there also a lot of duplication of checking the same node (via Echo messages) for liveness. So the patch also removes this duplication of checking node is UP. The final problem I found while testing is sometimes could still not see a change in live endpoints due to only 1 second polling, so the patch allows for overridding the settle parameters. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18398) CEP-25: Trie-indexed SSTable format
[
https://issues.apache.org/jira/browse/CASSANDRA-18398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725114#comment-17725114
]
Caleb Rackliffe edited comment on CASSANDRA-18398 at 5/22/23 8:30 PM:
--
The rebase on CASSANDRA-18441 looks good, but there is one thing I'm a bit
worried about now:
{noformat}
# The default format is BIG, the legacy SSTable format in use since Cassandra
3.0.
# Cassandra versions 5.0 and later also support the trie-indexed BTI format,
# which offers better performance.
#sstable:
# selected_format: big
{noformat}
AFAICT, {{selected_format}} is case-sensitive. Combine this with the fact that
the inline docs here use all-caps, and someone could try to use BIG or BTI and
be a bit surprised that it doesn't work?
EDIT: I guess I'd be okay w/ being case-sensitive if the docs at least say
something like "big" and "bti" rather than all-caps :)
was (Author: maedhroz):
The rebase on CASSANDRA-18441 looks good, but there is one thing I'm a bit
worried about now:
{noformat}
# The default format is BIG, the legacy SSTable format in use since Cassandra
3.0.
# Cassandra versions 5.0 and later also support the trie-indexed BTI format,
# which offers better performance.
#sstable:
# selected_format: big
{noformat}
AFAICT, {{selected_format}} is case-sensitive. Combine this with the fact that
the inline docs here use all-caps, and someone could try to use BIG or BTI and
be a bit surprised that it doesn't work?
> CEP-25: Trie-indexed SSTable format
> ---
>
> Key: CASSANDRA-18398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18398
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 37h 10m
> Remaining Estimate: 0h
>
> Implementation of Big Trie-Indexed (BTI) SSTable format, per
> [CEP-25|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725115#comment-17725115
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
There are few hundreds of errors in tests
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2471/#showFailuresLink
It all seem to fail on "Unknown compression options: ([sstable_compression])"
We stopped to use this as it was deprecated so we removed it but tests are
still using it.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725115#comment-17725115
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 5/22/23 8:28 PM:
There are few hundreds of errors in tests
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2471/#showFailuresLink
It all seems to fail on "Unknown compression options: ([sstable_compression])"
We stopped to use this as it was deprecated so we removed it but tests are
still using it.
was (Author: smiklosovic):
There are few hundreds of errors in tests
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2471/#showFailuresLink
It all seem to fail on "Unknown compression options: ([sstable_compression])"
We stopped to use this as it was deprecated so we removed it but tests are
still using it.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18398) CEP-25: Trie-indexed SSTable format
[
https://issues.apache.org/jira/browse/CASSANDRA-18398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725114#comment-17725114
]
Caleb Rackliffe commented on CASSANDRA-18398:
-
The rebase on CASSANDRA-18441 looks good, but there is one thing I'm a bit
worried about now:
{noformat}
# The default format is BIG, the legacy SSTable format in use since Cassandra
3.0.
# Cassandra versions 5.0 and later also support the trie-indexed BTI format,
# which offers better performance.
#sstable:
# selected_format: big
{noformat}
AFAICT, {{selected_format}} is case-sensitive. Combine this with the fact that
the inline docs here use all-caps, and someone could try to use BIG or BTI and
be a bit surprised that it doesn't work?
> CEP-25: Trie-indexed SSTable format
> ---
>
> Key: CASSANDRA-18398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18398
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 37h 10m
> Remaining Estimate: 0h
>
> Implementation of Big Trie-Indexed (BTI) SSTable format, per
> [CEP-25|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17818) Fix error message handling when trying to use CLUSTERING ORDER with non-clustering column
[
https://issues.apache.org/jira/browse/CASSANDRA-17818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ningzi Zhan reassigned CASSANDRA-17818:
---
Assignee: Ningzi Zhan
> Fix error message handling when trying to use CLUSTERING ORDER with
> non-clustering column
> -
>
> Key: CASSANDRA-17818
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17818
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Ekaterina Dimitrova
>Assignee: Ningzi Zhan
>Priority: Normal
> Labels: lhf
> Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> Imagine ck1, ck2, v columns. For "CLUSTERING ORDER ck1 ASC, v DESC" error msg
> will suggest that information for ck2 is missing. But if you add it it will
> still be wrong as "v" cannot be used. So the problem here is really about
> using non-clustering column rather than about not providing information about
> some clustering column.
> The following is example from 3.11, but the code is the same in 4.0, 4.1,
> trunk:
> {code:java}
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck1"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Missing
> CLUSTERING ORDER for column ck2"
> cqlsh:k_test> CREATE TABLE test2 (pk int, ck1 int, ck2 int, v int, PRIMARY
> KEY ((pk),ck1, ck2)) WITH CLUSTERING ORDER BY (ck1 ASC, ck2 DESC, v ASC);
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Only
> clustering key columns can be defined in CLUSTERING ORDER directive"{code}
> We need to be sure that we return to the user the same correct error message
> in all three cases and it should be "Only clustering key columns can be
> defined in CLUSTERING ORDER directive"
> +Additional information for newcomers+
> *
> [This|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/statements/schema/CreateTableStatement.java#L251-L252]
> is where we handle the issue incorrectly as proved by the example. The
> easiest way to handle this issue would be to check the key set content of
> {_}clusteringOrder{_}.
> * It would be good also to add more unit tests in
> [CreateTableValidationTest|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/schema/CreateTableValidationTest.java]
> to cover different cases.
> * I suggest we create patch first for 3.11 and then we can propagate it up
> to the next versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725093#comment-17725093 ] Brad Schoening commented on CASSANDRA-15046: Yes, that was a bug. Fixed! > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18519) CEP-15: (C*) Add notion of CommandsForRanges and make this durable in C*
[ https://issues.apache.org/jira/browse/CASSANDRA-18519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-18519: --- Labels: pull-request-available (was: ) > CEP-15: (C*) Add notion of CommandsForRanges and make this durable in C* > > > Key: CASSANDRA-18519 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18519 > Project: Cassandra > Issue Type: Task > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > > To add support for range transactions in C* we need to make sure > 1) their state is durable and can be recovered on restart > 2) have some way to find all CommandsForKey that are contained in the range > transaction range > 3) have some way to find all CommandsForRange that intersect this range > To do this, I propose the following > 1) Create a new commands_for_range table that stores: (store, range) -> > list — this is byId, not sure if repair needs > byExecuteId as well > 2) For C*, store a in-memory mapping of Range -> List, and on-boot > repopulate this cache. This then can be used to construct the > CommandsForRange needed by the transaction. This makes an assumption that > many ranges will not exist, at least for the time being. > 3) Change commands_for_keys to use LocalPartitioner, and order the table by > (store, key) > 4) When C* sees a range transaction, find all keys that are contained by the > range by running the logical query "SELECT key FROM commands_for_keys WHERE > key BETWEEN range.start AND range.end". Implementation has to make sure to > handle many keys (may need to partition the range to increase parallel > access, and may need to page through the table to see all keys (aka multiple > ReadCommands)). Once all keys are found, then must load into the > CommandsForKeys cache > For #4, https://github.com/apache/cassandra-accord/pull/27 maybe able to > optimize the logic to lazy load only what is actually needed rather than load > the whole world -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725071#comment-17725071
]
Michael Semb Wever commented on CASSANDRA-18017:
Hi Maxim! Thanks for the patch. I'm working on CASSANDRA-18133 which will
address also this. Are we ok waiting for that work?
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[
https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725062#comment-17725062
]
Stefan Miklosovic edited comment on CASSANDRA-15046 at 5/22/23 6:28 PM:
Sorry that I am that guy but I found a bug :)
If you do "rm ~/.cassandra/cqlshrc_history" so there is no history at all, you
log in and get history, it will return you this:
{code}
cqlsh> history
None
None
None
None
None
None
None
None
None
None
...
cqlsh>
{code}
It seems like it is trying to print out the array of N lines no matter what,
even they do not exist.
was (Author: smiklosovic):
Sorry that I am that guy but I found a bug :)
If you do "rm ~/.cassandra/cqlshrc_history" so there is no history at all, you
log in and get history, it will return you this:
{code}
cqlsh> history
None
None
None
None
None
None
None
None
None
None
...
cqlsh>
{code}
> Add a "history" command to cqlsh. Perhaps "show history"?
> --
>
> Key: CASSANDRA-15046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15046
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Wes Peters
>Assignee: Brad Schoening
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I was trying to capture some create key space and create table commands from
> a running cqlsh, and found there was no equivalent to the '\s' history
> command in Postgres' psql shell. It's a great tool for figuring out what you
> were doing yesterday.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[
https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725062#comment-17725062
]
Stefan Miklosovic commented on CASSANDRA-15046:
---
Sorry that I am that guy but I found a bug :)
If you do "rm ~/.cassandra/cqlshrc_history" so there is no history at all, you
log in and get history, it will return you this:
{code}
cqlsh> history
None
None
None
None
None
None
None
None
None
None
...
cqlsh>
{code}
> Add a "history" command to cqlsh. Perhaps "show history"?
> --
>
> Key: CASSANDRA-15046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15046
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Wes Peters
>Assignee: Brad Schoening
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I was trying to capture some create key space and create table commands from
> a running cqlsh, and found there was no equivalent to the '\s' history
> command in Postgres' psql shell. It's a great tool for figuring out what you
> were doing yesterday.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725053#comment-17725053
]
Maxim Muzafarov commented on CASSANDRA-18453:
-
LGTM,
Started the build:
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2475/
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725047#comment-17725047
]
Bernardo Botella Corbi commented on CASSANDRA-18453:
The PR got the second +1 from Maxim. Please let me know if anything else ir
required from my side [~smiklosovic]
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725027#comment-17725027
]
Maxim Muzafarov commented on CASSANDRA-18017:
-
[~mck] Hello,
I've submitted the patch, but I'm not sure how to test it. Can you recommend
the way you normally test such patches?
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-18017:
Test and Documentation Plan: Documentation is not required. The flag is
added to the script.
Status: Patch Available (was: Open)
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned CASSANDRA-18017:
---
Assignee: Maxim Muzafarov
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18017) Jenkins: Consider using the no-build-test flag
[
https://issues.apache.org/jira/browse/CASSANDRA-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-18017:
Status: Open (was: Triage Needed)
> Jenkins: Consider using the no-build-test flag
> --
>
> Key: CASSANDRA-18017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18017
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-16625 and CASSANDRA-18000 added a {{-Dno-build-test=true}} flag to
> skip the dependencies of the Ant test targets. This is useful to speed up the
> test targets if the {{build-test}} target has already been previously run,
> for example as part of {{{}ant jar{}}}.
> That was created thinking mainly on CircleCI's multiplexer, where we run the
> same test target repeatedly. Skipping the already run depended on targets can
> significantly speed up the tests. The flag however is also useful for all
> other test jobs because every parallel runner can skip the test building
> step, and we have hundreds of parallel runners. Saving around 30s on every
> runner adds up considerable savings.
> Maybe this flag can also be used for skipping test builds on Jenkins too, so
> each parallel test split can benefit from a slight boost. That could be done
> if either {{build-test}} or {{jar}} have already been run before calling the
> test target. I'm not familiarized with Jenkins config so I'm not sure whether
> it makes sense.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725025#comment-17725025
]
Andres de la Peña commented on CASSANDRA-18521:
---
Committed to {{cep-7-sai}} as
[9970cf56848f0f6176560c0cf0ce704c9b9a8c05|https://github.com/apache/cassandra/commit/9970cf56848f0f6176560c0cf0ce704c9b9a8c05].
Thanks for the review.
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18521:
--
Source Control Link:
https://github.com/apache/cassandra/commit/9970cf56848f0f6176560c0cf0ce704c9b9a8c05
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-7-sai updated: Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch cep-7-sai
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cep-7-sai by this push:
new 9970cf5684 Unify CQLTester#waitForIndex and
SAITester#waitForIndexQueryable
9970cf5684 is described below
commit 9970cf56848f0f6176560c0cf0ce704c9b9a8c05
Author: Andrés de la Peña
AuthorDate: Thu May 11 15:01:00 2023 +0100
Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
patch by Andrés de la Peña; reviewed by Caleb Rackliffe for CASSANDRA-18521
---
.../cassandra/cql3/functions/types/ParseUtils.java | 4 +-
test/unit/org/apache/cassandra/cql3/CQLTester.java | 240 +++--
.../org/apache/cassandra/cql3/CQLTesterTest.java | 82 +++
.../org/apache/cassandra/cql3/KeyCacheCqlTest.java | 4 +-
.../entities/SecondaryIndexOnMapEntriesTest.java | 2 +-
.../validation/entities/SecondaryIndexTest.java| 38 ++--
.../operations/InsertUpdateIfConditionTest.java| 2 -
.../db/guardrails/GuardrailTablesTest.java | 2 +-
.../cassandra/index/SecondaryIndexManagerTest.java | 127 +--
.../index/internal/CassandraIndexTest.java | 9 +-
.../org/apache/cassandra/index/sai/SAITester.java | 41 +---
.../index/sai/cql/AllowFilteringTest.java | 6 -
.../cassandra/index/sai/cql/BaseDataModel.java | 29 ++-
.../cassandra/index/sai/cql/BooleanTypeTest.java | 1 -
.../index/sai/cql/CollectionIndexingTest.java | 3 -
.../index/sai/cql/DecimalLargeValueTest.java | 2 -
.../index/sai/cql/DuplicateRowIDTest.java | 1 -
.../sai/cql/MixedIndexImplementationsTest.java | 4 -
.../index/sai/cql/MultipleColumnIndexTest.java | 2 -
.../index/sai/cql/SingleNodeExecutor.java | 4 +-
.../index/sai/cql/StorageAttachedIndexDDLTest.java | 36 ++--
.../index/sai/cql/types/IndexingTypeSupport.java | 2 -
.../cassandra/index/sai/disk/NodeStartupTest.java | 5 +-
.../index/sai/disk/SelectiveIntersectionTest.java | 2 -
.../index/sai/disk/SingleNodeQueryFailureTest.java | 1 -
.../index/sai/functional/CompactionTest.java | 2 -
.../index/sai/functional/DiskSpaceTest.java| 1 -
.../index/sai/functional/DropTableTest.java| 1 -
.../index/sai/functional/FailureTest.java | 2 +-
.../index/sai/functional/GroupComponentsTest.java | 3 -
.../index/sai/functional/NodeRestartTest.java | 9 +-
.../index/sai/functional/SnapshotTest.java | 2 -
.../index/sai/metrics/QueryMetricsTest.java| 1 -
.../sai/metrics/SegmentFlushingFailureTester.java | 1 -
.../index/sai/metrics/StateMetricsTest.java| 6 +-
.../cassandra/index/sai/plan/OperationTest.java| 2 +-
.../index/sai/virtual/IndexesSystemViewTest.java | 4 +-
.../index/sai/virtual/SSTablesSystemViewTest.java | 2 -
.../index/sai/virtual/SegmentsSystemViewTest.java | 1 -
39 files changed, 383 insertions(+), 303 deletions(-)
diff --git a/src/java/org/apache/cassandra/cql3/functions/types/ParseUtils.java
b/src/java/org/apache/cassandra/cql3/functions/types/ParseUtils.java
index 8972beed15..8d0f29b45b 100644
--- a/src/java/org/apache/cassandra/cql3/functions/types/ParseUtils.java
+++ b/src/java/org/apache/cassandra/cql3/functions/types/ParseUtils.java
@@ -292,7 +292,7 @@ public abstract class ParseUtils
* @param value The string to un-double quote.
* @return The un-double quoted string.
*/
-static String unDoubleQuote(String value)
+public static String unDoubleQuote(String value)
{
return unquote(value, '"');
}
@@ -482,7 +482,7 @@ public abstract class ParseUtils
* @return {@code true} if the given string is surrounded by the quote
character, and {@code
* false} otherwise.
*/
-private static boolean isQuoted(String value, char quoteChar)
+public static boolean isQuoted(String value, char quoteChar)
{
return value != null
&& value.length() > 1
diff --git a/test/unit/org/apache/cassandra/cql3/CQLTester.java
b/test/unit/org/apache/cassandra/cql3/CQLTester.java
index bf2f137165..f81cdbf38e 100644
--- a/test/unit/org/apache/cassandra/cql3/CQLTester.java
+++ b/test/unit/org/apache/cassandra/cql3/CQLTester.java
@@ -35,6 +35,7 @@ import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.stream.Collectors;
+import javax.annotation.Nullable;
import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
@@ -71,9 +72,11 @@ import org.apache.cassandra.concurrent.ScheduledExecutors;
import org.apache.cassandra.concurrent.Stage;
import org.apache.cassandra.config.DataStorageSpec;
import org.apache.cassandra.config.EncryptionOptions;
+import org.apache.cassandra.cql3.functions.types.Par
[jira] [Commented] (CASSANDRA-18453) Use WithProperties to ensure that system properties are handled
[
https://issues.apache.org/jira/browse/CASSANDRA-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725024#comment-17725024
]
Bernardo Botella Corbi commented on CASSANDRA-18453:
[~mmuzaf] [~smiklosovic] Thanks a lot for the reviews! I updated the PR
addressing all the comments.
> Use WithProperties to ensure that system properties are handled
> ---
>
> Key: CASSANDRA-18453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18453
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Maxim Muzafarov
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The {{WithProperties}} is used to handle system properties to set and reset
> values during the test run, instead of try-catch it uses the
> try-with-resource approach which facilitates test development.
> We need to replace all the try-catch clauses that work with system properties
> with {{WithProperties}} and try-with-resource for all the similar cases and
> where it is technically possible.
> Example:
> {code:java}
> try
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.setBoolean(true);
> testRecoveryWithGarbageLog();
> }
> finally
> {
> COMMITLOG_IGNORE_REPLAY_ERRORS.clearValue();
> }
> {code}
> Can be replaced with:
> {code:java}
> try (WithProperties = new
> WithProperties().with(COMMITLOG_IGNORE_REPLAY_ERRORS, "true"))
> {
> testRecoveryWithGarbageLog();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18534) Make sstable format configurable per table
[
https://issues.apache.org/jira/browse/CASSANDRA-18534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725015#comment-17725015
]
Caleb Rackliffe commented on CASSANDRA-18534:
-
I would just note that we need to make sure we avoid the category of problems
we had to address in CASSANDRA-18040 for table-specific Memtable API
configuration.
> Make sstable format configurable per table
> --
>
> Key: CASSANDRA-18534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18534
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Branimir Lambov
>Priority: Normal
>
> Some SSTable format settings need to be configurable per table for better
> efficiency. This includes:
> - {{row_index_granularity}}
> - {{bloom_filter_fp_chance}}
> - {{crc_check_chance}}
> - {{min/max_index_interval}}
> Some of these are currently configurable using direct properties of tables.
> Having them as format properties makes better sense and should also support
> specifying useable combinations of settings, e.g.
> {code:java}
> CREATE TABLE ... WITH sstable_format = "bti-fast";
> CREATE TABLE ... WITH sstable_format = "bti-small";
> {code}
> where {{bti-fast}} and {{bti-small}} can be defined in {{cassandra.yaml}}
> e.g. as
> {code:java}
> sstable.format.options:
> - bti-fast:
> row_index_granularity: 1kiB
> bloom_filter_fp_chance: 0.01
> - bti-small:
> row_index_granularity: 32kiB
> bloom_filter_fp_chance: 0.1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18541) AUTH requests use too much resources
[ https://issues.apache.org/jira/browse/CASSANDRA-18541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724990#comment-17724990 ] Dinesh Joshi commented on CASSANDRA-18541: -- Can you provide steps to repro the issue? The CPU graphs are not entirely actionable on their own. If possible you can even capture flame graphs on one of the Cassandra nodes using the [async profiler|https://github.com/async-profiler/async-profiler]. > AUTH requests use too much resources > > > Key: CASSANDRA-18541 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18541 > Project: Cassandra > Issue Type: Bug >Reporter: Yury Vidineev >Priority: Normal > Attachments: Screenshot_20230520_000633.png, > Screenshot_20230520_000654.png > > > Hello. I see unexpected CPU usage in a rare situation that may be worth > digging into. > We have C* 4.0.9 on Debian running on Java 11.0.18. > It's a small cluster of 3 nodes on commodity hardware (6 cores CPU, 32 Gb > RAM, 2 x 512 Gb SSD NVME). > This ring has about 35 clients using Datastax Java Driver for Apache > Cassandra. > In the driver connection settings, we use the following: > CONNECTION_POOL_LOCAL_SIZE = 400 > CONNECTION_POOL_REMOTE_SIZE = 100 > > And for some reason, from time to time, it causes hundreds of AUTH requests > per second that leads to an enormous CPU usage. > And yes, it's easy not to use these settings in the driver, leaving defaults > that don't produce such an amount of AUTHs. But isn't it weird that ~150 AUTH > rps consume ~1200% CPU? > Please see attached graphs. > I have the following in the settings: > authenticator: PasswordAuthenticator > authorizer: CassandraAuthorizer > roles_validity_in_ms: 60 > permissions_validity_in_ms: 60 > credentials_validity_in_ms: 60 > Please let me know if I can provide any other necessary information. > Thanks for your work. Cassandra is amazing :) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18180) bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724982#comment-17724982
]
Brandon Williams commented on CASSANDRA-18180:
--
I think enough due diligence has been done here that we should probably accept
the exports at this point, and we can open a ticket in the future if this
becomes a higher priority.
> bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17
> ---
>
> Key: CASSANDRA-18180
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18180
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
>
> While working on CASSANDRA-17992 we hit:
> {code:java}
> java.lang.ClassCastException: class
> org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class
> sun.nio.ch.DirectBuffer (org.apache.cassandra.utils.memory.BufferPool$Chunk
> is in unnamed module of loader 'app'; sun.nio.ch.DirectBuffer is in module
> java.base of loader 'bootstrap')\n\tat
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMEngine.overlapDetection(GaloisCounterMode.java:865)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt.doFinal(GaloisCounterMode.java:1502)\n\tat
>
> java.base/com.sun.crypto.provider.GaloisCounterMode.engineDoFinal(GaloisCounterMode.java:447)\n\tat
>
> {code}
> -The issue is exposed with JDK 17, trunk; if interested, ping- [~e.dimitrova]
> -for current branch as there is no feature branch at the moment- we can
> build and start from trunk with JDK17 already. Circle CI can be run for JDK17
> too. For more information how to do that - .circleci/readme.md
> CC [~benedict]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724981#comment-17724981
]
Brandon Williams commented on CASSANDRA-18540:
--
Seems like we should switch to TLS1.2, I know people are disabling 1.1 in their
configs as it is.
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, a
> specific JDK8 build (accidentally?) dropped TLSv1.1 (later added again) which
> led to adding some docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18540) negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed to negotiate" on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dan jatnieks reassigned CASSANDRA-18540:
Assignee: dan jatnieks
> negotiatedProtocolMustBeAcceptedProtocolTest tests fail with "TLSv1.1 failed
> to negotiate" on JDK17
> ---
>
> Key: CASSANDRA-18540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18540
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: dan jatnieks
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
> Note: This depends on having a fix for CASSANDRA-18180, otherwise most/all
> tests in {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} are failing due to that issue.
> Using the patch for CASSANDRA-18180, the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} test in both
> {{NativeTransportEncryptionOptionsTest}} and
> {{InternodeEncryptionOptionsTest}} fails with "TLSv1.1 failed to negotiate"
> on JDK17.
> From what I can see, the {{negotiatedProtocolMustBeAcceptedProtocolTest}} is
> failing because in JDK11 and JDK17 the "TLSv1.1" protocol is disabled.
> Since TLSv1.1 is disabled in JDK11 and 17, one possibility is to change the
> test to use TLSv1.2 instead of TLSv1.1. That should work directly with JDK11
> and 17, since TLSv1.2 is one of the defaults, and it won't be an issue for
> JDK8 as that will be dropped.
> Also, I think the point of the
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is to test that the
> {{accepted_protocols}} option is working correctly rather than the choice of
> _which_ protocol is used. Meaning, I don’t think the intent was to test
> TLSv1.1 specifically, rather that the mechanism of accepted protocols works
> and choosing TLSv1.1 was at the time convenient - but I could be wrong.
> It also seems to me like bit of a coincidence that these tests are currently
> working on JDK11, at least on CI. Indeed, running locally with JDK11, these
> fail for me:
> {noformat}
> $ pwd
> /Users/dan.jatnieks/apache/cassandra-4.0
> $ java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> $ ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> -Duse.jdk11=true
> ...
> [junit-timeout] Testcase:
> negotiatedProtocolMustBeAcceptedProtocolTest(org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest):
>FAILED
> [junit-timeout] Should be possible to establish a TLSv1.1 connection
> expected: but was:
> [junit-timeout] junit.framework.AssertionFailedError: Should be possible to
> establish a TLSv1.1 connection expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest.negotiatedProtocolMustBeAcceptedProtocolTest(NativeTransportEncryptionOptionsTest.java:160)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> I believe these work on CI because of CASSANDRA-16848 - in that ticket, a
> specific JDK8 build (accidentally?) dropped TLSv1.1 (later added again) which
> led to adding some docker code to make sure TLSv1.1 is accepted.
> I say coincidence because this change also makes it work for JDK11 and JDK17,
> and I've been able to verify that making a change locally to the JDK
> {{java.security}} file. I’m not sure that at the time of CASSANDRA-16848 it
> was intended for any JDK versions.
> The point of mentioning this is that if
> {{negotiatedProtocolMustBeAcceptedProtocolTest}} is changed to use TLSv1.2,
> and support for JDK8 is dropped, then the changes made in CASSANDRA-16848
> could also be reverted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724944#comment-17724944 ] Brad Schoening commented on CASSANDRA-15046: updated and ran pycodestyle successfully > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18542) Add a simple way to run pycodestyle checks
[ https://issues.apache.org/jira/browse/CASSANDRA-18542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724935#comment-17724935 ] Stefan Miklosovic commented on CASSANDRA-18542: --- even better, there might be additional "ant checkstyle-python" target which would invoke it. This gives very quick feedback how it looks like. > Add a simple way to run pycodestyle checks > -- > > Key: CASSANDRA-18542 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18542 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > As the title says. Basically I want to solve the problem of having perfectly > valid good looking python, only push and have the dtests run pycodestyle and > fail everything out for a missing blank line. We should have a convenient > way to catch this sooner. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18542) Add a simple way to run pycodestyle checks
[ https://issues.apache.org/jira/browse/CASSANDRA-18542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724922#comment-17724922 ] Stefan Miklosovic edited comment on CASSANDRA-18542 at 5/22/23 12:04 PM: - I would remove it from dtests and I would place it into cassandra repository into pylib/cassandra-cqlsh-test.sh. It does just this pycodestyle --ignore E501,E402,E731,W503 pylib/cqlshlib/*.py bin/cqlsh.py There is some logic around it in dtest but I am not sure it needs to be so complicated and what is the difference. was (Author: smiklosovic): I would remove it from dtests and I would place it into cassandra repository under into pylib/cassandra-cqlsh-test.sh. It does just this pycodestyle --ignore E501,E402,E731,W503 pylib/cqlshlib/*.py bin/cqlsh.py There is some logic around it in dtest but I am not sure it needs to be so complicated and what is the difference. > Add a simple way to run pycodestyle checks > -- > > Key: CASSANDRA-18542 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18542 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > As the title says. Basically I want to solve the problem of having perfectly > valid good looking python, only push and have the dtests run pycodestyle and > fail everything out for a missing blank line. We should have a convenient > way to catch this sooner. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18542) Add a simple way to run pycodestyle checks
[ https://issues.apache.org/jira/browse/CASSANDRA-18542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724922#comment-17724922 ] Stefan Miklosovic commented on CASSANDRA-18542: --- I would remove it from dtests and I would place it into cassandra repository under into pylib/cassandra-cqlsh-test.sh. It does just this pycodestyle --ignore E501,E402,E731,W503 pylib/cqlshlib/*.py bin/cqlsh.py There is some logic around it in dtest but I am not sure it needs to be so complicated and what is the difference. > Add a simple way to run pycodestyle checks > -- > > Key: CASSANDRA-18542 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18542 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > As the title says. Basically I want to solve the problem of having perfectly > valid good looking python, only push and have the dtests run pycodestyle and > fail everything out for a missing blank line. We should have a convenient > way to catch this sooner. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724910#comment-17724910 ] Brandon Williams commented on CASSANDRA-15046: -- I created CASSANDRA-18542 to help with this "missing blank line ruins the day" problem. > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18542) Add a simple way to run pycodestyle checks
[ https://issues.apache.org/jira/browse/CASSANDRA-18542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18542: - Change Category: Quality Assurance Complexity: Normal Component/s: Build Fix Version/s: 4.0.x 4.1.x 5.x Status: Open (was: Triage Needed) > Add a simple way to run pycodestyle checks > -- > > Key: CASSANDRA-18542 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18542 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > As the title says. Basically I want to solve the problem of having perfectly > valid good looking python, only push and have the dtests run pycodestyle and > fail everything out for a missing blank line. We should have a convenient > way to catch this sooner. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18542) Add a simple way to run pycodestyle checks
Brandon Williams created CASSANDRA-18542: Summary: Add a simple way to run pycodestyle checks Key: CASSANDRA-18542 URL: https://issues.apache.org/jira/browse/CASSANDRA-18542 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams As the title says. Basically I want to solve the problem of having perfectly valid good looking python, only push and have the dtests run pycodestyle and fail everything out for a missing blank line. We should have a convenient way to catch this sooner. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15719) DOC - Primary range repair should be run on every datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-15719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15719:
-
Bug Category: Parent values: Documentation(13562)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.1.x
5.x
Severity: Normal
Status: Open (was: Triage Needed)
> DOC - Primary range repair should be run on every datacenter
>
>
> Key: CASSANDRA-15719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15719
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Blog
>Reporter: Jane Deng
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
>
> In the Cassandra document page:
> [http://cassandra.apache.org/doc/latest/operating/repair.html], there is an
> explanation which makes confusion on users' side:
> {quote}The {{-pr}} flag will only repair the “primary” ranges on a node, so
> you can repair your entire cluster by running {{nodetool repair -pr}} on each
> node in a single datacenter.
> {quote}
> This made confusion that "running nodetool repair -pr on each node in a
> single DC" was sufficient to do a full repair on a multi-DC cluster.
> The correct way to use the primary range repair should be
> {quote}if you are using “nodetool repair -pr” you must run it on *EVERY* node
> in *EVERY* data center, no skipping allowed.
> {quote}
> Please make a doc fix. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13041) Do not allow removal of a DC from system_auth replication settings if the DC has active Cassandra instances
[ https://issues.apache.org/jira/browse/CASSANDRA-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724882#comment-17724882 ] Andres de la Peña commented on CASSANDRA-13041: --- A new guardrail certainly sounds good for this if the protection needs to be configurable. Or if we want to allow it with a warning. > Do not allow removal of a DC from system_auth replication settings if the DC > has active Cassandra instances > --- > > Key: CASSANDRA-13041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13041 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nachiket Patil >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 5.x > > Attachments: trunk.diff > > > I don’t believe it is ever correct to remove a DC from the system_auth > replication settings while there are nodes up in that DC. Cassandra should > not allow this change if there are hosts which are currently members of the > cluster in that DC, as any request which is routed to these hosts will meet > an unavailable. Also dropping the keyspace system_auth should not be allowed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724865#comment-17724865
]
Berenguer Blasi commented on CASSANDRA-14227:
-
Thx, it should be pretty non-controversial and we can always tweak the name etc.
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 5.x
>
> Attachments: C14227 Perf check 2023.03.21.pdf, screenshot-1.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18534) Make sstable format configurable per table
[
https://issues.apache.org/jira/browse/CASSANDRA-18534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723920#comment-17723920
]
maxwellguo edited comment on CASSANDRA-18534 at 5/22/23 9:06 AM:
-
Any volunteers ? If not, I think i can try to take this . [~blambov]
was (Author: maxwellguo):
Any volunteers ? If not, I think i can try to take this .
> Make sstable format configurable per table
> --
>
> Key: CASSANDRA-18534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18534
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Branimir Lambov
>Priority: Normal
>
> Some SSTable format settings need to be configurable per table for better
> efficiency. This includes:
> - {{row_index_granularity}}
> - {{bloom_filter_fp_chance}}
> - {{crc_check_chance}}
> - {{min/max_index_interval}}
> Some of these are currently configurable using direct properties of tables.
> Having them as format properties makes better sense and should also support
> specifying useable combinations of settings, e.g.
> {code:java}
> CREATE TABLE ... WITH sstable_format = "bti-fast";
> CREATE TABLE ... WITH sstable_format = "bti-small";
> {code}
> where {{bti-fast}} and {{bti-small}} can be defined in {{cassandra.yaml}}
> e.g. as
> {code:java}
> sstable.format.options:
> - bti-fast:
> row_index_granularity: 1kiB
> bloom_filter_fp_chance: 0.01
> - bti-small:
> row_index_granularity: 32kiB
> bloom_filter_fp_chance: 0.1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724840#comment-17724840
]
Benedict Elliott Smith commented on CASSANDRA-14227:
Sorry, the downside of lots of Jira traffic (incl from GitHub comments) is that
I don't check the email notifications for a high traffic ticket.
I won't have time to look at the code soon, but I trust you to have addressed
my concerns given what you describe above. Feel free to proceed.
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 5.x
>
> Attachments: C14227 Perf check 2023.03.21.pdf, screenshot-1.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724808#comment-17724808 ] Stefan Miklosovic edited comment on CASSANDRA-15046 at 5/22/23 8:09 AM: Still no success https://app.circleci.com/pipelines/github/instaclustr/cassandra/2269/workflows/9cf3f957-1c51-4e19-b029-ceecb4a2d9dc/jobs/36523/tests#failed-test-0 No worries, I've fixed and I run it again. was (Author: smiklosovic): Still no success https://app.circleci.com/pipelines/github/instaclustr/cassandra/2269/workflows/9cf3f957-1c51-4e19-b029-ceecb4a2d9dc/jobs/36523/tests#failed-test-0 > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17724808#comment-17724808 ] Stefan Miklosovic commented on CASSANDRA-15046: --- Still no success https://app.circleci.com/pipelines/github/instaclustr/cassandra/2269/workflows/9cf3f957-1c51-4e19-b029-ceecb4a2d9dc/jobs/36523/tests#failed-test-0 > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
