Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#1,755 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@tsegismont ci sta già lavorando.

Dal 20/10/2026.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java, postgresql
Ambito
backend, database

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
912
Fork
215
Merge medio
19h 32m
PR unite (30g)
47

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eclipse-vertx/vertx-sql-client

Tutte le issue di eclipse-vertx/vertx-sql-client

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.