vertx don't instant sends messages while processing handlers! #43
Comments
|
This issue was previously opened in eclipse/vertx repository, and @vietj wrote: Hi, with a worker it happens because Hazelcast uses an executeBlocking method that cannot be executed until the current task (the worker) has been finished (as it uses ordering). can you rather open this issue in vertx-hazelcast project ? |
|
A workaround while the fix is not out, it's creating another Note that this workaround is just for worker verticles. For standard verticles the default public class Pong extends AbstractVerticle {
private final static Logger LOG = LoggerFactory.getLogger(Pong.class);
private WorkerExecutor executor;
@Override
public void start() {
executor = getVertx().createSharedWorkerExecutor("vert.x-new-internal-blocking", 20);
getVertx().eventBus().consumer("table", message -> {
// Run ordered or not it's up to you
executor.executeBlocking(future -> {
String ball = (String)message.body();
LOG.info("pong> recv " + ball);
process(); // 50ms wait
LOG.info("pong> send " + ball);
message.reply(ball);
future.complete();
}, result -> {});
});
}
private static void process() {
try {
Thread.sleep(50);
} catch (InterruptedException e) {
throw new IllegalStateException(e);
}
}
} |
|
It's also related to that issue: vert-x3/issues#75 |
|
ideally we should not need to use such work around. |
|
@tsegismont @cescoffier how about adding a test in clustering TCK that checks that we can send an event bus message in a blocking worker ? |
|
@vietj will do 2016-09-06 19:25 GMT+02:00 Julien Viet [email protected]:
|
|
Tests about this issue: (vertx don't instant sends messages while having messages to process):
Legend:
If the issue is because a call to The hazelcast implementation could uses the current thread when it is a worker thread (doing a check on the current context and use execute blocking only when on event loop thread, quite tedious) Or could use another |
|
#29 was recently merged, which enabled the use of non-blocking execution through setting a System property. Some calls to @tetv , could you perform the tests again with A background of the abovementioned PR can be found at #28. |
|
Thank you @LoneRifle, I will do again the tests. |
|
Tests created using vertx 3.3.2 (with and without
Each cell tells if the messages are sent instantaneously to Ping after processing
Notes: Source code is available here: https://github.com/tetv/vertx3-blocking The tests were executed on:
|
|
Updated the test source code with junit tests (now using vertx 3.3.3).
Note: The There is also an identical issue but for non clustered vertx: eclipse-vertx/vert.x#1631 |
|
Closed via #54 |
|
I have updated to vertx 3.4.0, and the same issues described above are still happening. |
|
@tetv we have decided that having a message sent in a worker delayed until the blocking tasks is finished is a normal thing and we are not going to try to solve it. Blocking in Vert.x should be done to wrap blocking API and not used for waiting asynchronous responses. |
|
Thank you @vietj but it doesn't make much sense for me, at least in a first glance. In scenarios which a worker executing blocking code sends a |
|
can you explain more in detail the sequence of operations ? |
|
Sure @vietj, here it is:
|
It seems that
vertxonly sends cluster messages when is idle (nothing to process).That means while a
vertxis very busy/active there is no messages dispatched toeventBusuntil thevertxbecomes completely idle, that could be a big limitation if there is a need to send instant messages.What is the solution to force vertx to instant send a message without waiting the need to be
idle?In order to demonstrate this issue, I have created two very simple verticles:
Scenarios: (cluster mode)
verticle:verticle:For these tests ping verticle is a worker verticle ([w-##] means vert.x-worker-thread-##), however it's not revenant if it's a standard verticle because both configurations are similar. Both ping and pong suffers from the reported issue and therefore the messages were stuck on
eventBusuntilidle(nothing to process).Note that If the ping used a multithread worker then the 1 second extra stuff wasn't noticed and the entire process was 1 second quicker (see ping code), however the pong continues suffering from the reported issue.
ping verticle code:
pong verticle code:
verticle:verticleand pong is a multithread workerverticle:What is the solution to force vertx to instant send a message without waiting the need to be
idle?The text was updated successfully, but these errors were encountered: