Agrona transport (requires Java8)

[jfallows]

Support syntax for scripting interactions with Agrona ring buffer and broadcast buffer shared memory communication data structures.

For example, an implementation acting as an Agrona client can use the following script to emulate server behavior.

property newLayout ${agronaIT:layoutInit("target/agrona-itest", 1024, 1024)}

accept agrona://stream/bidirectional
       option reader ${agrona:manyToOneReader(newLayout.ring)}
       option writer ${agrona:broadcastTransmitter(newLayout.broadcast)}

accepted
connected

read [0x00 0x00 0x00 0x01]
read ([0..32] :server32)

write [0x00 0x00 0x00 0x02]
write ${server32}

close
closed

...and, an implementation acting as an Agrona server can use the following script to emulate client behavior.

property layout ${agronaIT:layout("target/agrona-itest", 1024, 1024)}
property client32 ${agronaIT:randomBytes(32)}

connect agrona://stream/bidirectional
        option reader ${agrona:broadcastReceiver(layout.broadcast)}
        option writer ${agrona:manyToOneWriter(layout.ring)}

connected

write [0x00 0x00 0x00 0x01]
write ${client32}
write flush

read [0x00 0x00 0x00 0x02]
read ${client32}

close
closed

Agrona data structures require the first 4 bytes of each message represent a non-negative integer, and any successive writes combine to make up the message payload. When the writes are flushed, the message is delivered to the shared memory data structure.

[jfallows]

Note: Agrona requires Java8, do we have any builds using the current version of k3po that actually require a version of Java earlier than Java8 ?

If Java8 is used by the maven build runtime but compiler source and compiler target are both set to 1.7, then that still works fine.

[jfallows]

Looks like there is a race condition for connect await ... that is sometimes triggered by Travis-CI, causing builds to break unexpectedly.

[dpwspoon]

For the JDK, we should update the major version of K3po so that this backwards incompatible API is taking affect. For our internal implementation our 5.x line is currently on jdk 1.8 and should be fine. I believe our 4.x line can always use

                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>2.1</version>
                    <configuration>
                        <source>1.8</source>
                        <target>1.7</target>
                    </configuration>

with animal sniffer API

We will need to make that change in https://github.com/kaazing-private/core.common/blob/develop/pom.xml. CCing @ahousing

Additionally we should make the k3po pom require Java 1.8 to build @jfallows

[dpwspoon]

Should this just be skipITs and not skipTests? Like failsafe plugin

[jfallows]

I think this change is consistent with the previous semantics, just split into 2 parameters as part of updating to use the Maven Java annotations, with the "or" logic moved to the goal implementation instead of the javadoc comment.

Regarding the logic itself, the failsafe plugin appears to support the skipping of tests via the skipTests property, but given the effect of skipTests to cause both unit tests and integration tests to be skipped, another more targeted skipITs is provided to have the same effect on the failsafe plugin (skipping ITs) but not also causing other plugins to skip unit tests, such as the surefire plugin.

In our case, the k3po plugin also supports both skipTests and skipITs for the same reasons, either use skipTests to skip all unit tests and integration tests, or use skipITs to skip only integration tests. In either case, the k3po plugin would skip setting up the server since the failsafe plugin would not be executing the integration tests.

[dpwspoon]

Okay sounds good.

[dpwspoon]

When we release lets do a 3.0.0-alpha1 version. I would like to target some k3po control protocol changes to go into 3.0.0 as well. Specifically a cleanup command

[jfallows]

No problem, we can consume an alpha or beta for a short while in kaazing/nuklei.

[jfallows]

Btw, let's have a separate discussion on the motivation for the upcoming k3po control protocol changes. I'd like to better understand it.

[dpwspoon]

@jfallows See #239 for discussion on protocol changes