Skip to content

Commit 727264a

Browse files
somasunrobertroeser
authored andcommitted
Resurrect old tck-driver code and get it running (rsocket#249)
* import of reactivesocket-tck-drivers from older commit * My changes * Rebasing code on top of Reactor changes
1 parent a537b08 commit 727264a

23 files changed

Lines changed: 2299 additions & 1 deletion

.gitignore

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -66,3 +66,6 @@ atlassian-ide-plugin.xml
6666
# NetBeans specific files/directories
6767
.nbattrs
6868
/bin
69+
70+
#.gitignore in subdirectory
71+
.gitignore
Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
# ReactiveSocket TCK Drivers
2+
3+
This is meant to be used in conjunction with the TCK at [reactivesocket-tck](https://github.com/ReactiveSocket/reactivesocket-tck)
4+
5+
## Basic Idea and Organization
6+
7+
The philosophy behind the TCK is that it should allow any implementation of ReactiveSocket to verify itself against any other
8+
implementation. In order to provide a truly polyglot solution, we determined that the best way to do so was to provide a central
9+
TCK repository with only the code that generates the intermediate script, and then leave it up to implementers to create the
10+
drivers for their own implementation. The script was created specifically to be easy to parse and implement drivers for,
11+
and this Java driver is the first driver to be created as the Java implementation of ReactiveSockets is the most mature at
12+
the time.
13+
14+
The driver is organized with a simple structure. On both the client and server drivers, we have the main driver class that
15+
do an intial parse of the script files. On the server side, this process basically constructs dynamic request handlers where
16+
every time a request is received, the appropriate behavior is searched up and is passed to a ParseMarble object, which is run
17+
on its own thread and is used to parse through a marble diagram and enact it's behavior. On the client side, the main driver
18+
class splits up each test into it's own individual lines, and then runs each test synchronously in its own thread. Support
19+
for concurrent behavior can easily be added later.
20+
21+
On the client side, for the most part, each test thread just parses through each line of the test in order, synchronously and enacts its
22+
behavior on our TestSubscriber, a special subscriber that we can use to verify that certain things have happened. `await` calls
23+
should block the main test thread, and the test should fail if a single assert fails.
24+
25+
Things get trickier with channel tests, because the client and server need to have the same behavior. In channel tests on both
26+
sides, the driver creates a ParseChannel object, which parses through the contents of a channel tests and handles receiving
27+
and sending data. We use the ParseMarble object to handle sending data. Here, we have one thread that continuously runs `parse()`,
28+
and other threads that run `add()` and `request()`, which stages data to be added and requested.
29+
30+
31+
32+
## Run Instructions
33+
34+
You can build the project with `gradle build`.
35+
You can run the client and server using the `run` script with `./run [options]`. The options are:
36+
37+
`--server` : This is if you want to launch the server
38+
39+
`--client` : This is if you want to launch the client
40+
41+
`--host <h>` : This is for the client only, determines what host to connect to
42+
43+
`--port <p>` : If launching as client, tells it to connect to port `p`, and if launching as server, tells what port to server on
44+
45+
`--file <f>` : The path to the script file. Make sure to give the server and client the correct file formats
46+
47+
`--debug` : This is if you want to look at the individual frames being sent and received by the client
48+
49+
`--tests` : This allows you, when you're running the client, to specify the tests you want to run by name. Each test
50+
should be comma separated.
51+
52+
Examples:
53+
`./run.sh --server --port 4567 --file src/test/resources/servertest.txt` should start up a server on port `4567` that
54+
has its behavior determined by the file `servertest.txt`.
55+
56+
`./run.sh --client --host localhost --port 4567 --file src/test/resources/clienttest.txt --debug --tests genericTest,badTest` should
57+
start the client and have it connect to localhost on port `4567` and load the tests in `clienttest.txt` in debug mode,
58+
and only run the tests named `genericTest` and `badTest`.
59+
Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
apply plugin: 'application'
2+
apply plugin: 'java'
3+
4+
mainClassName = "io.reactivesocket.tckdrivers.main.Main"
5+
6+
jar {
7+
manifest {
8+
attributes "Main-Class": "$mainClassName"
9+
}
10+
11+
from {
12+
configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }
13+
}
14+
}
15+
16+
dependencies {
17+
18+
compile project(':reactivesocket-core')
19+
compile project(':reactivesocket-client')
20+
compile project(':reactivesocket-transport-netty')
21+
testCompile project(':reactivesocket-test')
22+
compile 'com.fasterxml.jackson.core:jackson-core:2.8.0.rc2'
23+
compile 'com.fasterxml.jackson.core:jackson-databind:2.8.0.rc2'
24+
compile 'org.apache.commons:commons-lang3:3.4'
25+
compile 'io.reactivex:rxnetty-tcp:0.5.2-rc.5'
26+
compile 'io.reactivex.rxjava2:rxjava:2.0.2'
27+
compile 'io.airlift:airline:0.7'
28+
}

reactivesocket-tck-drivers/run.sh

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
#!/bin/bash
2+
3+
LATEST_VERSION=$(ls build/libs/reactivesocket-tck-drivers-*-SNAPSHOT.jar | sort -r | head -1)
4+
5+
echo "running latest version $LATEST_VERSION"
6+
7+
java -cp "$LATEST_VERSION" io.reactivesocket.tckdrivers.main.Main "$@"

0 commit comments

Comments
 (0)