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

Streaming reconnect runs under the previous leg's expired deadline (1 ms connect budget)

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

Maintainer thường phản hồi trong vòng 1 ngày

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
78/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
backend, networking

Hướng nghiên cứu

Start by reading HttpTransport.java around connect(), ensureConnected() and post(), then trace the reconnect path from WsmanClient.java. Add the regression scenario described in StreamingApiTest: a late Receive response followed by a dropped connection and reconnect. Done means the streaming operation completes without a spurious connect timeout, while poll-mode deadlines remain shared across a poll.

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

Mô tả

bug

Problem

In streaming mode (failOnQuietTimeout, i.e. HttpTransport.inactivityTimeout()), the socket deadline is per request leg: post() re-arms deadlineEpochMillis at the start of every leg (HttpTransport.java#L350).

But a reconnect does not go through post(). When the connection is gone, WsmanClient.send() calls transport.connect() explicitly before the authentication exchange (WsmanClient.java#L1166), and ensureConnected() caps the TCP connect and the TLS handshake with boundedByDeadline(connectTimeoutMillis) (HttpTransport.java#L318). That cap uses the deadline left over from the previous leg. If that leg ran long (a Receive that waited most of the inactivity timeout before the server dropped the connection, or a round trip that timed out), the leftover deadline is nearly or fully expired, and boundedByDeadline() floors it to 1 ms. The reconnect then fails with a connect timeout that has nothing to do with the server: a spurious TimeoutException for the streaming caller, or a wasted retry when connectRetries is set.

Where it bites today

PR #197 hit it on its Delete-then-Create sequence (a retired shell's Delete timing out, then the Create's reconnect) and works around it by calling configureTimeouts() again between the two requests. That resets the deadline for that one spot only; every other reconnect inside a streaming operation (a Receive, a Send, a Signal following a dropped connection) still runs under the stale deadline.

Proposed fix

Arm the per-leg deadline in connect() the same way post() does, so a reconnect gets the whole inactivity timeout for itself:

void connect() throws IOException {
    if (deadlinePerLeg) {
        deadlineEpochMillis = Utils.getCurrentTimeMillis() + readTimeoutMillis;
    }
    ensureConnected();
}

The configureTimeouts() re-call added by #197 can then go.

Poll mode (pollTimeout()) is unaffected: there the deadline is deliberately shared by every leg of one poll.

Test

StreamingApiTest: a command whose Receive the fake server answers late (close to the inactivity timeout) and then drops the connection, followed by a request that must reconnect; before the fix the reconnect fails with a connect timeout, after it the operation completes.

Ngôn ngữ chính
Java
Star
13
Fork
4
Merge trung bình
1 ngày 9 giờ
Pull request đã merge (30 ngày)
15

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

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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 MetricsHub/winrm-java

Tất cả issue của MetricsHub/winrm-java

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.