CODEWITHSUNDEEP
httpclientvert.xhttpserver
SharonKo
SharonKo

Reputation: 619

Vert.x - How to know which connection was closed

I have a Vert.x app that gets HTTP requests as a Server and later down the road sends the data (HTTP request as well) as a Client to several other servers (more than one Client exits). I see in the logs that sometimes I get io.vertx.core.VertxException: Connection was closed but with no other info.

How can I know which connection was the one that was actually closed? I have more than one connections active. I tried to add exceptionHandler to HttpServer and to HttpClientRequest, but they both were never called.

Upvotes: 0

Views: 9158

Answers (1)

Guss
Guss

Reputation: 32335

The io.vertx.core.VertxException: Connection was closed can be triggered for both client connections and server connections.

You'd get these errors on your HTTP client connection if the remote server closed the connection before completing the response, and you'd be able to capture them by setting the appropriate handlers on the client request (With Vert.x 4, you'd do something like ...send().onFailure(err -> /* handle the failure */) ), which I believe you already do.

You'd get these errors for the HTTP server connection if the remote client disconnects, either before your server completed the response, or - if the connection has keep-alive enabled (which is the default for HTTP/1.1 connections) - even after the response was sent.

  • In case the client closed the server connection before the response was fully sent, you should be able to capture and handle there errors in the HttpServer.exceptionHandler(), as I'm sure you already do.
  • In case the client closed the server connection after the response was fully sent, while it is in a keep-alive state, then there is no HttpServerRequest (or RoutingContext if you are using vertx-web, as you should) where the exception happens in, so Vert.x would just disregard the error (see here for the code).

So why do you still see those errors in the log? It could be various things because that exception is also used to handle EventBus connections and all kinds of internal network streams managed by Vert.x servers - and all without a stack trace (the actual exception instance being thrown is created statically here), so Vert.x kinds of sucks in that way.

My recommendation: make sure you attach error handlers to everything (pay attention to websocket connections or HTTP response streams, if you use them) and if you still get those errors in the logs - maybe you can just ignroe them as the commenter suggested.

Upvotes: 2

Related Questions