cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8728) Unit test support for native protocol
Date Wed, 04 Feb 2015 11:29:34 GMT

    [ 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)

Mime
View raw message