Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#157 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
62/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
networking

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Java
Star
68
Fork
38
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của eclipse-vertx/vertx-http-proxy

Tất cả issue của eclipse-vertx/vertx-http-proxy

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.