[jira] [Commented] (CASSANDRA-9753) LOCAL_QUORUM reads can block cross-DC if there is a digest mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412304#comment-17412304 ] Jeremy Hanna commented on CASSANDRA-9753: - Is it fair to say that temporarily disabling (dc_local_)read_repair_chance and speculative retry while adding a new data center will mean that all LOCAL_* consistency level based queries will stay in the origin data center? > LOCAL_QUORUM reads can block cross-DC if there is a digest mismatch > --- > > Key: CASSANDRA-9753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9753 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Coordination >Reporter: Richard Low >Priority: Normal > > When there is a digest mismatch during the initial read, a data read request > is sent to all replicas involved in the initial read. This can be more than > the initial blockFor if read repair was done and if speculative retry kicked > in. E.g. for RF 3 in two DCs, the number of reads could be 4: 2 for > LOCAL_QUORUM, 1 for read repair and 1 for speculative read if one replica was > slow. If there is then a digest mismatch, Cassandra will issue the data read > to all 4 and set blockFor=4. Now the read query is blocked on cross-DC > latency. The digest mismatch read blockFor should be capped at RF for the > local DC when using CL.LOCAL_*. > You can reproduce this behaviour by creating a keyspace with > NetworkTopologyStrategy, RF 3 per DC, dc_local_read_repair=1.0 and ALWAYS for > speculative read. If you force a digest mismatch (e.g. by deleting a replicas > SSTables and restarting) you can see in tracing that it is blocking for 4 > responses. -- 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
]
Ekaterina Dimitrova updated CASSANDRA-14752:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> 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-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1741#comment-1741
]
Ekaterina Dimitrova commented on CASSANDRA-16841:
-
Thank you [~k-rus], confirmed, we are on the same page. Thank you for your
work.
About the ticket status, staying in REVIEW IN PROGRESS is fine. You are
addressing small review comment.
If it was a big ticket with a lot of rewriting, someone might return it to work
in progress but I don't think this is the case. Just ping us on the ticket when
you are ready so we can do a final check and commit. Thanks again for all your
work! :)
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An issue, which I was hit:
> When one class in a dtest file is marked as resource intensive, then all
> tests in all classes are treated as resource intensive. For example,
> [repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
> contains three classes and the last class is marked as resource intensive:
> {code:java}
> @pytest.mark.resource_intensive
> class TestRepairDataSystemTable(Tester):
> {code}
> So if I try to run an unmarked class:
> {code:java}
> pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
> --collect-only --skip-resource-intensive-tests
> {code}
> then all tests are ignored
> {code:java}
> collected 36 items / 36 deselected
> {code}
> This is because a test is treated to be marked if any class in the same file
> has the mark. This bug was introduced in the fix of CASS-16399. Before only
> upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
> then all tests are upgrade test in the file.
>
> This bug, for example, means that if the same file contains one class marked
> with vnodes and another class with no_vnodes, then no tests will be executed
> in the file.
> I also noticed another issue that If a test run is executed with the argument
> {{-only-resource-intensive-tests}} and there is no sufficient resources for
> resource intensive tests, then no tests were executed. Thus it was necessary
> to provide {{-force-resource-intensive-tests}} in addition.
> Suggestions for the solutions:
> # Require to mark each class and remove the special case of upgrade tests.
> This will simplify the implementation and might be more obvious for new
> comers.
> # Treat {{-only-resource-intensive-tests}} in the same way as
> {{-force-resource-intensive-tests}}, so it will be enough to just specify it
> even with no sufficient resources.
> *Update:* comments were provided to keep only the first suggestion and do not
> implement the second suggestion.
>
--
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-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:comment-tabpanel=17412185#comment-17412185
]
Josh McKenzie commented on CASSANDRA-12988:
---
This patch as it stands ties read auth CL together at LOCAL_QUORUM, writes at
EACH_QUORUM. Previously, we had a kind of hodge-podge of them across various
classes:
* ConsistencyLevel.LOCAL_ONE for both read and write operations in
CassandraAuthorizer
* ConsistencyLevel.ONE for batches in there
* ConsistencyLevel.QUORUM for checks in CassandraRoleManager +
PasswordAuthenticator if the username is "cassandra"
* ConsistencyLevel.LOCAL_ONE for checks in CassandraRoleManager +
PasswordAuthenticator if the username is otherwise
Right now there's a handful of dtests failing as they're specifically looking
for error messages that match the above expected CL's for various auth
failures. At this point I think the right course of action is to tidy up those
dtests and also update NEWS.txt with some variation of the above note about the
change in consistency levels from essentially ONE to QUORUM.
Assuming no disagreement from you [~b.le...@gmail.com], I'll get on that in the
morning.
> 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] [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=17412182#comment-17412182
]
Chris Lohfink commented on CASSANDRA-16806:
---
I am +1 to change. From looks of it it was pretty unnecessary to restrict them
in first place.
> 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: 3.5h
> 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-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412162#comment-17412162 ] Brandon Williams commented on CASSANDRA-16895: -- GraalJS is UPL https://github.com/oracle/graaljs/blob/master/LICENSE UPL is Category A: https://www.apache.org/legal/resolved.html so I think if we [use graaljs|https://github.com/oracle/graaljs/blob/master/docs/user/RunOnJDK.md] that should be ok. > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > This ticket is intended to group all issues found to support Java 17 in the > future. -- 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
]
Chris Lohfink updated CASSANDRA-16806:
--
Reviewers: Benjamin Lerer, Chris Lohfink (was: Benjamin Lerer)
> 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-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412159#comment-17412159 ] Ekaterina Dimitrova commented on CASSANDRA-16895: - Good catch, this would be an issue according to [https://www.apache.org/licenses/GPL-compatibility.html] > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > This ticket is intended to group all issues found to support Java 17 in the > future. -- 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-16901) Optimize heavily-used `String.format()`-with-constant formatter use cases
[
https://issues.apache.org/jira/browse/CASSANDRA-16901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412150#comment-17412150
]
Tatu Saloranta commented on CASSANDRA-16901:
No, I don't have cluster benchmarks unfortunately. I doubt effect would be big
enough to show on latencies; might be visible on heap dumps wrt garbage
(assuming `QualifiedName.to[CQL]String()` is heavily used, maybe it isn't).
My thinking is more along the lines of this being incremental improvement which
would not add complexity (a simple helper method). But I agree that ideally it
would show some measurable improvement.
> Optimize heavily-used `String.format()`-with-constant formatter use cases
> -
>
> Key: CASSANDRA-16901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16901
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tatu Saloranta
>Priority: Normal
>
> For background, I did some benchmarking to compare performance of two simple
> ways to concatenate 2 Strings with a separator (used in f.ex
> `QualifiedName.java` for "keyspace:name" concatenation):
> # String.format("%s.%s", keyspace, name);
> # new StringBuilder().append(keyspace).append('.').append(name).toString()
> Difference is somewhat significant (for me, factor of 40x), as per:
> https://cowtowncoder.medium.com/measuring-performance-of-java-string-format-or-lack-thereof-2e1c6a13362c
> and so it seems worthwhile replacing at least some of usage from Cassandra.
> With a quick look it seems that classes like:
> * QualifiedName.java, FieldSelector.java, Selectable.java (in cql3)
> could benefit from this. And the second implementation can be packaged as a
> simple utility method (concatenateStringsWithChar?) so that code should be as
> readable as before.
> I can provide a patch, or if anyone else wants to have a go, feel free to.
>
>
>
--
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-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412151#comment-17412151 ] Brandon Williams commented on CASSANDRA-16895: -- GraalVM is [GPL2|https://github.com/oracle/graal/blob/master/LICENSE] unfortunately. > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > This ticket is intended to group all issues found to support Java 17 in the > future. -- 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-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412148#comment-17412148 ] Ekaterina Dimitrova edited comment on CASSANDRA-16895 at 9/8/21, 7:23 PM: -- Some initial thoughts after some initial work done to remove Java 8 and add Java 17 for trunk: - The Nashorn engine has been deprecated in JDK 11 as part of [JEP 335|https://openjdk.java.net/jeps/335] and has been removed from JDK15 as part of [JEP 372|https://openjdk.java.net/jeps/372]. GraalVM can step in as a replacement for JavaScript code previously executed on the Nashorn engine. GraalVM provides all the features for JavaScript previously provided by Nashorn. Working on this part now. - We will need more -add-exports and --add-opens as Java 17 is quite restrictive. - Currently [this script |https://github.com/apache/cassandra/blob/trunk/build.xml#L147-L155]inclusion in build.xml leads to _../cassandra/build.xml:147: Unable to create javax script engine for javascript,_ related to the Nashorn removal. My initial try to solve this didn't work. I left it for later as a lower priority task. - ant updated; probably other dependencies will have to be updated too was (Author: e.dimitrova): Some initial thoughts after some initial work done to remove Java 8 and add Java 17 for trunk: - The Nashorn engine has been deprecated in JDK 11 as part of [JEP 335|https://openjdk.java.net/jeps/335] and and has been removed from JDK15 as part of [JEP 372|https://openjdk.java.net/jeps/372]. GraalVM can step in as a replacement for JavaScript code previously executed on the Nashorn engine. GraalVM provides all the features for JavaScript previously provided by Nashorn. Working on this part now. - We will need more -add-exports and --add-opens as Java 17 is quite restrictive. - Currently [this script |https://github.com/apache/cassandra/blob/trunk/build.xml#L147-L155]inclusion in build.xml leads to _../cassandra/build.xml:147: Unable to create javax script engine for javascript,_ related to the Nashorn removal. My initial try to solve this didn't work. I left it for later as a lower priority task. - ant updated; probably other dependencies will have to be updated too > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > This ticket is intended to group all issues found to support Java 17 in the > future. -- 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-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412148#comment-17412148 ] Ekaterina Dimitrova edited comment on CASSANDRA-16895 at 9/8/21, 7:23 PM: -- Some initial thoughts after some initial work done to remove Java 8 and add Java 17 for trunk: - The Nashorn engine has been deprecated in JDK 11 as part of [JEP 335|https://openjdk.java.net/jeps/335] and and has been removed from JDK15 as part of [JEP 372|https://openjdk.java.net/jeps/372]. GraalVM can step in as a replacement for JavaScript code previously executed on the Nashorn engine. GraalVM provides all the features for JavaScript previously provided by Nashorn. Working on this part now. - We will need more -add-exports and --add-opens as Java 17 is quite restrictive. - Currently [this script |https://github.com/apache/cassandra/blob/trunk/build.xml#L147-L155]inclusion in build.xml leads to _../cassandra/build.xml:147: Unable to create javax script engine for javascript,_ related to the Nashorn removal. My initial try to solve this didn't work. I left it for later as a lower priority task. - ant updated; probably other dependencies will have to be updated too was (Author: e.dimitrova): Some initial thoughts after some initial work done to remove Java 8 and add Java 17 for trunk: -The Nashorn engine has been deprecated in JDK 11 as part of [JEP 335|https://openjdk.java.net/jeps/335] and and has been removed from JDK15 as part of [JEP 372|https://openjdk.java.net/jeps/372]. GraalVM can step in as a replacement for JavaScript code previously executed on the Nashorn engine. GraalVM provides all the features for JavaScript previously provided by Nashorn. Working on this part now. - We will need more -add-exports and --add-opens as Java 17 is quite restrictive. - Currently [this script |https://github.com/apache/cassandra/blob/trunk/build.xml#L147-L155]inclusion in build.xml leads to _../cassandra/build.xml:147: Unable to create javax script engine for javascript,_ related to the Nashorn removal. My initial try to solve this didn't work. I left it for later as a lower priority task. - ant updated; probably other dependencies will have to be updated too > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > This ticket is intended to group all issues found to support Java 17 in the > future. -- 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-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412148#comment-17412148 ] Ekaterina Dimitrova commented on CASSANDRA-16895: - Some initial thoughts after some initial work done to remove Java 8 and add Java 17 for trunk: -The Nashorn engine has been deprecated in JDK 11 as part of [JEP 335|https://openjdk.java.net/jeps/335] and and has been removed from JDK15 as part of [JEP 372|https://openjdk.java.net/jeps/372]. GraalVM can step in as a replacement for JavaScript code previously executed on the Nashorn engine. GraalVM provides all the features for JavaScript previously provided by Nashorn. Working on this part now. -We will need more --add-exports and --add-opens as Java 17 is quite restrictive. - Currently [this script |https://github.com/apache/cassandra/blob/trunk/build.xml#L147-L155]inclusion in build.xml leads to _../cassandra/build.xml:147: Unable to create javax script engine for javascript,_ related to the Nashorn removal. My initial try to solve this didn't work. I left it for later as a lower priority task. - ant updated; probably other dependencies will have to be updated too > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > This ticket is intended to group all issues found to support Java 17 in the > future. -- 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-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412148#comment-17412148 ] Ekaterina Dimitrova edited comment on CASSANDRA-16895 at 9/8/21, 7:22 PM: -- Some initial thoughts after some initial work done to remove Java 8 and add Java 17 for trunk: -The Nashorn engine has been deprecated in JDK 11 as part of [JEP 335|https://openjdk.java.net/jeps/335] and and has been removed from JDK15 as part of [JEP 372|https://openjdk.java.net/jeps/372]. GraalVM can step in as a replacement for JavaScript code previously executed on the Nashorn engine. GraalVM provides all the features for JavaScript previously provided by Nashorn. Working on this part now. - We will need more -add-exports and --add-opens as Java 17 is quite restrictive. - Currently [this script |https://github.com/apache/cassandra/blob/trunk/build.xml#L147-L155]inclusion in build.xml leads to _../cassandra/build.xml:147: Unable to create javax script engine for javascript,_ related to the Nashorn removal. My initial try to solve this didn't work. I left it for later as a lower priority task. - ant updated; probably other dependencies will have to be updated too was (Author: e.dimitrova): Some initial thoughts after some initial work done to remove Java 8 and add Java 17 for trunk: -The Nashorn engine has been deprecated in JDK 11 as part of [JEP 335|https://openjdk.java.net/jeps/335] and and has been removed from JDK15 as part of [JEP 372|https://openjdk.java.net/jeps/372]. GraalVM can step in as a replacement for JavaScript code previously executed on the Nashorn engine. GraalVM provides all the features for JavaScript previously provided by Nashorn. Working on this part now. -We will need more --add-exports and --add-opens as Java 17 is quite restrictive. - Currently [this script |https://github.com/apache/cassandra/blob/trunk/build.xml#L147-L155]inclusion in build.xml leads to _../cassandra/build.xml:147: Unable to create javax script engine for javascript,_ related to the Nashorn removal. My initial try to solve this didn't work. I left it for later as a lower priority task. - ant updated; probably other dependencies will have to be updated too > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > This ticket is intended to group all issues found to support Java 17 in the > future. -- 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-16929) CEP-10: General Improvements (Phase 2)
[ https://issues.apache.org/jira/browse/CASSANDRA-16929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-16929: --- Change Category: Quality Assurance Complexity: Challenging Component/s: Test/burn Status: Open (was: Triage Needed) > CEP-10: General Improvements (Phase 2) > -- > > Key: CASSANDRA-16929 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16929 > Project: Cassandra > Issue Type: Improvement > Components: Test/burn >Reporter: Benedict Elliott Smith >Priority: Normal > > This is a tracking Jira for work related to CEP-10 -- 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-16922) CEP-10: Major Prerequisites (Phase 1)
[ https://issues.apache.org/jira/browse/CASSANDRA-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-16922: --- Change Category: Code Clarity Complexity: Challenging Component/s: Test/burn Status: Open (was: Triage Needed) > CEP-10: Major Prerequisites (Phase 1) > - > > Key: CASSANDRA-16922 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16922 > Project: Cassandra > Issue Type: Improvement > Components: Test/burn >Reporter: Benedict Elliott Smith >Priority: Normal > > This is a tracking Jira for major pre-requisite system refactors for CEP-10 -- 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-16921) CEP-10: Cluster and Code Simulations
[ https://issues.apache.org/jira/browse/CASSANDRA-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-16921: --- Change Category: Quality Assurance Complexity: Challenging Component/s: Test/burn Status: Open (was: Triage Needed) > CEP-10: Cluster and Code Simulations > > > Key: CASSANDRA-16921 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16921 > Project: Cassandra > Issue Type: Improvement > Components: Test/burn >Reporter: Benedict Elliott Smith >Priority: Normal > > This is a tracking Jira for CEP-10: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-10%3A+Cluster+and+Code+Simulations -- 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-16933) CEP-10: Simulator Paxos Compatibility (Phase 3)
[ https://issues.apache.org/jira/browse/CASSANDRA-16933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-16933: --- Summary: CEP-10: Simulator Paxos Compatibility (Phase 3) (was: CEP-10: Simulator Paxos Compatibility) > CEP-10: Simulator Paxos Compatibility (Phase 3) > --- > > Key: CASSANDRA-16933 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16933 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Priority: Normal > > This is a tracking ticket for improvements to present-day Paxos to support > verification by the simulator -- 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-16936) Support atomic addition and append for LWTs
Benedict Elliott Smith created CASSANDRA-16936: -- Summary: Support atomic addition and append for LWTs Key: CASSANDRA-16936 URL: https://issues.apache.org/jira/browse/CASSANDRA-16936 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith To support CEP-10 we require some atomic functionality that modifies the state of a register as part of the transaction. Specifically, we require at least the ability to append a string to another string. Since this is more widely useful, at the same time we also support addition on numeric fields so that users may maintain precise counters using Paxos, should they wish. -- 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-16935) Use paxos_variant to specify Paxos behaviour
Benedict Elliott Smith created CASSANDRA-16935: -- Summary: Use paxos_variant to specify Paxos behaviour Key: CASSANDRA-16935 URL: https://issues.apache.org/jira/browse/CASSANDRA-16935 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith This patch introduces a config property for specifying the desired Paxos implementation and semantics. Initially, this will support only v1_norrl and v2, with “norrl” meaning “no read/read linearizability” i.e. supporting those use cases that need to restore prior performance, but only for read/read interactions. -- 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-16934) Use Synchronized for Paxos Concurrency Control
Benedict Elliott Smith created CASSANDRA-16934:
--
Summary: Use Synchronized for Paxos Concurrency Control
Key: CASSANDRA-16934
URL: https://issues.apache.org/jira/browse/CASSANDRA-16934
Project: Cassandra
Issue Type: Improvement
Reporter: Benedict Elliott Smith
For CEP-10 compatibility we must use the {{synchronized}} keyword for mutual
exclusion rather than Guava striped locks. This patch refactors the current
Paxos implementation to support this.
--
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-16933) CEP-10: Simulator Paxos Compatibility
Benedict Elliott Smith created CASSANDRA-16933: -- Summary: CEP-10: Simulator Paxos Compatibility Key: CASSANDRA-16933 URL: https://issues.apache.org/jira/browse/CASSANDRA-16933 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith This is a tracking ticket for improvements to present-day Paxos to support verification by the simulator -- 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-16932) Gossip Fixes
Benedict Elliott Smith created CASSANDRA-16932: -- Summary: Gossip Fixes Key: CASSANDRA-16932 URL: https://issues.apache.org/jira/browse/CASSANDRA-16932 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith Testing with CEP-10 discovered faults with gossip where status updates may be processed in an order that invalidates their application. These fixes are necessary for simulation to run correctly, but also potentially affect gossip time to settle. -- 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-16931) Improvements to @Shared annotation
Benedict Elliott Smith created CASSANDRA-16931: -- Summary: Improvements to @Shared annotation Key: CASSANDRA-16931 URL: https://issues.apache.org/jira/browse/CASSANDRA-16931 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith To support CEP-10 it is necessary to expand our functionality for selectively sharing classes between class loaders. This ticket introduces functionality to specify various recursive scopes of sharing, so that you may specify that any transitive dependencies of the class or interface may be also shared. That is, you may specify that those types necessary to implement or invoke methods on the class or interface must also be shared, that inner classes and types may also be shared, and that parent classes (and their inner classes and API dependencies) may also be shared. Additionally, validation has been added to ensure that the specified sharing level encompasses the transitive closure of classes that will need to be loaded to use a class. -- 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-16930) Introduce Determinism (and other) Configuration Options
Benedict Elliott Smith created CASSANDRA-16930: -- Summary: Introduce Determinism (and other) Configuration Options Key: CASSANDRA-16930 URL: https://issues.apache.org/jira/browse/CASSANDRA-16930 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith In order to support CEP-10 we must enable deterministic execution within Cassandra, support disabling certain optional features that are incompatible with simulation, and support overriding some existing features. Some determinism will be enabled by the Simulator itself, but there are aspects of Cassandra that must be made compliant as well. This includes: compression system-wide, memtable overhead computation, specifying the number of processors used for computation/decisions, specifing all cache sizes explicitly, enabling deterministic table IDs, and supporting deterministic node IDs for TimeUUID creation. We also want to be able disable sstable activity tracking, and to be able to happily ignore problems with native filesystem methods and SIGAR. We also want to be able to override the migration delay, batch sync interval and system auth replication factor. For pluggability we also want to be able to specify a custom FailureDetector. -- 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-16929) CEP-10: General Improvements (Phase 2)
Benedict Elliott Smith created CASSANDRA-16929: -- Summary: CEP-10: General Improvements (Phase 2) Key: CASSANDRA-16929 URL: https://issues.apache.org/jira/browse/CASSANDRA-16929 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith This is a tracking Jira for work related to CEP-10 -- 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-16928) InetAddressAndPort to extend InetAddress
Benedict Elliott Smith created CASSANDRA-16928: -- Summary: InetAddressAndPort to extend InetAddress Key: CASSANDRA-16928 URL: https://issues.apache.org/jira/browse/CASSANDRA-16928 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith Logically InetAddressAndPort encapsulates the same information as a simple InetAddress. Importantly, InetAddressAndPort cannot easily be unpicked from its dependencies that prohibit it being shared between classloaders. So our in-jvm dtest API instead uses SocketAddress. To support a clean and efficient Streaming API we need to be able to treat InetAddressAndPort as such a cross-classloader type. -- 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-16927) Mockable Streaming
Benedict Elliott Smith created CASSANDRA-16927: -- Summary: Mockable Streaming Key: CASSANDRA-16927 URL: https://issues.apache.org/jira/browse/CASSANDRA-16927 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith To support CEP-10 it is necessary to support alternative streaming implementations, so that execution may be controlled. The ticket encompasses two sub-tickets: firstly we make InetAddressAndPort extend InetAddress so that we may 2) introduce a cross-classloader API for establishing a streaming connection and sending data over it. -- 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-16925) Task Execution
Benedict Elliott Smith created CASSANDRA-16925: -- Summary: Task Execution Key: CASSANDRA-16925 URL: https://issues.apache.org/jira/browse/CASSANDRA-16925 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith To support CEP-10 it is necessary to support alternative executor implementations that may be externally controlled. This ticket introduces an ExecutorFactory, and all executor creation is migrated to this facility. The codebase’s use of executors is inconsistent, and relatedly there are divergent Future APIs in use, with Netty, Guava and Java APIs in use in various places. To improve consistency we introduce our own Future API that implements all of the above, as well as providing other additional ergonomic improvements. We introduce a new ExecutorPlus API that extends Executor to supply this extended Future API. All executors and futures are ported to these new APIs to improve coherency in the codebase, and to support consistently mocking these implementations. DebuggableThreadPoolExecutor and its hierarchy is replaced with ThreadPoolExecutorBase, ThreadPoolExecutorPlus and extending classes with consistent names, implementations and configurability. Additionally the ExecutorFactory takes over the allocation of new threads, and provides a new InfiniteLoopExecutorfacility for common paradigms. -- 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-16926) Mockable FileSystem
Benedict Elliott Smith created CASSANDRA-16926: -- Summary: Mockable FileSystem Key: CASSANDRA-16926 URL: https://issues.apache.org/jira/browse/CASSANDRA-16926 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith To support CEP-10 it is necessary to support alternative file system implementations so that execution may be consistent between hosts. This ticket introduces a new File API backed by Path objects, and all File usages are ported to it. This necessitates the migration away from RandomAccessReader, but otherwise the change is mostly straight-forward, if quite expansive. -- 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-16923) System Clock
Benedict Elliott Smith created CASSANDRA-16923: -- Summary: System Clock Key: CASSANDRA-16923 URL: https://issues.apache.org/jira/browse/CASSANDRA-16923 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith To support CEP-10 and other project testing goals, it is necessary to support supplying a non-standard time source that can be externally controlled. This ticket modifies existing abstractions and migrates all calls to System.currentTimeMillis() and System.nanoTime() to these APIs. -- 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-16924) Blocking Concurrency Primitives
Benedict Elliott Smith created CASSANDRA-16924: -- Summary: Blocking Concurrency Primitives Key: CASSANDRA-16924 URL: https://issues.apache.org/jira/browse/CASSANDRA-16924 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith To support CEP-10 it is necessary to support alternative implementations of the blocking concurrency primitives we use on the project. At the same time, the project is very inconsistent in its usage of these APIs, so this work includes a number of improvements to the coherency of the codebase. This ticket introduces new abstractions and standardises old ones, migrating all blocking concurrency operations besides Futures returned by Executors to these new APIs. This includes a migration of SimpleCondition to a new Conditioninterface, new CountDownLatch and Semaphore interfaces, and new static factory methods for creating these objects (as well as WaitQueue) that can be intercepted by byte weaving. Additionally the internal Netty Future implementation is improved to support more general use (though this is only fully realised in a later ticket), OpOrder is improved to more easily support mocking WaitQueue. Finally we standardise the propagation of InterruptedExecption, with the new UncheckedInterruptedException, so that simulations may be terminated cleanly. -- 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-16922) CEP-10: Major Prerequisites (Phase 1)
Benedict Elliott Smith created CASSANDRA-16922: -- Summary: CEP-10: Major Prerequisites (Phase 1) Key: CASSANDRA-16922 URL: https://issues.apache.org/jira/browse/CASSANDRA-16922 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith This is a tracking Jira for major pre-requisite system refactors for CEP-10 -- 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-16921) CEP-10: Cluster and Code Simulations
Benedict Elliott Smith created CASSANDRA-16921: -- Summary: CEP-10: Cluster and Code Simulations Key: CASSANDRA-16921 URL: https://issues.apache.org/jira/browse/CASSANDRA-16921 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith This is a tracking Jira for CEP-10: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-10%3A+Cluster+and+Code+Simulations -- 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-16901) Optimize heavily-used `String.format()`-with-constant formatter use cases
[
https://issues.apache.org/jira/browse/CASSANDRA-16901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412104#comment-17412104
]
David Capwell commented on CASSANDRA-16901:
---
do you have any cluster benchmarks showing any branches impacted? I agree
String.format is slow but it shouldn't really be common in the hot path (else
this ticket could get some nice wins)
> Optimize heavily-used `String.format()`-with-constant formatter use cases
> -
>
> Key: CASSANDRA-16901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16901
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Tatu Saloranta
>Priority: Normal
>
> For background, I did some benchmarking to compare performance of two simple
> ways to concatenate 2 Strings with a separator (used in f.ex
> `QualifiedName.java` for "keyspace:name" concatenation):
> # String.format("%s.%s", keyspace, name);
> # new StringBuilder().append(keyspace).append('.').append(name).toString()
> Difference is somewhat significant (for me, factor of 40x), as per:
> https://cowtowncoder.medium.com/measuring-performance-of-java-string-format-or-lack-thereof-2e1c6a13362c
> and so it seems worthwhile replacing at least some of usage from Cassandra.
> With a quick look it seems that classes like:
> * QualifiedName.java, FieldSelector.java, Selectable.java (in cql3)
> could benefit from this. And the second implementation can be packaged as a
> simple utility method (concatenateStringsWithChar?) so that code should be as
> readable as before.
> I can provide a patch, or if anyone else wants to have a go, feel free to.
>
>
>
--
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-16847) nodetool assassinate of a node that failed bootstrap may lead to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16847:
-
Fix Version/s: (was: 4.0.x)
(was: 3.11.x)
4.0.2
3.11.12
> nodetool assassinate of a node that failed bootstrap may lead to
> IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16847
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Membership,
> Consistency/Bootstrap and Decommission
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.12, 4.0.2
>
>
> User [Yorick|https://the-asf.slack.com/team/U026YMYS2QN] reported on ASF
> Slack that a node which failed to bootstrap is stuck in {{hibernate}} status
> and persists in {{gossipinfo}}:
> {noformat}
> /10.x.x.108
> generation:1625493756
> heartbeat:86
> STATUS:2:hibernate,true
> LOAD:79:96124.0
> SCHEMA:14:59adb24e-f3cd-3e02-97f0-5b395827453f
> DC:10:DC1
> RACK:12:RAC3
> RELEASE_VERSION:6:3.11.10
> INTERNAL_IP:8:10.x.x.108
> RPC_ADDRESS:5:10.x.x.108
> NET_VERSION:3:11
> HOST_ID:4:5b254d51-fc58-4ca2-856f-fe7878752131
> TOKENS:1: {noformat}
> Attempts to assassinate the node returns {{IndexOutOfBoundsException}}:
> {noformat}
> ERROR [GossipStage:1] 2021-08-11 09:10:03,440 CassandraDaemon.java:244 -
> Exception in thread Thread[GossipStage:1,5,main]
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:659) ~[na:1.8.0_292]
> at java.util.ArrayList.get(ArrayList.java:435) ~[na:1.8.0_292]
> at com.google.common.collect.Iterables.get(Iterables.java:728)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.makeTokenString(VersionedValue.java:156)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.left(VersionedValue.java:178)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.Gossiper.lambda$assassinateEndpoint$1(Gossiper.java:695)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_292]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_292]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_292] {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] [Updated] (CASSANDRA-16847) nodetool assassinate of a node that failed bootstrap may lead to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16847:
-
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/5cdddcf393145b4fb794cc4a73391fad78f58bac
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks. Committed.
> nodetool assassinate of a node that failed bootstrap may lead to
> IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16847
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Membership,
> Consistency/Bootstrap and Decommission
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> User [Yorick|https://the-asf.slack.com/team/U026YMYS2QN] reported on ASF
> Slack that a node which failed to bootstrap is stuck in {{hibernate}} status
> and persists in {{gossipinfo}}:
> {noformat}
> /10.x.x.108
> generation:1625493756
> heartbeat:86
> STATUS:2:hibernate,true
> LOAD:79:96124.0
> SCHEMA:14:59adb24e-f3cd-3e02-97f0-5b395827453f
> DC:10:DC1
> RACK:12:RAC3
> RELEASE_VERSION:6:3.11.10
> INTERNAL_IP:8:10.x.x.108
> RPC_ADDRESS:5:10.x.x.108
> NET_VERSION:3:11
> HOST_ID:4:5b254d51-fc58-4ca2-856f-fe7878752131
> TOKENS:1: {noformat}
> Attempts to assassinate the node returns {{IndexOutOfBoundsException}}:
> {noformat}
> ERROR [GossipStage:1] 2021-08-11 09:10:03,440 CassandraDaemon.java:244 -
> Exception in thread Thread[GossipStage:1,5,main]
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:659) ~[na:1.8.0_292]
> at java.util.ArrayList.get(ArrayList.java:435) ~[na:1.8.0_292]
> at com.google.common.collect.Iterables.get(Iterables.java:728)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.makeTokenString(VersionedValue.java:156)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.left(VersionedValue.java:178)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.Gossiper.lambda$assassinateEndpoint$1(Gossiper.java:695)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_292]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_292]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_292] {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] [Updated] (CASSANDRA-16847) nodetool assassinate of a node that failed bootstrap may lead to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16847:
-
Status: Review In Progress (was: Needs Committer)
> nodetool assassinate of a node that failed bootstrap may lead to
> IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16847
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Membership,
> Consistency/Bootstrap and Decommission
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> User [Yorick|https://the-asf.slack.com/team/U026YMYS2QN] reported on ASF
> Slack that a node which failed to bootstrap is stuck in {{hibernate}} status
> and persists in {{gossipinfo}}:
> {noformat}
> /10.x.x.108
> generation:1625493756
> heartbeat:86
> STATUS:2:hibernate,true
> LOAD:79:96124.0
> SCHEMA:14:59adb24e-f3cd-3e02-97f0-5b395827453f
> DC:10:DC1
> RACK:12:RAC3
> RELEASE_VERSION:6:3.11.10
> INTERNAL_IP:8:10.x.x.108
> RPC_ADDRESS:5:10.x.x.108
> NET_VERSION:3:11
> HOST_ID:4:5b254d51-fc58-4ca2-856f-fe7878752131
> TOKENS:1: {noformat}
> Attempts to assassinate the node returns {{IndexOutOfBoundsException}}:
> {noformat}
> ERROR [GossipStage:1] 2021-08-11 09:10:03,440 CassandraDaemon.java:244 -
> Exception in thread Thread[GossipStage:1,5,main]
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:659) ~[na:1.8.0_292]
> at java.util.ArrayList.get(ArrayList.java:435) ~[na:1.8.0_292]
> at com.google.common.collect.Iterables.get(Iterables.java:728)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.makeTokenString(VersionedValue.java:156)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.left(VersionedValue.java:178)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.Gossiper.lambda$assassinateEndpoint$1(Gossiper.java:695)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_292]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_292]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_292] {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] [Updated] (CASSANDRA-16847) nodetool assassinate of a node that failed bootstrap may lead to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16847:
-
Status: Ready to Commit (was: Review In Progress)
> nodetool assassinate of a node that failed bootstrap may lead to
> IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16847
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Membership,
> Consistency/Bootstrap and Decommission
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> User [Yorick|https://the-asf.slack.com/team/U026YMYS2QN] reported on ASF
> Slack that a node which failed to bootstrap is stuck in {{hibernate}} status
> and persists in {{gossipinfo}}:
> {noformat}
> /10.x.x.108
> generation:1625493756
> heartbeat:86
> STATUS:2:hibernate,true
> LOAD:79:96124.0
> SCHEMA:14:59adb24e-f3cd-3e02-97f0-5b395827453f
> DC:10:DC1
> RACK:12:RAC3
> RELEASE_VERSION:6:3.11.10
> INTERNAL_IP:8:10.x.x.108
> RPC_ADDRESS:5:10.x.x.108
> NET_VERSION:3:11
> HOST_ID:4:5b254d51-fc58-4ca2-856f-fe7878752131
> TOKENS:1: {noformat}
> Attempts to assassinate the node returns {{IndexOutOfBoundsException}}:
> {noformat}
> ERROR [GossipStage:1] 2021-08-11 09:10:03,440 CassandraDaemon.java:244 -
> Exception in thread Thread[GossipStage:1,5,main]
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:659) ~[na:1.8.0_292]
> at java.util.ArrayList.get(ArrayList.java:435) ~[na:1.8.0_292]
> at com.google.common.collect.Iterables.get(Iterables.java:728)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.makeTokenString(VersionedValue.java:156)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.left(VersionedValue.java:178)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.Gossiper.lambda$assassinateEndpoint$1(Gossiper.java:695)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_292]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_292]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_292] {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
[cassandra] branch trunk updated (dcee430 -> b8f786d)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from dcee430 Add support for filtering using IN restrictions new 5cdddcf Make assassinate more resilient to missing tokens new ffc6593 Merge branch 'cassandra-3.11' into cassandra-4.0 new b8f786d Merge branch 'cassandra-4.0' into trunk The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 7 +++ src/java/org/apache/cassandra/gms/Gossiper.java | 8 +--- src/java/org/apache/cassandra/locator/TokenMetadata.java | 2 +- 3 files changed, 13 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (d90cd51 -> ffc6593)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d90cd51 Fix CHANGES.txt entries after bumping version to 4.0.2 new 5cdddcf Make assassinate more resilient to missing tokens new ffc6593 Merge branch 'cassandra-3.11' into cassandra-4.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 2 ++ src/java/org/apache/cassandra/gms/Gossiper.java | 8 +--- src/java/org/apache/cassandra/locator/TokenMetadata.java | 2 +- 3 files changed, 8 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit ffc6593d06d119fb98e930b966b13c5461df6052
Merge: d90cd51 5cdddcf
Author: Brandon Williams
AuthorDate: Wed Sep 8 11:49:05 2021 -0500
Merge branch 'cassandra-3.11' into cassandra-4.0
CHANGES.txt | 2 ++
src/java/org/apache/cassandra/gms/Gossiper.java | 8 +---
src/java/org/apache/cassandra/locator/TokenMetadata.java | 2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
diff --cc CHANGES.txt
index 9ed275e,f589208..0ff0ffe
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,28 -1,25 +1,30 @@@
-3.11.12
- * Make assassinate more resilient to missing tokens (CASSANDRA-16847)
+4.0.2
+ * Delay auth setup until after gossip has settled to avoid unavailables on
startup (CASSANDRA-16783)
+ * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898)
+ * org.apache.cassandra.db.rows.ArrayCell#unsharedHeapSizeExcludingData
includes data twice (CASSANDRA-16900)
* Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies
(CASSANDRA-16854)
- * Validate SASI tokenizer options before adding index to schema
(CASSANDRA-15135)
- * Fixup scrub output when no data post-scrub and clear up old use of row,
which really means partition (CASSANDRA-16835)
- * Fix ant-junit dependency issue (CASSANDRA-16827)
- * Reduce thread contention in CommitLogSegment and HintsBuffer
(CASSANDRA-16072)
- * Avoid sending CDC column if not enabled (CASSANDRA-16770)
++Merged from 3.11:
++ * Make assassinate more resilient to missing tokens (CASSANDRA-16847)
Merged from 3.0:
* Make the addition of regular column to COMPACT tables throw an
InvalidRequestException (CASSANDRA-14564)
- * Fix materialized view schema backup as table (CASSANDRA-12734)
- * Avoid signaling DigestResolver until the minimum number of responses are
guaranteed to be visible (CASSANDRA-16883)
- * Fix secondary indexes on primary key columns skipping some writes
(CASSANDRA-16868)
- * Fix incorrect error message in LegacyLayout (CASSANDRA-15136)
- * Use JMX to validate nodetool --jobs parameter (CASSANDRA-16104)
- * Handle properly UnsatisfiedLinkError in NativeLibrary#getProcessID()
(CASSANDRA-16578)
- * Remove mutation data from error log message (CASSANDRA-16817)
-Merged from 2.2:
- * Add python2 location to RPMs (CASSANDRA-16822)
-
-3.11.11
+4.0.1
+ * Tolerate missing DNS entry when completing a host replacement
(CASSANDRA-16873)
+ * Harden PrunableArrayQueue against Pruner implementations that might throw
exceptions (CASSANDRA-16866)
+ * Move RepairedDataInfo to the execution controller rather than the
ReadCommand to avoid unintended sharing (CASSANDRA-16721)
+ * Bump zstd-jni version to 1.5.0-4 (CASSANDRA-16884)
+ * Remove assumption that all urgent messages are small (CASSANDRA-16877)
+ * ArrayClustering.unsharedHeapSize does not include the data so undercounts
the heap size (CASSANDRA-16845)
+ * Improve help, doc and error messages about sstabledump -k and -x arguments
(CASSANDRA-16818)
+ * Add repaired/unrepaired bytes back to nodetool (CASSANDRA-15282)
+ * Upgrade lz4-java to 1.8.0 to add RH6 support back (CASSANDRA-16753)
+ * Improve DiagnosticEventService.publish(event) logging message of events
(CASSANDRA-16749)
+ * Cleanup dependency scopes (CASSANDRA-16704)
+ * Make JmxHistogram#getRecentValues() and JmxTimer#getRecentValues()
thread-safe (CASSANDRA-16707)
+Merged from 3.11:
+ * Validate SASI tokenizer options before adding index to schema
(CASSANDRA-15135)
+ * Fixup scrub output when no data post-scrub and clear up old use of row,
which really means partition (CASSANDRA-16835)
+ * Reduce thread contention in CommitLogSegment and HintsBuffer
(CASSANDRA-16072)
* Make cqlsh use the same set of reserved keywords than the server uses
(CASSANDRA-15663)
* Optimize bytes skipping when reading SSTable files (CASSANDRA-14415)
* Enable tombstone compactions when unchecked_tombstone_compaction is set in
TWCS (CASSANDRA-14496)
diff --cc src/java/org/apache/cassandra/gms/Gossiper.java
index 2c38cfb,08cd106..6eb674f
--- a/src/java/org/apache/cassandra/gms/Gossiper.java
+++ b/src/java/org/apache/cassandra/gms/Gossiper.java
@@@ -770,10 -655,9 +770,9 @@@ public class Gossiper implements IFailu
*/
public void assassinateEndpoint(String address) throws
UnknownHostException
{
-InetAddress endpoint = InetAddress.getByName(address);
+InetAddressAndPort endpoint = InetAddressAndPort.getByName(address);
runInGossipStageBlocking(() -> {
EndpointState epState = endpointStateMap.get(endpoint);
- Collection tokens;
logger.warn("Assassinating {} via gossip", endpoint);
if (epState == null)
diff --cc
[cassandra] branch cassandra-3.11 updated: Make assassinate more resilient to missing tokens
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new 5cdddcf Make assassinate more resilient to missing tokens
5cdddcf is described below
commit 5cdddcf393145b4fb794cc4a73391fad78f58bac
Author: Brandon Williams
AuthorDate: Thu Aug 12 10:48:17 2021 -0500
Make assassinate more resilient to missing tokens
Patch by Robert Stupp and brandonwilliams; reviewed by adelapena for
CASSANDRA-16847
---
CHANGES.txt | 1 +
src/java/org/apache/cassandra/gms/Gossiper.java | 8 +---
src/java/org/apache/cassandra/locator/TokenMetadata.java | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index b9668c9..f589208 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.11.12
+ * Make assassinate more resilient to missing tokens (CASSANDRA-16847)
* Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies
(CASSANDRA-16854)
* Validate SASI tokenizer options before adding index to schema
(CASSANDRA-15135)
* Fixup scrub output when no data post-scrub and clear up old use of row,
which really means partition (CASSANDRA-16835)
diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java
b/src/java/org/apache/cassandra/gms/Gossiper.java
index 1603693..08cd106 100644
--- a/src/java/org/apache/cassandra/gms/Gossiper.java
+++ b/src/java/org/apache/cassandra/gms/Gossiper.java
@@ -658,7 +658,6 @@ public class Gossiper implements
IFailureDetectionEventListener, GossiperMBean
InetAddress endpoint = InetAddress.getByName(address);
runInGossipStageBlocking(() -> {
EndpointState epState = endpointStateMap.get(endpoint);
-Collection tokens = null;
logger.warn("Assassinating {} via gossip", endpoint);
if (epState == null)
@@ -683,6 +682,7 @@ public class Gossiper implements
IFailureDetectionEventListener, GossiperMBean
epState.getHeartBeatState().forceNewerGenerationUnsafe();
}
+Collection tokens = null;
try
{
tokens =
StorageService.instance.getTokenMetadata().getTokens(endpoint);
@@ -690,8 +690,10 @@ public class Gossiper implements
IFailureDetectionEventListener, GossiperMBean
catch (Throwable th)
{
JVMStabilityInspector.inspectThrowable(th);
-// TODO this is broken
-logger.warn("Unable to calculate tokens for {}. Will use a
random one", address);
+}
+if (tokens == null || tokens.isEmpty())
+{
+logger.warn("Trying to assassinate an endpoint {} that does
not have any tokens assigned. This should not have happened, trying to continue
with a random token.", address);
tokens =
Collections.singletonList(StorageService.instance.getTokenMetadata().partitioner.getRandomToken());
}
diff --git a/src/java/org/apache/cassandra/locator/TokenMetadata.java
b/src/java/org/apache/cassandra/locator/TokenMetadata.java
index cdd3885..8300a39 100644
--- a/src/java/org/apache/cassandra/locator/TokenMetadata.java
+++ b/src/java/org/apache/cassandra/locator/TokenMetadata.java
@@ -559,11 +559,11 @@ public class TokenMetadata
public Collection getTokens(InetAddress endpoint)
{
assert endpoint != null;
-assert isMember(endpoint); // don't want to return nulls
lock.readLock().lock();
try
{
+assert isMember(endpoint); // don't want to return nulls
return new ArrayList<>(tokenToEndpointMap.inverse().get(endpoint));
}
finally
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b8f786d387ec0b023bd6fe61bc012d8f8dc95301 Merge: dcee430 ffc6593 Author: Brandon Williams AuthorDate: Wed Sep 8 11:50:33 2021 -0500 Merge branch 'cassandra-4.0' into trunk CHANGES.txt | 7 +++ src/java/org/apache/cassandra/gms/Gossiper.java | 8 +--- src/java/org/apache/cassandra/locator/TokenMetadata.java | 2 +- 3 files changed, 13 insertions(+), 4 deletions(-) diff --cc CHANGES.txt index 5d4c20f,0ff0ffe..f3b0f76 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,33 -1,16 +1,40 @@@ -4.0.2 +4.1 + * Add support for filtering using IN restrictions (CASSANDRA-14344) + * Provide a nodetool command to invalidate auth caches (CASSANDRA-16404) + * Catch read repair timeout exceptions and add metric (CASSANDRA-16880) + * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) + * Add client warnings and abort to tombstone and coordinator reads which go past a low/high watermark (CASSANDRA-16850) + * Add TTL support to nodetool snapshots (CASSANDRA-16789) + * Allow CommitLogSegmentReader to optionally skip sync marker CRC checks (CASSANDRA-16842) + * allow blocking IPs from updating metrics about traffic (CASSANDRA-16859) + * Request-Based Native Transport Rate-Limiting (CASSANDRA-16663) + * Implement nodetool getauditlog command (CASSANDRA-16725) + * Clean up repair code (CASSANDRA-13720) + * Background schedule to clean up orphaned hints files (CASSANDRA-16815) + * Modify SecondaryIndexManager#indexPartition() to retrieve only columns for which indexes are actually being built (CASSANDRA-16776) + * Batch the token metadata update to improve the speed (CASSANDRA-15291) + * Reduce the log level on "expected" repair exceptions (CASSANDRA-16775) + * Make JMXTimer expose attributes using consistent time unit (CASSANDRA-16760) + * Remove check on gossip status from DynamicEndpointSnitch::updateScores (CASSANDRA-11671) + * Fix AbstractReadQuery::toCQLString not returning valid CQL (CASSANDRA-16510) + * Log when compacting many tombstones (CASSANDRA-16780) + * Display bytes per level in tablestats for LCS tables (CASSANDRA-16799) + * Add isolated flush timer to CommitLogMetrics and ensure writes correspond to single WaitingOnCommit data points (CASSANDRA-16701) + * Add a system property to set hostId if not yet initialized (CASSANDRA-14582) + * GossiperTest.testHasVersion3Nodes didn't take into account trunk version changes, fixed to rely on latest version (CASSANDRA-16651) +Merged from 4.0: * Delay auth setup until after gossip has settled to avoid unavailables on startup (CASSANDRA-16783) - * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) * org.apache.cassandra.db.rows.ArrayCell#unsharedHeapSizeExcludingData includes data twice (CASSANDRA-16900) + * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) + * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) + Merged from 3.11: + * Make assassinate more resilient to missing tokens (CASSANDRA-16847) + Merged from 3.0: + * Make the addition of regular column to COMPACT tables throw an InvalidRequestException (CASSANDRA-14564) + + 4.0.1 * Tolerate missing DNS entry when completing a host replacement (CASSANDRA-16873) - * Harden PrunableArrayQueue against Pruner implementations that might throw exceptions (CASSANDRA-16866) + * Harden PrunableArrayQueue against Pruner implementations that might throw exceptions (CASSANDRA-16866) * Move RepairedDataInfo to the execution controller rather than the ReadCommand to avoid unintended sharing (CASSANDRA-16721) * Bump zstd-jni version to 1.5.0-4 (CASSANDRA-16884) * Remove assumption that all urgent messages are small (CASSANDRA-16877) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412075#comment-17412075
]
Jack Casey commented on CASSANDRA-16860:
Hey [~stefan.miklosovic], thank you for following up!
I'm still planning on working on this, a few things have come up personally so
I've been quite busy, but hoping to get this done in the near future!
I have the code in place to determine snapshots via name, however am still
working on getting this to work with the functionality added in [this
change|https://github.com/apache/cassandra/pull/1046/files].
Please do not hesitate if you have any feedback!
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Jack Casey
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CASSANDRA-16915) Delay is not applied in the dtest to test bootstrap delay
[
https://issues.apache.org/jira/browse/CASSANDRA-16915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruslan Fomkin updated CASSANDRA-16915:
--
Resolution: Invalid
Status: Resolved (was: Triage Needed)
After investigating with byteman verbosity it became clear that the rule and
the test work as expected. So no issue.
> Delay is not applied in the dtest to test bootstrap delay
> -
>
> Key: CASSANDRA-16915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16915
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Priority: Normal
>
> Test
> [test_bootstrap_waits_for_streaming_to_finish|https://github.com/apache/cassandra-dtest/blob/trunk/bootstrap_test.py#L267]
> supposed to delay bootstrap of {{node2}} by using byteman :
> {code:java}
> node2 = new_node(cluster, byteman_port='4200')
> node2.update_startup_byteman_script('./byteman/bootstrap_5s_sleep.btm')
> {code}
> where [byteman
> code|https://github.com/apache/cassandra-dtest/blob/trunk/byteman/bootstrap_5s_sleep.btm]
> is:
> {code:java}
> RULE Sleep 5s when finishing bootstrap
> CLASS org.apache.cassandra.service.StorageService
> METHOD bootstrapFinished
> AT ENTRY
> IF NOT flagged("done")
> DO
> flag("done");
> Thread.sleep(5000)
> ENDRULE
> {code}
> However, I found that this byteman rule is not applied.
> For example, I changed the rule body into:
> {code:java}
> ...
> IF TRUE
> DO
> asfa;adfa;
> flag("done");
> throw new RuntimeException("Test");
> Thread.sleep(5)
> ENDRULE{code}
> So my conclusion is that the delay is not applied. I haven't investigated if
> it is the issue in calling {{update_startup_byteman_script}}, which is
> implemented in CCM, or in the implementation inside CCM.
> This issue might exist in other similar tests.
>
>
--
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-16915) Delay is not applied in the dtest to test bootstrap delay
[
https://issues.apache.org/jira/browse/CASSANDRA-16915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411964#comment-17411964
]
Ruslan Fomkin edited comment on CASSANDRA-16915 at 9/8/21, 2:22 PM:
Thank you! It helped me to find that the rule is called and used.
Closing the ticket as invalid.
was (Author: k-rus):
Thank you! It helped me to find that the rule is called and used.
> Delay is not applied in the dtest to test bootstrap delay
> -
>
> Key: CASSANDRA-16915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16915
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Priority: Normal
>
> Test
> [test_bootstrap_waits_for_streaming_to_finish|https://github.com/apache/cassandra-dtest/blob/trunk/bootstrap_test.py#L267]
> supposed to delay bootstrap of {{node2}} by using byteman :
> {code:java}
> node2 = new_node(cluster, byteman_port='4200')
> node2.update_startup_byteman_script('./byteman/bootstrap_5s_sleep.btm')
> {code}
> where [byteman
> code|https://github.com/apache/cassandra-dtest/blob/trunk/byteman/bootstrap_5s_sleep.btm]
> is:
> {code:java}
> RULE Sleep 5s when finishing bootstrap
> CLASS org.apache.cassandra.service.StorageService
> METHOD bootstrapFinished
> AT ENTRY
> IF NOT flagged("done")
> DO
> flag("done");
> Thread.sleep(5000)
> ENDRULE
> {code}
> However, I found that this byteman rule is not applied.
> For example, I changed the rule body into:
> {code:java}
> ...
> IF TRUE
> DO
> asfa;adfa;
> flag("done");
> throw new RuntimeException("Test");
> Thread.sleep(5)
> ENDRULE{code}
> So my conclusion is that the delay is not applied. I haven't investigated if
> it is the issue in calling {{update_startup_byteman_script}}, which is
> implemented in CCM, or in the implementation inside CCM.
> This issue might exist in other similar tests.
>
>
--
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-16915) Delay is not applied in the dtest to test bootstrap delay
[
https://issues.apache.org/jira/browse/CASSANDRA-16915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411964#comment-17411964
]
Ruslan Fomkin commented on CASSANDRA-16915:
---
Thank you! It helped me to find that the rule is called and used.
> Delay is not applied in the dtest to test bootstrap delay
> -
>
> Key: CASSANDRA-16915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16915
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Priority: Normal
>
> Test
> [test_bootstrap_waits_for_streaming_to_finish|https://github.com/apache/cassandra-dtest/blob/trunk/bootstrap_test.py#L267]
> supposed to delay bootstrap of {{node2}} by using byteman :
> {code:java}
> node2 = new_node(cluster, byteman_port='4200')
> node2.update_startup_byteman_script('./byteman/bootstrap_5s_sleep.btm')
> {code}
> where [byteman
> code|https://github.com/apache/cassandra-dtest/blob/trunk/byteman/bootstrap_5s_sleep.btm]
> is:
> {code:java}
> RULE Sleep 5s when finishing bootstrap
> CLASS org.apache.cassandra.service.StorageService
> METHOD bootstrapFinished
> AT ENTRY
> IF NOT flagged("done")
> DO
> flag("done");
> Thread.sleep(5000)
> ENDRULE
> {code}
> However, I found that this byteman rule is not applied.
> For example, I changed the rule body into:
> {code:java}
> ...
> IF TRUE
> DO
> asfa;adfa;
> flag("done");
> throw new RuntimeException("Test");
> Thread.sleep(5)
> ENDRULE{code}
> So my conclusion is that the delay is not applied. I haven't investigated if
> it is the issue in calling {{update_startup_byteman_script}}, which is
> implemented in CCM, or in the implementation inside CCM.
> This issue might exist in other similar tests.
>
>
--
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-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411947#comment-17411947
]
Stefan Miklosovic commented on CASSANDRA-16860:
---
Hi [~jackcasey-visier], do you still plan to work on this issue and accommodate
it to current code and suggestions?
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Jack Casey
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
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-16920) Make creation timestamp consistent for all tables of a snapshot
[ https://issues.apache.org/jira/browse/CASSANDRA-16920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16920: Reviewers: Paulo Motta > Make creation timestamp consistent for all tables of a snapshot > --- > > Key: CASSANDRA-16920 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16920 > Project: Cassandra > Issue Type: Bug > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > This mostly affects listsnapshots command as well as removal of a snapshot > when it is on TTL. > Currently, there is not the same timestamp for "created_at" field in > listsnapshots output so what might happen when TTL deletion kicks in is that > only part of tables might be removed because other tables do not have to make > it into that TTL threshold but they will be removed on the next > SnapshotManager's removal round. -- 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-16451) Add ability to ttl snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16451:
--
Component/s: Local/Snapshots
> Add ability to ttl snapshots
>
>
> Key: CASSANDRA-16451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16451
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
> Labels: gsoc2021, mentor, pull-request-available
> Fix For: 4.x
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> It should be possible to add a TTL to snapshots, after which it automatically
> cleans itself up.
> This will be useful together with the {{auto_snapshot}} option, where you
> want to keep an emergency snapshot in case of accidental drop or truncation
> but automatically remove it after a specified period when it's no longer
> useful. So in addition to allowing a user to specify a snapshot ttl on
> {{nodetool snapshot}} we should have a {{auto_snapshot_ttl}} option that
> allows a user to set a ttl for automatic snaphots on drop/truncate.
--
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-16911) Remove ephemeral snapshot marker file and introduce a flag to SnapshotManifest
[ https://issues.apache.org/jira/browse/CASSANDRA-16911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16911: -- Component/s: (was: Local/Other) Local/Snapshots > Remove ephemeral snapshot marker file and introduce a flag to SnapshotManifest > -- > > Key: CASSANDRA-16911 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16911 > Project: Cassandra > Issue Type: Improvement > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > While creating an ephemeral snapshot, a marker file is created at disk in a > respective snapshot directory. This is not necessary anymore as we have > introduced SnapshotManifest in CASSANDRA-16789 so we can move this flag > there. By putting the information if a snapshot is ephemeral or not into > SnapshotManifest, we simplify and "clean up" the snapshotting process and > related codebase. -- 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-16790) Add auto_snapshot_ttl configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-16790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16790:
--
Component/s: Local/Snapshots
> 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, Local/Snapshots
>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] [Updated] (CASSANDRA-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16860:
--
Component/s: Local/Snapshots
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Jack Casey
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
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-16920) Make creation timestamp consistent for all tables of a snapshot
[ https://issues.apache.org/jira/browse/CASSANDRA-16920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16920: -- Test and Documentation Plan: unit test / dtest Status: Patch Available (was: Open) https://github.com/apache/cassandra/pull/1189 > Make creation timestamp consistent for all tables of a snapshot > --- > > Key: CASSANDRA-16920 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16920 > Project: Cassandra > Issue Type: Bug > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > This mostly affects listsnapshots command as well as removal of a snapshot > when it is on TTL. > Currently, there is not the same timestamp for "created_at" field in > listsnapshots output so what might happen when TTL deletion kicks in is that > only part of tables might be removed because other tables do not have to make > it into that TTL threshold but they will be removed on the next > SnapshotManager's removal round. -- 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-16843) auto-snapshots for dropped tables don't appear in nodetool listsnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16843:
--
Component/s: (was: Local/Other)
Local/Snapshots
> auto-snapshots for dropped tables don't appear in nodetool listsnapshots
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: James Brown
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16920) Make creation timestamp consistent for all tables of a snapshot
[ https://issues.apache.org/jira/browse/CASSANDRA-16920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16920: -- Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Discovered By: Adhoc Test Severity: Low Status: Open (was: Triage Needed) > Make creation timestamp consistent for all tables of a snapshot > --- > > Key: CASSANDRA-16920 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16920 > Project: Cassandra > Issue Type: Bug > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > This mostly affects listsnapshots command as well as removal of a snapshot > when it is on TTL. > Currently, there is not the same timestamp for "created_at" field in > listsnapshots output so what might happen when TTL deletion kicks in is that > only part of tables might be removed because other tables do not have to make > it into that TTL threshold but they will be removed on the next > SnapshotManager's removal round. -- 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-16920) Make creation timestamp consistent for all tables of a snapshot
Stefan Miklosovic created CASSANDRA-16920: - Summary: Make creation timestamp consistent for all tables of a snapshot Key: CASSANDRA-16920 URL: https://issues.apache.org/jira/browse/CASSANDRA-16920 Project: Cassandra Issue Type: Bug Components: Local/Snapshots Reporter: Stefan Miklosovic Assignee: Stefan Miklosovic This mostly affects listsnapshots command as well as removal of a snapshot when it is on TTL. Currently, there is not the same timestamp for "created_at" field in listsnapshots output so what might happen when TTL deletion kicks in is that only part of tables might be removed because other tables do not have to make it into that TTL threshold but they will be removed on the next SnapshotManager's removal round. -- 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-15134) SASI index files not included in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-15134:
--
Component/s: Local/Snapshots
> SASI index files not included in snapshots
> --
>
> Key: CASSANDRA-15134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15134
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI, Local/Snapshots
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> Newly written SASI index files are not being included in snapshots. This is
> because the SASI index files are not added to the components
> ({{org.apache.cassandra.io.sstable.SSTable#components}}) list of newly
> written sstables.
> Although I don't believe anything except snapshots ever tries to reference
> the SASI index files from this location, on startup Cassandra does add the
> SASI index files (if they are found on disk) of existing sstables in their
> components list. In that case sstables that existed on startup with SASI
> index files will have their SASI index files included in any snapshots.
>
> This patch updates the components list of newly written sstable once the
> index is built.
> ||3.11||4.0||Trunk||
> |[https://github.com/apache/cassandra/pull/1150]|[TBD]|[TBD]|
>
--
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-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:comment-tabpanel=17411899#comment-17411899
]
Josh McKenzie edited comment on CASSANDRA-12988 at 9/8/21, 12:40 PM:
-
Some dtest failures that look related to the slight changes in CL defaults that
come along w/the shape of the patch. Bouncing back to in progress while I work
through those as I'm not sure how invasive those changes will end up.
edit: just saw that you picked this up [~b.le...@gmail.com]; I'll keep things
as they are on the Jira here and ping when I've rooted this out.
was (Author: jmckenzie):
Some dtest failures that look related to the slight changes in CL defaults that
come along w/the shape of the patch. Bouncing back to in progress while I work
through those as I'm not sure how invasive those changes will end up.
> 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] [Commented] (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:comment-tabpanel=17411899#comment-17411899
]
Josh McKenzie commented on CASSANDRA-12988:
---
Some dtest failures that look related to the slight changes in CL defaults that
come along w/the shape of the patch. Bouncing back to in progress while I work
through those as I'm not sure how invasive those changes will end up.
> 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-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] [Commented] (CASSANDRA-16847) nodetool assassinate of a node that failed bootstrap may lead to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411888#comment-17411888
]
Andres de la Peña commented on CASSANDRA-16847:
---
Looks good to me, +1
> nodetool assassinate of a node that failed bootstrap may lead to
> IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16847
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Membership,
> Consistency/Bootstrap and Decommission
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> User [Yorick|https://the-asf.slack.com/team/U026YMYS2QN] reported on ASF
> Slack that a node which failed to bootstrap is stuck in {{hibernate}} status
> and persists in {{gossipinfo}}:
> {noformat}
> /10.x.x.108
> generation:1625493756
> heartbeat:86
> STATUS:2:hibernate,true
> LOAD:79:96124.0
> SCHEMA:14:59adb24e-f3cd-3e02-97f0-5b395827453f
> DC:10:DC1
> RACK:12:RAC3
> RELEASE_VERSION:6:3.11.10
> INTERNAL_IP:8:10.x.x.108
> RPC_ADDRESS:5:10.x.x.108
> NET_VERSION:3:11
> HOST_ID:4:5b254d51-fc58-4ca2-856f-fe7878752131
> TOKENS:1: {noformat}
> Attempts to assassinate the node returns {{IndexOutOfBoundsException}}:
> {noformat}
> ERROR [GossipStage:1] 2021-08-11 09:10:03,440 CassandraDaemon.java:244 -
> Exception in thread Thread[GossipStage:1,5,main]
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:659) ~[na:1.8.0_292]
> at java.util.ArrayList.get(ArrayList.java:435) ~[na:1.8.0_292]
> at com.google.common.collect.Iterables.get(Iterables.java:728)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.makeTokenString(VersionedValue.java:156)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.left(VersionedValue.java:178)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.Gossiper.lambda$assassinateEndpoint$1(Gossiper.java:695)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_292]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_292]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_292] {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-15134) SASI index files not included in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411873#comment-17411873
]
Stefan Miklosovic commented on CASSANDRA-15134:
---
I have checked that the computation of snapshot size takes into account SASI
index components.
PR here [https://github.com/apache/cassandra/pull/1150]
On general positive feedback, I will prepare rest of the branches (4.0 and
trunk).
Build for above PR is here:
https://app.circleci.com/pipelines/github/instaclustr/cassandra/452/workflows/e997d1b1-e221-4a6b-b056-fec218b67eea
> SASI index files not included in snapshots
> --
>
> Key: CASSANDRA-15134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15134
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> Newly written SASI index files are not being included in snapshots. This is
> because the SASI index files are not added to the components
> ({{org.apache.cassandra.io.sstable.SSTable#components}}) list of newly
> written sstables.
> Although I don't believe anything except snapshots ever tries to reference
> the SASI index files from this location, on startup Cassandra does add the
> SASI index files (if they are found on disk) of existing sstables in their
> components list. In that case sstables that existed on startup with SASI
> index files will have their SASI index files included in any snapshots.
>
> This patch updates the components list of newly written sstable once the
> index is built.
> ||3.11||4.0||Trunk||
> |[https://github.com/apache/cassandra/pull/1150]|[TBD]|[TBD]|
>
--
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-15134) SASI index files not included in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-15134:
--
Status: Patch Available (was: In Progress)
> SASI index files not included in snapshots
> --
>
> Key: CASSANDRA-15134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15134
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> Newly written SASI index files are not being included in snapshots. This is
> because the SASI index files are not added to the components
> ({{org.apache.cassandra.io.sstable.SSTable#components}}) list of newly
> written sstables.
> Although I don't believe anything except snapshots ever tries to reference
> the SASI index files from this location, on startup Cassandra does add the
> SASI index files (if they are found on disk) of existing sstables in their
> components list. In that case sstables that existed on startup with SASI
> index files will have their SASI index files included in any snapshots.
>
> This patch updates the components list of newly written sstable once the
> index is built.
> ||3.11||4.0||Trunk||
> |[https://github.com/apache/cassandra/pull/1150]|[TBD]|[TBD]|
>
--
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-16847) nodetool assassinate of a node that failed bootstrap may lead to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16847:
--
Reviewers: Andres de la Peña
> nodetool assassinate of a node that failed bootstrap may lead to
> IndexOutOfBoundsException
> --
>
> Key: CASSANDRA-16847
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16847
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Membership,
> Consistency/Bootstrap and Decommission
>Reporter: Erick Ramirez
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> User [Yorick|https://the-asf.slack.com/team/U026YMYS2QN] reported on ASF
> Slack that a node which failed to bootstrap is stuck in {{hibernate}} status
> and persists in {{gossipinfo}}:
> {noformat}
> /10.x.x.108
> generation:1625493756
> heartbeat:86
> STATUS:2:hibernate,true
> LOAD:79:96124.0
> SCHEMA:14:59adb24e-f3cd-3e02-97f0-5b395827453f
> DC:10:DC1
> RACK:12:RAC3
> RELEASE_VERSION:6:3.11.10
> INTERNAL_IP:8:10.x.x.108
> RPC_ADDRESS:5:10.x.x.108
> NET_VERSION:3:11
> HOST_ID:4:5b254d51-fc58-4ca2-856f-fe7878752131
> TOKENS:1: {noformat}
> Attempts to assassinate the node returns {{IndexOutOfBoundsException}}:
> {noformat}
> ERROR [GossipStage:1] 2021-08-11 09:10:03,440 CassandraDaemon.java:244 -
> Exception in thread Thread[GossipStage:1,5,main]
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:659) ~[na:1.8.0_292]
> at java.util.ArrayList.get(ArrayList.java:435) ~[na:1.8.0_292]
> at com.google.common.collect.Iterables.get(Iterables.java:728)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.makeTokenString(VersionedValue.java:156)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.VersionedValue$VersionedValueFactory.left(VersionedValue.java:178)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.gms.Gossiper.lambda$assassinateEndpoint$1(Gossiper.java:695)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_292]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ~[na:1.8.0_292]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_292]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_292] {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-14196) replace_address_test:TestReplaceAddress.test_multi_dc_replace_with_rf1 fails without vnodes
[ https://issues.apache.org/jira/browse/CASSANDRA-14196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411822#comment-17411822 ] Ruslan Fomkin commented on CASSANDRA-14196: --- I have done some local testing and suspect that this is not an issue any more. It looks like that the marks of vnode and flaky can be removed. > replace_address_test:TestReplaceAddress.test_multi_dc_replace_with_rf1 fails > without vnodes > --- > > Key: CASSANDRA-14196 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14196 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core, Legacy/Testing >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > Skipping it for now, but it probably should pass without vnodes. > https://circleci.com/gh/aweisberg/cassandra/871#tests/containers/15 -- 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-16718) Changing listen_address with prefer_local may lead to issues
[ https://issues.apache.org/jira/browse/CASSANDRA-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411763#comment-17411763 ] Jan Karlsson commented on CASSANDRA-16718: -- Great findings so far. Thank you for taking the time to dig into this. I agree that the old local address is persisted somewhere and therefore used by the existing node. However, in an attempt to verify your findings I modified my test case to manually change the preferred_ip before I start the last node so that it points to the correct address. The test still fails even with an updated preferred_ip. My original thought was that the Gossiper was persisting this ip in endpointStateMap. During checkEndpointCollison, the UP node will attempt to connect through the local address before this address is updated by the ShadowRound. > Changing listen_address with prefer_local may lead to issues > > > Key: CASSANDRA-16718 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16718 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Jan Karlsson >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > Many container based solution function by assigning new listen_addresses when > nodes are stopped. Changing the listen_address is usually as simple as > turning off the node and changing the yaml file. > However, if prefer_local is enabled, I observed that nodes were unable to > join the cluster and fail with 'Unable to gossip with any seeds'. > Trace shows that the changing node will try to communicate with the existing > node but the response is never received. I assume it is because the existing > node attempts to communicate with the local address during the shadow round. > -- 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
[cassandra] branch trunk updated: Add support for filtering using IN restrictions
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new dcee430 Add support for filtering using IN restrictions
dcee430 is described below
commit dcee430e57f3fd37e4bc6652ad7180361e31444e
Author: nvharikrishna
AuthorDate: Wed Aug 18 15:06:03 2021 +0200
Add support for filtering using IN restrictions
patch by Venkata Harikrishna Nukala; reviewed by Andrés de la Peña and
Benjamin Lerer for CASSANDRA-14344
---
CHANGES.txt| 1 +
src/java/org/apache/cassandra/cql3/Operator.java | 5 +-
.../cassandra/cql3/SingleColumnRelation.java | 10 --
.../cql3/restrictions/MultiColumnRestriction.java | 19 ++-
.../cql3/restrictions/SingleColumnRestriction.java | 7 +-
.../cql3/restrictions/StatementRestrictions.java | 3 -
.../org/apache/cassandra/db/filter/RowFilter.java | 6 +-
.../cassandra/index/sasi/conf/ColumnIndex.java | 2 +-
.../cassandra/index/sasi/plan/Expression.java | 5 +-
.../cassandra/serializers/ListSerializer.java | 37 ++
.../validation/operations/CompactStorageTest.java | 26 ++--
.../operations/SelectMultiColumnRelationTest.java | 42 ++
.../operations/SelectSingleColumnRelationTest.java | 146 -
.../cql3/validation/operations/SelectTest.java | 64 ++---
.../apache/cassandra/index/sasi/SASICQLTest.java | 16 +++
15 files changed, 334 insertions(+), 55 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index c3000d4..5d4c20f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Add support for filtering using IN restrictions (CASSANDRA-14344)
* Provide a nodetool command to invalidate auth caches (CASSANDRA-16404)
* Catch read repair timeout exceptions and add metric (CASSANDRA-16880)
* Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies
(CASSANDRA-16854)
diff --git a/src/java/org/apache/cassandra/cql3/Operator.java
b/src/java/org/apache/cassandra/cql3/Operator.java
index 1acedee..992056c 100644
--- a/src/java/org/apache/cassandra/cql3/Operator.java
+++ b/src/java/org/apache/cassandra/cql3/Operator.java
@@ -26,6 +26,7 @@ import java.util.Map;
import java.util.Set;
import org.apache.cassandra.db.marshal.*;
+import org.apache.cassandra.serializers.ListSerializer;
import org.apache.cassandra.utils.ByteBufferUtil;
public enum Operator
@@ -110,8 +111,8 @@ public enum Operator
public boolean isSatisfiedBy(AbstractType type, ByteBuffer
leftOperand, ByteBuffer rightOperand)
{
-List inValues = ListType.getInstance(type,
false).getSerializer().deserialize(rightOperand);
-return
inValues.contains(type.getSerializer().deserialize(leftOperand));
+ListSerializer serializer = ListType.getInstance(type,
false).getSerializer();
+return serializer.anyMatch(rightOperand, r ->
type.compareForCQL(leftOperand, r) == 0);
}
},
CONTAINS(5)
diff --git a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
index 9ff3f07..cf1cb69 100644
--- a/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
+++ b/src/java/org/apache/cassandra/cql3/SingleColumnRelation.java
@@ -274,16 +274,6 @@ public final class SingleColumnRelation extends Relation
{
ColumnSpecification receiver = columnDef;
-if (isIN())
-{
-// We only allow IN on the row key and the clustering key so far,
never on non-PK columns, and this even if
-// there's an index
-// Note: for backward compatibility reason, we conside a IN of 1
value the same as a EQ, so we let that
-// slide.
-checkFalse(!columnDef.isPrimaryKeyColumn() &&
!canHaveOnlyOneValue(),
- "IN predicates on non-primary-key columns (%s) is not
yet supported", columnDef.name);
-}
-
checkFalse(isContainsKey() && !(receiver.type instanceof MapType),
"Cannot use CONTAINS KEY on non-map column %s", receiver.name);
checkFalse(isContains() && !(receiver.type.isCollection()), "Cannot
use CONTAINS on non-collection column %s", receiver.name);
diff --git
a/src/java/org/apache/cassandra/cql3/restrictions/MultiColumnRestriction.java
b/src/java/org/apache/cassandra/cql3/restrictions/MultiColumnRestriction.java
index 4c6ce2f..acbb48e 100644
---
a/src/java/org/apache/cassandra/cql3/restrictions/MultiColumnRestriction.java
+++
b/src/java/org/apache/cassandra/cql3/restrictions/MultiColumnRestriction.java
@@ -21,6 +21,8 @@ import java.nio.ByteBuffer;
import java.util.*;
import org.apache.cassandra.schema.ColumnMetadata;
+import org.apache.cassandra.serializers.ListSerializer;
+import
[jira] [Commented] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411752#comment-17411752
]
Ruslan Fomkin commented on CASSANDRA-16841:
---
[~e.dimitrova] Thank you for your comment and clarifying that the comment was
only related to the resource intensive case.
[~e.dimitrova] [~adelapena] Your suggestion is to remove the change related to
flags of the resource intensive only and the resource intensive force, so that
the resource intensive force flag is always needed even with the resource
intensive only flag. I will do this change to restore the original behaviour
and will update the tests. The rest of the patch will be kept the same. Let me
know if I missed or misunderstood anything.
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An issue, which I was hit:
> When one class in a dtest file is marked as resource intensive, then all
> tests in all classes are treated as resource intensive. For example,
> [repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
> contains three classes and the last class is marked as resource intensive:
> {code:java}
> @pytest.mark.resource_intensive
> class TestRepairDataSystemTable(Tester):
> {code}
> So if I try to run an unmarked class:
> {code:java}
> pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
> --collect-only --skip-resource-intensive-tests
> {code}
> then all tests are ignored
> {code:java}
> collected 36 items / 36 deselected
> {code}
> This is because a test is treated to be marked if any class in the same file
> has the mark. This bug was introduced in the fix of CASS-16399. Before only
> upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
> then all tests are upgrade test in the file.
>
> This bug, for example, means that if the same file contains one class marked
> with vnodes and another class with no_vnodes, then no tests will be executed
> in the file.
> I also noticed another issue that If a test run is executed with the argument
> {{-only-resource-intensive-tests}} and there is no sufficient resources for
> resource intensive tests, then no tests were executed. Thus it was necessary
> to provide {{-force-resource-intensive-tests}} in addition.
> Suggestions for the solutions:
> # Require to mark each class and remove the special case of upgrade tests.
> This will simplify the implementation and might be more obvious for new
> comers.
> # Treat {{-only-resource-intensive-tests}} in the same way as
> {{-force-resource-intensive-tests}}, so it will be enough to just specify it
> even with no sufficient resources.
>
>
--
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-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruslan Fomkin updated CASSANDRA-16841:
--
Description:
An issue, which I was hit:
When one class in a dtest file is marked as resource intensive, then all tests
in all classes are treated as resource intensive. For example,
[repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
contains three classes and the last class is marked as resource intensive:
{code:java}
@pytest.mark.resource_intensive
class TestRepairDataSystemTable(Tester):
{code}
So if I try to run an unmarked class:
{code:java}
pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
--collect-only --skip-resource-intensive-tests
{code}
then all tests are ignored
{code:java}
collected 36 items / 36 deselected
{code}
This is because a test is treated to be marked if any class in the same file
has the mark. This bug was introduced in the fix of CASS-16399. Before only
upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
then all tests are upgrade test in the file.
This bug, for example, means that if the same file contains one class marked
with vnodes and another class with no_vnodes, then no tests will be executed in
the file.
I also noticed another issue that If a test run is executed with the argument
{{-only-resource-intensive-tests}} and there is no sufficient resources for
resource intensive tests, then no tests were executed. Thus it was necessary to
provide {{-force-resource-intensive-tests}} in addition.
Suggestions for the solutions:
# Require to mark each class and remove the special case of upgrade tests.
This will simplify the implementation and might be more obvious for new comers.
# Treat {{-only-resource-intensive-tests}} in the same way as
{{-force-resource-intensive-tests}}, so it will be enough to just specify it
even with no sufficient resources.
*Update:* comments were provided to keep only the first suggestion and do not
implement the second suggestion.
was:
An issue, which I was hit:
When one class in a dtest file is marked as resource intensive, then all tests
in all classes are treated as resource intensive. For example,
[repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
contains three classes and the last class is marked as resource intensive:
{code:java}
@pytest.mark.resource_intensive
class TestRepairDataSystemTable(Tester):
{code}
So if I try to run an unmarked class:
{code:java}
pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
--collect-only --skip-resource-intensive-tests
{code}
then all tests are ignored
{code:java}
collected 36 items / 36 deselected
{code}
This is because a test is treated to be marked if any class in the same file
has the mark. This bug was introduced in the fix of CASS-16399. Before only
upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
then all tests are upgrade test in the file.
This bug, for example, means that if the same file contains one class marked
with vnodes and another class with no_vnodes, then no tests will be executed in
the file.
I also noticed another issue that If a test run is executed with the argument
{{-only-resource-intensive-tests}} and there is no sufficient resources for
resource intensive tests, then no tests were executed. Thus it was necessary to
provide {{-force-resource-intensive-tests}} in addition.
Suggestions for the solutions:
# Require to mark each class and remove the special case of upgrade tests.
This will simplify the implementation and might be more obvious for new comers.
# Treat {{-only-resource-intensive-tests}} in the same way as
{{-force-resource-intensive-tests}}, so it will be enough to just specify it
even with no sufficient resources.
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An issue, which I was hit:
> When one class in a dtest file is marked as resource intensive, then all
> tests in all classes are treated as resource intensive. For example,
> [repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
> contains three classes and the last class is marked as resource intensive:
> {code:java}
> @pytest.mark.resource_intensive
> class TestRepairDataSystemTable(Tester):
> {code}
> So if I try to run an unmarked class:
> {code:java}
> pytest
[jira] [Commented] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411753#comment-17411753
]
Ruslan Fomkin commented on CASSANDRA-16841:
---
Do I need to do any changes in the status of the ticket, while I am addressing
this comment?
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An issue, which I was hit:
> When one class in a dtest file is marked as resource intensive, then all
> tests in all classes are treated as resource intensive. For example,
> [repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
> contains three classes and the last class is marked as resource intensive:
> {code:java}
> @pytest.mark.resource_intensive
> class TestRepairDataSystemTable(Tester):
> {code}
> So if I try to run an unmarked class:
> {code:java}
> pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
> --collect-only --skip-resource-intensive-tests
> {code}
> then all tests are ignored
> {code:java}
> collected 36 items / 36 deselected
> {code}
> This is because a test is treated to be marked if any class in the same file
> has the mark. This bug was introduced in the fix of CASS-16399. Before only
> upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
> then all tests are upgrade test in the file.
>
> This bug, for example, means that if the same file contains one class marked
> with vnodes and another class with no_vnodes, then no tests will be executed
> in the file.
> I also noticed another issue that If a test run is executed with the argument
> {{-only-resource-intensive-tests}} and there is no sufficient resources for
> resource intensive tests, then no tests were executed. Thus it was necessary
> to provide {{-force-resource-intensive-tests}} in addition.
> Suggestions for the solutions:
> # Require to mark each class and remove the special case of upgrade tests.
> This will simplify the implementation and might be more obvious for new
> comers.
> # Treat {{-only-resource-intensive-tests}} in the same way as
> {{-force-resource-intensive-tests}}, so it will be enough to just specify it
> even with no sufficient resources.
>
>
--
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
