[
https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653361#comment-16653361
]
Stefan Podkowinski commented on CASSANDRA-14821:
------------------------------------------------
As already mentioned, I really understand the motivation behind this and the
intention to replace dtests with a JVM based solution in the long run. My
approach to that was implementing CASSANDRA-12016 a little more than two years
ago. The main assumption behind it was that tests would be less complex and
could be run much more efficiently, by always focusing on a single node and
mocking it's interactions with a simulated cluster, instead of actually running
separate Cassandra instances in parallel and manipulating instances to exchange
messages in a certain way for a particular test case. Some tests implemented
based on that approach turned out to be promising. But there are certainly also
limitations and I hope that looking at the solution provided as part of this
ticket, would help me to learn more about use cases when tests could not be
fully simulated (for functional or practical reasons) and really need to be run
as multi instance integration tests. But that's just my personal curiosity.
What we should do nonetheless, is to eventually update the documentation and
describe which testing approach would fit best for which use case (dtest
py/jvm, unit, message mocking, property based, ..). I'd be happy to do that,
once this ticket is done.
> 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]