Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

WebSocket: a reset of either joined socket is logged at ERROR by ConnectionBase

Cerrado
  • ¿Algo no está bien?
#157 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@tsegismont ya está trabajando en esto.

Desde el 20/10/2026.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
62/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
networking

Línea de trabajo

Start in ReverseProxy.Proxy#sendResponse, where the client socket (request.proxiedRequest().toNetSocket()) and the backend socket (proxiedResponse.netSocket()) are joined with only handler and closeHandler. Read ConnectionBase#handleException to see why an unhandled reset is logged at ERROR. Done means both joined sockets get an exception handler that logs at trace and closes the other socket, with no reproducer test required.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Version

5.2.1 (also current main)

Context

Once the backend answers 101, ReverseProxy.Proxy#sendResponse joins the client socket
(request.proxiedRequest().toNetSocket()) and the backend socket (proxiedResponse.netSocket()) with handler and
closeHandler only. Neither socket gets an exception handler, so a failure on a joined socket is logged as an error.
The common case is a peer resetting its connection, which is routine for WebSockets (a closed tab, a mobile client
changing networks, a load balancer in front of the proxy closing its connection with a reset). With the native epoll
transport each one logs:

[ERROR] io.vertx.core.net.impl.ConnectionBase - recvAddress(..) failed with error(-104): Connection reset by peer

(Connection reset with the NIO transport.) Behind HAProxy this is a steady stream of ERROR lines, one per abruptly
ended WebSocket, that cannot be told apart from real failures.

Client side. toNetSocket() replaces the HTTP server connection with a new NetSocketImpl
(Http1ServerConnection#netSocket). The new connection does not keep the server's exception handler (which logs
connection failures at trace by default), so a reset takes this path:

  1. the read fails with ECONNRESET, and Netty fires exceptionCaught and then closes the channel;
  2. VertxHandler#exceptionCaught calls ConnectionBase#handleException on the NetSocketImpl;
  3. ConnectionBase#handleException finds no exception handler and logs the exception at ERROR;
  4. the channel closes, closeHandler fires and closes the backend socket.

Backend side. proxiedResponse.netSocket() is an HttpNetSocket over the request to the backend. A failure is
reported to that request's connection (Http1ClientConnection#handleException, which calls
ConnectionBase#handleException) and to the request (HttpClientRequestImpl#handleException), each of which logs it
at ERROR unless it has an exception handler, and then to the socket. The request and its connection belong to
whoever created the request (the OriginRequestProvider), so this issue only covers the joined sockets. Related: the
request also logs Connection was closed at ERROR whenever the proxy closes a WebSocket, a normal close included,
unless its creator sets an exception handler (the existing WebSocketTest tests log it on main).

The failure branch right below (Handle this case printed to System.err when toNetSocket() fails) is covered by
#155 / #156.

Steps to reproduce
  1. Proxy a WebSocket to a backend and let the backend answer 101.
  2. Once data has gone through the proxy, reset the client connection (close it with SO_LINGER 0).
  3. The proxy logs the reset at ERROR from io.vertx.core.net.impl.ConnectionBase.
Possible fix

Set an exception handler on both joined sockets, next to the closeHandlers, that logs at trace and closes the other
socket.

Do you have a reproducer?

The steps above; there is no test with the fix, because the change only affects what is logged. After an
IOException on a read, Netty closes the channel once it has reported the exception, and the existing closeHandlers
then close the other socket, so both sides close with or without the exception handlers. A test would have to capture
Vert.x's own log output, which nothing in this project does, and would depend on which logging backend the tests
happen to run with.

Lenguaje dominante
Java
Estrellas
68
Forks
39
Merge medio
2 d 43 min
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eclipse-vertx/vertx-http-proxy

Todos los issues de eclipse-vertx/vertx-http-proxy

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.