Replaced TestUntil by AccessSafely

[eliezio]

No description provided.

[VaughnVernon]

@eliezio Since @alexguzun was working in wire most recently, I prefer that he review your code. He is working near London this week and won't be back to Portugal until the weekend. I will do a review but I won't merge. I want Alex to approve and merge.

[VaughnVernon]

@eliezio Looks good to me. Will await @alexguzun to approve and merge.

[VaughnVernon]

@eliezio I think that the common base class test makes sense. It seems like a good idea to prove that the interfaces are appropriately implemented across different transport types. I approve but will await @alexguzun to approve and merge.

[VaughnVernon]

@eliezio @alexguzun The Travis-CI build is failing on vlingo-wire with a timeout. This is generally due to a test not seeing the AccessSafely countdown reach zero. This may be due to an exception in test execution or that the number of expected steps is too high. Of course the countdown of expected steps might not reach zero due to another resource failure, such as network port availability. It's possible that the common test does not use a separate port for each test run, which is necessary for Socket and RSocket because the same port can be used by tests running in parallel, or there may be latency in closing the port prior to other tests attempting to use the same port. Here is the Travis-CI output:

io.rsocket.exceptions.RejectedSetupException: Channel could not be created

10:37:22.382 [main] INFO  io.vlingo.actors.Logger - RSocket client channel opened for address Address[Host[localhost],49243,NONE]

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received```

[alexguzun]

Each test, extending from this class, should have their own port range to avoid collision when running parallel tests .

[eliezio]

Got it. Is it possible to use random ports on all tests, allowing a definitive solution for problems like this?

[VaughnVernon]

Even a single static AtomicInteger and using incrementAndGet() in the abstract base will work for all extenders. I don't know why random would be better. You would still have to set ranges to different tests don't collide. I don't think there could be a central static because it could get recreated if multiple JVMs are employed in a given test run.

[eliezio]

When I say random I mean letting the OS choose a random local port and configuring the client accordingly. This is a common failsafe practice on testing server applications.

[alexguzun]

I could not find any reliable way to do what you are suggesting with raw java.nio.channels.SocketChannel and io.rsocket.transport.netty.server.TcpServerTransport at the time. I think most of the frameworks simply loop through sockets until find one that's open. We could replicate the approach but it's prone to race conditions when the loop identifies a free socket, closes it, and the consumer did not yet attached to it.

[eliezio]

This automatic port allocation is provided by every ServerSocket implementation. See https://docs.oracle.com/javase/8/docs/api/java/net/ServerSocket.html#ServerSocket-int-

Moreover, the test at https://github.com/rsocket/rsocket-java/blob/88ee909b8bfb78b5c53fa25bc39e16f6d893f0df/rsocket-transport-netty/src/test/java/io/rsocket/transport/netty/server/TcpServerTransportTest.java#L85 suggests that this mechanism is also available on rsocket.

[alexguzun]

Great find! Can you test this?

[VaughnVernon]

@alexguzun Can this be merged?