Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

core-database: the Spring SystemDB pool (HikariPool-1) ignores every pool setting - honour SystemDB_HIKARI_*

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

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

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
49/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
java, spring-boot
領域
backend, database

調査の方向性

Start with DataSourceSystemConfig#getDataSource, DataSourceInitializer#toHikariPropertyName, and the existing DataSourceInitializer pool configuration and logging. Trace how DirigibleConfig.SYSTEM_DATA_SOURCE_NAME supplies the prefix, then add a unit test showing those properties override Hikari defaults while the defaults remain unchanged. Done means the Spring pool has the configured values, a distinct SystemDB-core name, and startup logs of its effective settings.

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

説明

Problem

The SystemDB Spring bean ignores every pool setting: DataSourceSystemConfig#getDataSource builds it from four values only.

dataSourceProperties.setDriverClassName(...); setUrl(...); setUsername(...); setPassword(...);
return dataSourceProperties.initializeDataSourceBuilder().type(HikariDataSource.class).build();

So the pool runs on Hikari's defaults:

  • maximumPoolSize 10;
  • minimumIdle equal to the maximum, so it is a fixed pool of 10, and idleTimeout has no effect;
  • maxLifetime 30 min and connectionTimeout 30 s;
  • no leak detection;
  • the pool name HikariPool-1.

SystemDB_HIKARI_* does not reach it. Since #7876 those keys are honoured only by DataSourceInitializer.

This bean is the platform's primary DataSource. It serves:

  • JPA (entityManagerFactory);
  • Liquibase (LiquibaseSystemConfig);
  • the Flowable ProcessEngine (BpmFlowableConfig);
  • Quartz (@QuartzDataSource, QuartzConfig).

Separately, DataSourcesManager#getSystemDataSource() creates a second pool to the same database through DataSourceInitializer, from SystemDB.datasource. That pool is named SystemDB and does honour SystemDB_HIKARI_*. So an instance holds two pools to the SystemDB, and only one of them can be sized. SystemDB_HIKARI_MINIMUMIDLE=2 lowers the second pool and leaves the 10 connections of HikariPool-1 in place.

Measured

The setup: a staging landscape with three Dirigible 14.95.0 instances on one RDS db.t4g.small, about 170 usable connections. One instance is multitenant with 10 tenants. We set DefaultDB_HIKARI_MINIMUMIDLE=2 and SystemDB_HIKARI_MINIMUMIDLE=2, and tenant pools are at the default minimumIdle 1.

The result: 46 connections in total, of which 30 are HikariPool-1 (10 per instance, idle). The pool is now the largest fixed cost per instance. During a rolling deploy it is doubled, so every additional application on a shared database pays 10 more, or 20 more while it deploys.

Proposal

  • Apply <system data source name>_HIKARI_* (by default SystemDB_HIKARI_*, from DirigibleConfig.SYSTEM_DATA_SOURCE_NAME) to the Spring bean too.
    • Use the same case-insensitive mapping onto Hikari property names (DataSourceInitializer#toHikariPropertyName), shared rather than copied, so that SystemDB_HIKARI_MINIMUMIDLE works.
    • One set of keys sizes both SystemDB pools.
  • Keep today's behaviour as the default: maximum 10, minimum idle 10. An instance that sets nothing sees no change.
  • Give the pool a name, e.g. SystemDB-core, so that logs and metrics no longer show HikariPool-1. It must differ from the initializer's SystemDB pool, which would clash when MBeans are registered.
  • Log the effective pool at startup, as DataSourceInitializer does: Data source [...] pool: maximumPoolSize [...], minimumIdle [...], idleTimeout [...] ms.
  • A unit test that the properties win over the defaults.
  • Optional, possibly a follow-up: let DataSourcesManager#getSystemDataSource() reuse the Spring bean instead of opening a second pool to the same database. This would save one more pool per instance.
Caveat for the docs

maximumPoolSize of this pool must cover the platform's own concurrent users of the SystemDB:

  • Flowable's async executor threads;
  • the Quartz thread pool;
  • JPA calls from request threads and synchronizers.

Lowering minimumIdle is safe; it only means that a burst after a quiet period opens new connections. Lowering maximumPoolSize below that concurrency would make process steps and jobs wait for connectionTimeout.

Related: #7876 (the same for DataSourceInitializer, shipped in 14.90.0).

主要言語
Java
スター
278
フォーク
97
平均マージ
18時間 57分
マージ済み PR（30日）
249

環境構築

はじめの一歩

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

eclipse-dirigible/dirigible のほかの issue

eclipse-dirigible/dirigible の issue をすべて見る

似ている issue

Java の issue をもっと見る

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

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