[jira] [Commented] (CASSANDRA-8728) Unit test support for native protocol

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304975#comment-14304975 ] 

Sylvain Lebresne commented on CASSANDRA-8728:
---------------------------------------------

I'm fine having basic unit tests for the protocol, and I understand that when developing new features for said protocol it's frustrating to have to wait for drivers to catch up to actually test the feature, but I think we should also balance how much efforts is worth putting in this.

Typically, emitting notifications might prove hard to test with a single node unit test, and imo it's fine leaving that to dtests (as it's a multi-node thing really). I'm also not entire sure that the concept of writing bytes manually in the tests (your {{NativeFrame}}) is worth the effort (except maybe for testing corrupted frames, but tbh it's not like the protocol is terribly resilient to that so there is so much we can test on that front). As we already have code to serialize and deserialize frames in the code, let's maybe start by simple unit tests that validate that by serializing and deserializing a given message we get back what we're supposed to.

Similarly, for concurrent access, it's probably not too hard to create a couple ad-hoc concurrent tests, but I wouldn't add too much complexity for that when it's already fairly heavily tested through drivers (by stress for instance).


> Unit test support for native protocol
> -------------------------------------
>
>                 Key: CASSANDRA-8728
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8728
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tests
>            Reporter: Robert Stupp
>            Priority: Minor
>
> Currently we do not have any chance to directly test the native protocol „on the wire“. Especially when coding new protocol features, it’s more a ”blind flight” and basically ”hope” that the code is correct.
> Purpose of this ticket is to provide unit test code that allows testing of native protocol as is. It’s purpose is not to test any CQL stuff as it.
> Since the native protocol is multiplexed and as such is intended to be used concurrently, unit test support should allow concurrent access to a single connection.
> Native protocol test code should work against a single node (for unit testing inside C* source tree) but also be able to handle/emit notifications.
> Test code should be very strict and fail for features/values that are not specified in a specific protocol version.
> Code used in the test classes should be separate to production code to be able to identify possible bugs in production code.
> (Following code should be considered as ”pseudo code”/idea and not as _the_ way to go)
> Establishing a connection:
> {noformat}
> NativeConnection connection = new NativeConnection(host, port, minClientVersion, maxClientVersion);
> connection.setAuthentication(…);
> connection.establish(timeout);
> {noformat}
> (There could be some support to provide host+port in unit tests that start an "embedded" server.)
> Sending (building) frames should be possible using a single class that builds the frame’s byte buffer like this. Additionally it should be able to construct corrupt/invalid frames to check failure-resistance of the server.
> {noformat}
> NativeStream stream = connection.newStream(); // create new stream
> NativeFrame frame = new NativeFrame(version, flags, stream.getId(), opcode);
> frame.addLong(longValue);
> frame.addStringList(str1, str2, …);
> nativeConnection.send(frame);
> {noformat}
> Stream handling:
> Each frame received for a stream goes into the stream’s received-frame-queue and can be polled from it.
> {noformat}
> NativeStream stream = connection.getEventStream();  // or getStream(-1);
> NativeFrame frame = stream.poll(); // get next frame
> {noformat}
> Native protocol events:
> {noformat}
> NativeStream stream = connection.getEventStream();  // or getStream(-1);
> NativeFrame frame = stream.poll(); // get next frame
> // OR
> NativeFrame frame = stream.pollForOpcode(opcode); // get frame with specific opcode
> // OR
> NativeFrame frame = stream.pollForEvent(eventCode); // get frame with specific event code
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)