Vertical and uncaught exceptions
Considering the scenario that one of the vertices is throwing an uncaught exception.
What will happen next? If the vertical state is removed from the system, is there some kind of erlang supervisor-like mechanism to restart the vertical?
The documentation is not entirely clear in this aspect.
Update based on comments: I'm more interested in the situation where an exception is thrown from the handlers handling the received message (via the bus)
Hello
source to share
I answered part of my question (with a test program)
When an exception is thrown in an event handler, the exception is caught by the vert.x file and swallowed (ignored) . The event handler will process the next message.
Update: The application can register an exception handler and receive any unhandled Throwable delivered to that handler. There you can do some additional general processing
Update2: use vertx.exceptionHandler
to register the handler
source to share
Vert.x is all about the same style, asynchronous programming, which is mostly highlighted by callback handlers.
To deal with the deployment failure case, you must first proceed programmatically, i.e. you need to expand your vertical programmatically, suppose the deployment vertical vertex provides a completion handler that will be populated with the deployment result, here's a sample using Java (since you haven't chosen any particular language, I'll go better) where:
-
MainVerticle
: your vertical deployment point (mainly used to deploy other vertices). -
some.package.MyVerticle
: this is your real vertical, note that I used id here , not instance.
public class MainVerticle extends AbstractVerticle {
public void start() {
vertx.deployVerticle("some.package.MyVerticle", res -> {
if (res.succeeded()) {
// Do whatever if deployment succeeded
} else {
// Handle deployment failure here...
}
});
}
}
Now, when it comes to "messaging failures", it would be more difficult to isolate a specific case as it can happen in many places and on behalf of both ends of messages.
If you want to register a failure handler when posting a message, you can instantiate MessageProducer<T>
that represents a stream to which it can be written and register an exception handler on it:
EventBus eb = vertx.eventBus();
MessageProducer<String> sender = eb.sender("someAddress");
sender.exceptionHandler(e -> {
System.out.println("An error occured" + e.getCause());
});
sender.write("Hello...");
On the other hand, you can handle the failure case when reading received messages in almost the same way, but using MessageConsumer<T>
this time:
EventBus eb = vertx.eventBus();
MessageConsumer<String> receiver = eb.consumer("someAddress");
receiver.exceptionHandler(e -> {
System.out.println("An error occured while readeing data" + e.getCause());
}).handler(msg -> {
System.out.println("A message has been received: " + msg.body());
});
source to share
To add a little to the previous answer, if you want to react to all uncaught exceptions, register a handler on the object vertx
like this:
vertx.exceptionHandler(new Handler<Throwable>() {
@Override
public void handle(Throwable event) {
// do what you meant to do on uncaught exception, e.g.:
System.err.println("Error");
someLogger.error(event + " throws exception: " + event.getStackTrace());
}
});
source to share
I ran into something similar to this. When an exception happens as part of the post processing in Verticle, I just wanted to respond with an exception.
The idea is to simply float exceptions all the way to the entry point of the application where you can decide what to do about the error, while still grabbing the entire stack along the way.
For this, I wrote this function:
protected ReplyException buildReplyException(Throwable cause, String message)
{
ReplyException ex = new ReplyException(ReplyFailure.RECIPIENT_FAILURE, -1, message);
ex.initCause(cause);
return ex;
}
Which I then use to create response handlers or handlers, like this:
reply -> {
if (reply.succeeded()) {
message.reply(true);
} else {
message.reply(buildReplyException(reply.cause(), ""));
}
});
This way, the guy who sent the original message will receive an erroneous response containing the reason for the exception, in which the full stack trace is full.
This approach worked really well for me to handle errors while handling messages.
source to share