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:46:35 GMT

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

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

bq. Maybe some combination of some very rudimental "client code" (just able to establish the
TCP connection and basic handshaking) plus the already existing code could work for a start

Yes, and there is already some rudimental "client code" in {{org.apache.cassandra.transport.SimpleClient}}
for the purpose of testing. We just never wrote unit tests that uses it.

> 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