PG: read idle timeout only half-closes the connection, pending connect hangs until pool timeout

クローズ
  • 何か問題がありますか？
#1,755 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@tsegismont がすでに取り組んでいます。

2026年10月20日 から。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
58/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
java, postgresql
領域
backend, database

調査の方向性

The issue points to PgEncoder.close and the VertxConnection.handleIdle close path; start by reading those implementations and the related connection close tests. Reproduce with a server that accepts the socket but never answers, using the supplied Java example and a 500 ms read idle timeout. Done means the connection closes and pending commands fail promptly with ClosedConnectionException.

索引モデルが issue の本文から書いたものです。

説明

Version

vertx-pg-client 5.1.10 (same code on master)

Context

With NetClientOptions.setReadIdleTimeout(...) passed to the pool builder, a read idle timeout on a PG connection does not close the channel. If the server never answers (dead host, firewall dropping packets, hung proxy), the connection stays open and any pending command, including the startup handshake, is never failed. The caller only gets an error from the pool connection-timeout, or not at all for an established connection.

The Db2 client fails in about 500 ms in the same setup.

Cause

On idle, Vert.x core calls chctx.close() from the handler context (VertxConnection.handleIdle). That close goes through PgEncoder.close(ctx, promise), which only encodes a CloseConnectionCommand: it writes Terminate and calls shutdownOutput(), but never propagates the close and never completes the promise. The channel is only half-closed and waits for the server to close its side. A silent server never does, so channelInactive and the close handler of SocketConnectionBase never run.

Steps to reproduce

A server that accepts the connection and never answers:

import java.io.InputStream;
import java.net.InetAddress;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.concurrent.TimeUnit;

import io.vertx.core.Vertx;
import io.vertx.core.net.NetClientOptions;
import io.vertx.pgclient.PgBuilder;
import io.vertx.pgclient.PgConnectOptions;
import io.vertx.sqlclient.Pool;
import io.vertx.sqlclient.PoolOptions;

public class Repro {
  public static void main(String[] args) throws Exception {
    ServerSocket server = new ServerSocket(0, 50, InetAddress.getLoopbackAddress());
    Thread acceptor = new Thread(() -> {
      try {
        Socket socket = server.accept();
        long start = System.nanoTime();
        InputStream in = socket.getInputStream();
        while (in.read() != -1) {
        }
        System.out.printf("server: read EOF after %d ms%n", (System.nanoTime() - start) / 1_000_000);
      } catch (Exception ignore) {
      }
    });
    acceptor.setDaemon(true);
    acceptor.start();

    Vertx vertx = Vertx.vertx();
    Pool pool = PgBuilder.pool()
      .with(new PoolOptions().setConnectionTimeout(15).setConnectionTimeoutUnit(TimeUnit.SECONDS))
      .with(new NetClientOptions().setIdleTimeoutUnit(TimeUnit.MILLISECONDS).setReadIdleTimeout(500))
      .connectingTo(new PgConnectOptions().setHost("127.0.0.1").setPort(server.getLocalPort())
        .setDatabase("db").setUser("u").setPassword("p"))
      .using(vertx)
      .build();

    long start = System.nanoTime();
    try {
      pool.getConnection().await(30, TimeUnit.SECONDS);
    } catch (Throwable e) {
      System.out.printf("getConnection failed after %d ms: %s%n", (System.nanoTime() - start) / 1_000_000, e);
    }
    vertx.close().await();
  }
}

Output:

server: read EOF after 505 ms
getConnection failed after 15004 ms: io.vertx.core.impl.NoStackTraceThrowable: Timeout

Also, vertx.close().await() at the end of this program takes about 105 s (measured 105573 ms), while it returns in 17 ms when the server closes the connection itself.

The idle timeout fires at 500 ms, but the client only half-closes the connection. If the server closes its side 2 s after reading EOF, getConnection fails right then (about 2.5 s) with ClosedConnectionException, which confirms that the channel stays open until the peer closes it.

For comparison, the same program with DB2Builder / DB2ConnectOptions:

server: read EOF after 500 ms
getConnection failed after 508 ms: io.vertx.db2client.DB2Exception: The connection was closed by the database server., SQLCODE=-4499  SQLSTATE=08004.C.3
Expected

When the read idle timeout fires, the connection is closed (the graceful Terminate is fine, but the channel should actually close and the close promise should complete), so pending commands fail with ClosedConnectionException right away.

Possible fix

In PgEncoder.close, after writing Terminate, propagate the close (ctx.close(promise)) instead of only shutting down the output, or at least close the channel when the server does not close it within a short delay.

主要言語
Java
スター
912
フォーク
215
平均マージ
3時間 55分
マージ済み PR（30日）
43

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

eclipse-vertx/vertx-sql-client のほかの issue

eclipse-vertx/vertx-sql-client の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。