[
https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648391#comment-16648391
]
Benedict commented on CASSANDRA-14821:
--------------------------------------
[[email protected]]: if any change needed less justification, I can't think of
it, but perhaps this hasn't been expressed clearly enough.
You can think of dtests as deprecated as soon as this lands, with every new
distributed test written here instead (and preferably all existing dtests being
ported eventually).
It will provide, in essence, an in-process ccm - but with the wiring to access
each node's internal state directly at any point of the codebase. dtests will
be faster, less flaky, and more easily developed. You'll be able to trivially
debug them in your IDE, seeing all node states, and we can write complex
fuzzers over entire cluster behaviours with total control over what happens.
We can reliably disable, corrupt or otherwise interfere with cross-node
behaviours.
This is as good as testing gets, short of properly isolating and mocking out
every subsystem. It's only a shame we didn't do this a long time ago.
As it happens, I intend to write a test using this framework for
CASSANDRA-14812. But we should not block integration on that; this is too
widely impactful.
> Make it possible to run multi-node coordinator/replica tests in a single JVM
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-14821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14821
> Project: Cassandra
> Issue Type: Test
> Reporter: Alex Petrov
> Assignee: Alex Petrov
> Priority: Major
>
> Currently, dtests are complex to write, hard to modify and slow to run. The
> only option to manipulate a cluster state is either to shut down nodes or run
> unreliable Byteman queries.
> In order to improve the situation, a new Distributed Tester is proposed. It
> fires up multiple Cassandra Instances in a single JVM. It is done through
> having distinct class loaders in order to work around the singleton problem
> in Cassandra. In order to be able to pass some information between the nodes,
> a common class loader is used that loads up java standard library and several
> helper classes. Tests look a lot like CQLTester tests would usually look like.
> Each Cassandra Instance, with its distinct class loader is using
> serialisation and class loading mechanisms in order to run instance-local
> queries and execute node state manipulation code, hooks, callbacks etc.
> First version mocks out Messaging Service and simplifies schema management by
> simply running schema change commands on each of the instances separately.
> Internode communication is mocked by passing ByteBuffers through shared class
> loader.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
