[
https://issues.apache.org/jira/browse/CASSANDRA-18753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17830932#comment-17830932
]
Maxim Muzafarov commented on CASSANDRA-18753:
---------------------------------------------
Sorry, if I got the status of the changes wrong. I haven't followed the
discussion.
The changes have been merged into the trunk, but the issue is still unresolved
and only points to the 5.0.x (the commit message refers to this issue). I think
there is a mistake here, right? (the changes should be either rollbacked or the
issue must have the right status).
[https://github.com/apache/cassandra/commit/06ed1afc34128523298020e7601dad148f2b2fb6]
It's also worth mentioning that some of the dtests are broken due to the
changes in the trunk branch.
It can be reproduced locally with a 100% chance.
{code:java}
memtable:
configurations:
skiplist:
class_name: SkipListMemtable
trie:
class_name: TrieMemtable
default:
inherits: skiplist
{code}
For example, the broken test (the trunk branch in the main project and the
trunk branch in the dtests are used):
{code:java}
pytest --cassandra-dir=/Users/mm/IdeaProjects/cassandra
gossip_test.py::TestGossip::test_assassinate_valid_node
{code}
The exception:
{code:java}
node1: ERROR [main] 2024-03-26 13:27:38,909 CassandraDaemon.java:900 -
Exception encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.schema.TableParams$Builder.<init>(TableParams.java:362)
at org.apache.cassandra.schema.TableParams.builder(TableParams.java:127)
at
org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:60)
at
org.apache.cassandra.cql3.statements.schema.CreateTableStatement.builder(CreateTableStatement.java:196)
at
org.apache.cassandra.cql3.statements.schema.CreateTableStatement.parse(CreateTableStatement.java:474)
at
org.apache.cassandra.schema.SchemaKeyspace.parse(SchemaKeyspace.java:278)
at
org.apache.cassandra.schema.SchemaKeyspace.<clinit>(SchemaKeyspace.java:92)
at org.apache.cassandra.schema.Schema.initialize(Schema.java:77)
at org.apache.cassandra.schema.Schema.<clinit>(Schema.java:72)
at org.apache.cassandra.db.Keyspace.setInitialized(Keyspace.java:124)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:261)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:728)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
Caused by: org.apache.cassandra.exceptions.ConfigurationException:
Configuration definition inherits unknown skiplist. A configuration can only
extend one defined earlier or "default".
at
org.apache.cassandra.config.InheritingClass.resolve(InheritingClass.java:54)
at
org.apache.cassandra.schema.MemtableParams.expandDefinitions(MemtableParams.java:151)
at
org.apache.cassandra.schema.MemtableParams.<clinit>(MemtableParams.java:101)
... 13 common frames omitted
{code}
Posting the stacktrace for visibility.
> Add an optimized default configuration to tests and make it available for new
> users
> -----------------------------------------------------------------------------------
>
> Key: CASSANDRA-18753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18753
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
> Reporter: Branimir Lambov
> Assignee: Branimir Lambov
> Priority: Urgent
> Fix For: 5.0-rc, 5.x
>
> Attachments:
> CCM_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch,
>
> DTEST_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch
>
> Time Spent: 12h 20m
> Remaining Estimate: 0h
>
> We currently offer only one sample configuration file with Cassandra, and
> that file is deliberately configured to disable all new functionality and
> incompatible improvements. This works well for legacy users that want to have
> a painless upgrade, but is a very bad choice for new users, or anyone wanting
> to make comparisons between Cassandra versions or between Cassandra and other
> databases.
> We offer very little indication, in the database packaging itself, that there
> are well-tested configuration choices that can solve known problems and
> dramatically improve performance. This is guaranteed to paint the database in
> a worse light than it deserves, and will very likely hurt adoption.
> We should find a way to offer a very easy way of choosing between "optimized"
> and "compatible" defaults. At minimal, we could provide alternate yaml files.
> Alternatively, we could build on the {{storage_compatibility_mode}} concept
> to grow it into a setting that not only enables/disables certain settings,
> but also changes their default values.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
