Asynchronous messaging in vertx #43
Conversation
…pector into runtime_overhaul
|
Travis test fails with: |
|
Regarding making the results out of order, do the refinements on ExpectedRecords still work? i.e. can you still call expected.refine().inOrder().from(index)? Our team could live without this, but it is a quite nice feature that really brings a lot of differentiated value to using Flink Spector. Does the messaging in error logs upon Assertion Failures also get mixed up? That could be quite confusing when debugging why an Assertion failed. |
|
The data the matchers are working on is what gets scrambled. You could still use inOrder() but there would be no guarantee that the output arrives in that order. Asides from that I'm switching the messaging layer again to use a disruptor which are based on a ring buffer. This of course conserves the ordering during messaging. It's already working but not finished. I think in the end I wan't to provide a local test mode using disruptors leveraging inter-thread messaging. And if I would like to support distributed tests in the future running on an actual cluster. I can exchange the messaging in this case to use vert.x or something other based on network sockets. |
|
Deprecated by Pullrequest #44 |
The messaging layer has been reimplemented with vert.x http://vertx.io which has been shown to make tests more stable and performant. The downside is ordering of output is now more random than before. This means even if Flink conserves the order of events internally, Flinkspector might scramble it. Flinkspector has been implemented from the start to handle results in random order. The question is if developers have adopted this mindset. Comments on this would be nice.