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

Robert Stupp commented on CASSANDRA-8728:
-----------------------------------------

Right - might be a bit over-engineered regarding corrupted streams and 
notifications.
The actual point I started thinking about was: how can I ensure/test that a 
error code new to v4 is not emitted to v2/v3 clients. First problem was how to 
initiate a native protocol connection and second how to check the received 
frames.
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.
WDYT?

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

Reply via email to