[
https://issues.apache.org/jira/browse/CASSANDRA-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665189#comment-16665189
]
Alex Petrov edited comment on CASSANDRA-14821 at 10/26/18 2:17 PM:
-------------------------------------------------------------------
bq. but I'm really afraid that this one introduces more difficulties and other
issues than it solves.
It'd be great to elaborate on it as I see no difficulties, but I'm open to your
suggestions if you describe which exactly parts introduce any difficulties. I
realise however that benefits will be only adding up with time as there are
more tests and more discovered issues and I'm happy to make benefits even
larger than they already are.
Additionally, the benefits are already starting to show: we have already found
and fixed two issues and were able to write tests for third one which proved it
works well, with this approach and now can test things that previously were
impossible to test (listed in detail in other comments).
I'd also be curious to see previously where this approach was successfully
implemented. The only that I'm aware of is Embedded Cassandra, but this does
not come even close as it neither allowed successfully stopping the process nor
did it allow to launch multiple instances.
I think the future of dtests is completely *out of scope* of this ticket and it
should only be discussed in a wider forum and requires a deep analysis. The
only goal here is to allow testing things which are hard to reproduce with
dtests and unit tests (among others, ones that have fine-grained control over
instance state and behaviour). Focus is to allow test _some_ things
differently, quicker, more deterministically and with native debugger.
was (Author: ifesdjeen):
bq. but I'm really afraid that this one introduces more difficulties and other
issues than it solves.
It'd be great to elaborate on it as I see no difficulties, but I'm open for
your suggestions if you describe which exactly parts introduce any
difficulties. I realise however that benefits will be only adding up with time
as there are more tests and more discovered issues and I'm happy to make
benefits even larger than they already are.
Additionally, the benefits are already starting to show: we have already found
and fixed two issues and were able to write tests for third one which proved it
works well, with this approach and now can test things that previously were
impossible to test (listed in detail in other comments).
I'd also be curious to see previously where this approach was successfully
implemented. The only that I'm aware of is Embedded Cassandra, but this does
not come even close as it nor allowed successfully stopping the process neither
did it allow to launch multiple instances.
I think the future of dtests is completely *out of scope* of this ticket and it
should only be discussed in a wider forum and requires a deep analysis. The
only goal here is to allow testing things which are hard to reproduce with
dtests and unit tests (among others, ones that have fine-grained control over
instance state and behaviour). Focus is to allow test _some_ things
differently, quicker, more deterministically and with native debugger.
> 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
>
> This patch proposes an in-JVM Distributed Tester that can help to write
> distributed tests in a single JVM and be able to control node behaviour in a
> fine-grained way and set up nodes exactly how one needs it: configuration
> settings, parameters, which are also controllable in runtime on a per node
> basis, so each node can have its own unique state.
> 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.
> |[patch|https://github.com/ifesdjeen/cassandra/tree/in-jvm-distributed-tests-2]|[tests|https://circleci.com/workflow-run/d88a1278-596c-4af1-9a03-998e9f6c78d3]|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
