# Hikari Pool Connection Validation



## OnDemand (5. Jul 2020)

Hallo zusammen,

ich habe einen Connection Pool wie unten, allerdings bekomme ich ständig folgende Fehlermeldungen und die Verbindungen sind geschlossen. Hat jemand ne Idee?

No operations allowed after statement closed.
Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@20221c8d (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.


```
HikariConfig config = new HikariConfig();
                    config.setJdbcUrl(tenantProperties.getProperty("datasource.url") + "&serverTimezone=" + TimeZone.getDefault().getID());
                    config.setUsername(tenantProperties.getProperty("datasource.username"));
                    config.setPassword(tenantProperties.getProperty("datasource.password"));
                    config.setPoolName(tenantId);
                    config.setMaximumPoolSize(5);
                    HikariDataSource ds = new HikariDataSource(config);
                    ds.setIdleTimeout(600000);
```

Hab schon maxLifeTime gesetzt auf verschiedene Werte, aber bringt nix. Meine DB hat standard 28800s wait_timeout hat das damit irgendwas zu tun?

Hier in der Methode kommt der Fehler (Hibernate kümmert sich ums das Schließen der Verbidnungen bzs zurückgeben in den Pool mit Spring boot)


```
private void doWork(){}
Session hibernateSession = em.unwrap(Session.class);
            hibernateSession.doWork(new org.hibernate.jdbc.Work() {
                @Override
                public void execute(Connection connection) {
                //do da work Prepeared Statement
                }
}
```


----------



## mihe7 (6. Jul 2020)

Hilft Dir https://github.com/brettwooldridge/HikariCP/issues/1034 ?


----------



## OnDemand (6. Jul 2020)

Danke, aber was ist der HA Proxy Timeout? In Mysql sehe ich massig logs "is marked as crashed and should be repaired" aber die sind ok, Tabellen kann ich aufrufen


----------



## mihe7 (6. Jul 2020)

Wenn ich es richtig verstehe, dann muss der Werte von wait_timeout (SHOW VARIABLES like '%timeout%') gleich oder sogar etwas größer sein als maxLifeTime. Oder irgendwas anderes schließt die Connection, z. B. im Code.


----------



## OnDemand (6. Jul 2020)

Der RAM ist scheinbar nicht ausreichend  Zu viele Connections im Pool. MaxLifetime setz ich mal auf 10% unter wait_timeout


----------



## mihe7 (6. Jul 2020)

NicoDeluxe hat gesagt.:


> Zu viele Connections im Pool.


OMG, wie viele Connections hast Du denn?!?


----------



## OnDemand (6. Jul 2020)

5 pro User (Tenante Datenbank)


----------



## LimDul (6. Jul 2020)

Ich bin gerade verwirrt - ist der Sinn eines Pools, dass ich nicht eben für jeden User X-Connections vorhalte sondern einen globalen Pool?


----------



## OnDemand (6. Jul 2020)

Es gibt mehrere Pools, pro Tenant 1 pool. Man könnte vielleicht auch einen Pool mit allen Verbindungen machen
Hab jetzt auf 2 Verbindungen reduziert, hoffe dass es reicht. Keine Möglichkeit RAM zu erhöhen die Tage :/


----------



## mihe7 (6. Jul 2020)

NicoDeluxe hat gesagt.:


> Es gibt mehrere Pools, pro Tenant 1 pool.


Meintest Du oben pro Tenant 5 Connections?


----------



## OnDemand (6. Jul 2020)

jop pro Tenant 5 Connection, jetzt 2


----------



## mihe7 (6. Jul 2020)

Stehen die Tenants in der gleichen DB? Und wie viele sind das?


----------



## OnDemand (6. Jul 2020)

Die Tenants in der gleichen DB wie meinst du das? Jeder Tenant hat eine eigene DB auf einem großen Server, vielleicht 100 tenants derzeit

Jetzt viel mir auf, dass der RAM wächst, unser Programm macht stündlich was auf die Datenbanken und jedesmal wächst der RAM des DB Servers um 200BM anstatt nach dem Abarbeiten der Queries wieder weniger zu werden.


----------



## mihe7 (6. Jul 2020)

NicoDeluxe hat gesagt.:


> Jeder Tenant hat eine eigene DB auf einem großen Server, vielleicht 100 tenants derzeit


Das wären also etwa 200 Connections. Die sollten IMO nicht das Problem darstellen.



NicoDeluxe hat gesagt.:


> Jetzt viel mir auf, dass der RAM wächst, unser Programm macht stündlich was auf die Datenbanken und jedesmal wächst der RAM des DB Servers um 200BM anstatt nach dem Abarbeiten der Queries wieder weniger zu werden.



https://blog.pythian.com/mysql-memory-consumption/ enthält interessante Infos zum Speicherverbrauch.


----------



## OnDemand (6. Jul 2020)

Die Mysql Variablen sind alle default :/ Das ist echt merkürdig, nicht mal der neustart des angebundenen Service macht den RAM auf dem DB Server frei. Also muss mysql da iwas speicehrn. Das geht so lange gut bis er voll ist und die Connections schließt.

Muss ich vielleicht in meiner og Methode irgendwas schließen? Laut einiger Beiträge darf die connection nicht geschlossen werden. Wenn ich das Prepeared Stement schließe kommt auch wieder irgendeine Fehlermeldung.


----------



## mihe7 (6. Jul 2020)

NicoDeluxe hat gesagt.:


> Laut einiger Beiträge darf die connection nicht geschlossen werden.


Die Connection muss vom Connection Pool geschlossen werden - dafür ist er ja da. Es ist auch normal, dass die DB Speicher frisst - das soll so sein, denn alles, was im Speicher liegt, kann ohne I/O in die Peripherie beantwortet werden. Nur sollte es natürlich nicht zu viel werden. Was allerdings interessant ist: dass das Speicher beim Schließen der Connection freigegeben wird. Das hört sich nach verbindungsbezogenen Daten an. Gem. der Formel aus dem Blog würde ich mir read_buffer_size, join_buffer_size, read_rnd_buffer_size, thread_stack und max_packet_size ansehen.


----------



## OnDemand (6. Jul 2020)

Danke, ich kann damit leider nicht so viel anfangen. Meiner Meinigung nach sind das alles Standardwerte (die vielleicht nicht immer gut sind)

Folgende Werte sind gemäß Konsole gesetzt:
read_buffer_size=131072
join_buffer_size =262144
read_rnd_buffer_size = 262144
thread_stack  = 299008
max_packet_size  EMTPY SET


----------



## OnDemand (7. Jul 2020)

Also es scheint so, dass ein bestimmter Service Schuld ist. Der ballert einfach verdammt viel Daten an die DB. Was aber komisch ist, dass die DB den RAM nicht freigibt sondern einfach iwann die Connections killed.


----------



## LimDul (7. Jul 2020)

Mal ganz doof gefragt - diese verdammt viele Daten, ist das eine Transaktion oder mehrere? Weil wenn das eine Transaktion ist, kann ich mir vorstellen, dass die eher im RAM gehalten wird, als wenn es mehrere sind.


----------

