JDBC Client Spring: Pool läuft voll

[OnDemand]

Moin zusammen,

ich nutze grad mal den JDBC Client https://www.danvega.dev/blog/spring-jdbc-client

Dabei fällt mir auf, dass der Pool vollläuft. 10 Verbindungen nutzt er, die sind dann im idle, aber irgendwie werden die nicht mehr freigegeben. Erst wenn ich die App neu starte, werden die Verbindungen wieder freigeben.

Hat jemand eine Idee und könnte mir auf die Sprünge helfen? Hab auch schon maxLifetime runter genommen, aber da tut sich auch nix.

spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect
spring.datasource.url=${DATASOURCE_URL}
spring.datasource.username=${DATASOURCE_USER}
spring.datasource.password=${DATASOURCE_PASSWORD}
spring.jpa.generate-ddl=false
spring.jpa.enabled=false
spring.jpa.hibernate.ddl-auto=none
spring.datasource.hikari.maximumPoolSize=10
spring.datasource.hikari.idleTimeout=600000
spring.datasource.hikari.maxLifetime=1800000

@Repository
public class OfferRepository {

    @Autowired
    private JdbcClient jdbcClient;

    public int getCountPendingOffers(Optional<Void> filter) {
        return jdbcClient.sql("SELECT COUNT(*)xxxxxx")
                .param("customerId", filter.get())
                .query(Integer.class)
                .single();
    }

}

 

[Oneixee5]

Vermutlich liegt das an dem Optional<Void> filter - Parameter, die Abfrage wird ewig warten, bis da etwas herauskommt.
Optional ist kein Datentyp für Parameter sondern für die Rückgabe von Methoden - das Thema hatten wir schon mal.

 

[thecain]

Hikari versucht doch immer ein paar Sessions bereit zu halten
idle ist mMn korrekt, wenn sie auch wiederverwendet werden.

Vll könnte man minmumIdle auf 0 setzen, damit die sessions mal auf 0 runter gehen.

 

[OnDemand]

Vermutlich liegt das an dem Optional<Void> filter - Parameter, die Abfrage wird ewig warten, bis da etwas herauskommt.
Optional ist kein Datentyp für Parameter sondern für die Rückgabe von Methoden - das Thema hatten wir schon mal.

Selbiges Verhalten tritt allerdings auch auf, wenn ich einen Integer als Parameter übergebe

Vll könnte man minmumIdle auf 0 setzen, damit die sessions mal auf 0 runter gehen.

spring.datasource.hikari.minimum-idle=0
hat leider auch nichts gebracht, hm echt strange.

Irgendwie scheint es ein anderer Query zu sein der nicht fertig wird und daher die Verbindung nicht wieder freigibt. Oder liegt das an JDBCClient dass man da die Verbindung wieder freigeben muss? Aber das wäre nicht im Sinne des Erfinders, muss irgendeine andere Ursache haben

Edit: hab meine 3, 4 Queries manuell ausgeführt, da wartet nix ewig oder so. Ergebnisse kommen sofort. Das muss also irgendwas in der Konfiguration sein

 

[LimDul]

Im Zweifellsfall bei sowas das Log Level hochdrehen, das man sieht welche SQL Querys abgesetzt werden - ggf. Log Statements in die Methoden einbauen (before/after Query).

 

[OnDemand]

Es lag an einer Methode, die einen Stream zurück gegeben hat. So hier funktioniert es:

    public List<OrderRecord> findWithPagination(int offset, int limit, int supplierId) {
        try (Stream<OrderRecord> stream = jdbcClient.sql(selectAllOrdersLimited)
                .param("offset", offset)
                .param("limit", limit)
                .param("meineId", supplierId)
                .query(OrderRecord.class)
                .stream()) {
            return stream.collect(Collectors.toList());
        }
    }

vorher:

    public Stream<OrderRecord> findWithPagination(int offset, int limit, int supplierId) {
        return jdbcClient.sql(selectAllOrdersLimited)
                .param("offset", offset)
                .param("limit", limit)
                .param("meineId", supplierId)
                .query(OrderRecord.class)
                .stream();
    }

Was aber ist da genau das Problem? Der Stream wird offenbar nicht beendet oder ähnlich?

 

[Oneixee5]

Hier würde die Doku weiterhelfen:

Streaming Results​

When you specify Stream as the return type of a query method, Spring Data JDBC returns elements as soon as they become available. When dealing with large amounts of data this is suitable for reducing latency and memory requirements.

The stream contains an open connection to the database. To avoid memory leaks, that connection needs to be closed eventually, by closing the stream. The recommended way to do that is a try-with-resource clause. It also means that, once the connection to the database is closed, the stream cannot obtain further elements and likely throws an exception.

Also formal ist deine 1. Variante richtig und die 2. schließt die Verbindung nicht. Allerdings könnte man auch gleich JdbcClient.list() aufrufen.