[
https://issues.apache.org/jira/browse/CASSANDRA-15505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017884#comment-17017884
]
Alex Petrov edited comment on CASSANDRA-15505 at 1/17/20 10:27 AM:
-------------------------------------------------------------------
[~dcapwell] main motivation to make API the way it is right now is:
1. Internal Cassandra messages are version-dependent and even if their classes
matched (which is not the case after the recent refactoring), we should not
expose Cassandra internals through in-jvm dtest framework. This means that we
can only pass already serialised messages.
2. Serialization mechanisms (Cassandra and Java) here unfortunately serve
different purposes. Cassandra serialiser just encodes message to a byte buffer
and wraps it into a class that performs actual routing. Java serialisation
makes sure that the message can pass the boundary of the instance.
3. Messages are not updated and the intent here is not allowing updating, but
inspecting them. Inspecting messages is possible only in when you have
Cassandra on class path, and often requires running instance state for decoding
(like tables, keyspaces, etc), so I decided to make an example in tests that
performs inspection directly on the node.
As regards the tests this could be useful for, since I initially thought we
could count received repair messages using interceptors in the failing repair
test. I'm also frequently adding netty handler for logging for tracing messages
between the nodes, and I can imagine a few tests where we could rely on message
visibility for validation.
I have tried to find an example of "calling run like in failing repair test",
and I assume you mean that you mean we can either read metrics, or we can even
subscribe to the message sink without having this possibility built in in the
framework. I still see some value to have it directly here though.
was (Author: ifesdjeen):
[~dcapwell] main motivation to make API the way it is right now is:
1. Internal Cassandra messages are version-dependent and even if their classes
matched (which is not the case after the recent refactoring), we should not
expose Cassandra internals through in-jvm dtest framework. This means that we
can only pass already serialised messages.
2. Serialization mechanisms (Cassandra and Java here unfortunately serve
different purposes). Cassandra serialiser just encodes message to a byte buffer
and wraps it into a class that performs actual routing. Java serialisation
makes sure that the message can pass the boundary of the instance.
3. Messages are not updated and the intent here is not allowing updating, but
inspecting them. But since inspecting messages is possible only in when you
have Cassandra on class path, and often requires running instance state for
decoding (like tables, keyspaces, etc), I decided to make an example in tests
that performs inspection directly on the node.
As regards the tests this could be useful for, since I initially thought we
could count received repair messages using interceptors in the failing repair
test. I'm also frequently adding netty handler for logging for tracing messages
between the nodes, and I can imagine a few tests where we could rely on message
visibility for validation.
I have tried to find an example of "calling run like in failing repair test",
and I assume you mean that you mean we can either read metrics, or we can even
subscribe to the message sink without having this possibility built in in the
framework. I still see some value to have it directly here though.
> Add message interceptors to in-jvm dtests
> -----------------------------------------
>
> Key: CASSANDRA-15505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15505
> Project: Cassandra
> Issue Type: New Feature
> Components: Test/dtest
> Reporter: Alex Petrov
> Assignee: Alex Petrov
> Priority: Normal
>
> Currently we only have means to filter messages in in-jvm tests. We need a
> facility to intercept and modify the messages between nodes for testing
> purposes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
