You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by "mortenstevens (via GitHub)" <gi...@apache.org> on 2026/06/09 08:55:03 UTC
[I] Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion) [cloudstack]
mortenstevens opened a new issue, #13382:
URL: https://github.com/apache/cloudstack/issues/13382
### problem
We are experiencing a critical connection leak in Apache CloudStack 4.22.1.0 (running on Ubuntu 24.04). The background task for Out-of-Band Management (OOBM) leaks database connections every time it executes.
Even when setting wait_timeout on MySQL server side or trying to inject pool properties, the connections remain blocked within the Java application state as active, eventually hitting the db.cloud.maxActive threshold (default 250), which causes the management server to stop responding and throw SQLTransientConnectionException.
### versions
CloudStack Version: 4.22.1.0
OS: Ubuntu 24.04.4 LTS
DB: MySQL 8.0.45
Java Version: 17.0.19
### The steps to reproduce the bug
1. Configure Out-of-Band Management (OOBM) for multiple physical hosts
2. Set outofbandmanagement.background.task.execution.interval to a lower value for testing purposes (e.g., 60 or 300 to accelerate the leak
3. Monitor the MySQL SHOW FULL PROCESSLIST; vs. the CloudStack Management Server Metrics over time.
...
### What to do about it?
Every time the OOBM task runs, it opens 1 connection per configured host (3 connections in total for our setup). These connections are never returned to the HikariCP pool (missing .close() or unhandled exception block in the OOBM plugin execution layer).
The Mismatch between DB and Java Pool:
MySQL Side: Sells connections as Sleep. If MySQL kills them via wait_timeout, the sockets are closed on the network layer.
CloudStack/HikariCP Side: Because the leaked connections are still flagged as active (In-Use) by the OOBM thread, HikariCP never runs a health check on them and refuses to evict them via maxLifetime. The internal counter stays at active=250.
Once the counter hits 250, the management server crashes.
Logs & Error Stacktrace:
2026-06-08 21:14:28,070 ERROR [c.c.s.S.ManagementServerCollector] (StatsCollector-1:[ctx-fd90ba07]) (logid:182faa68) Error trying to retrieve management server host statistics com.cloud.utils.exception.CloudRuntimeException: Unable to find on DB, due to: cloud - Connection is not available, request timed out after 30000ms (total=250, active=250, idle=0, waiting=22)
Is there any workaround available? Maybe switching to dbcp?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion) [cloudstack]
Posted by "mortenstevens (via GitHub)" <gi...@apache.org>.
mortenstevens commented on issue #13382:
URL: https://github.com/apache/cloudstack/issues/13382#issuecomment-4679170800
@shwstppr
Switching the connection pool library from HikariCP to DBCP2 did not resolve the problem.
Update on the issue:
We have performed some additional testing and successfully isolated the conditions under which this connection leak occurs.
The Setup: Multiple physical hosts controlled via Dell iDRAC 9 using the Redfish driver.
When the global setting outofbandmanagement.background.task.execution.interval was set to 300 seconds (5 minutes), the database connections accumulated indefinitely until the pool was completely exhausted, regardless of the pool backend used.
Our Workaround: We found that lowering the execution interval of outofbandmanagement.background.task.execution.interval to 60 seconds mitigates the issue. At this higher frequency, both Java and MySQL inactive sessions are automatically and consistently reaped/evicted shortly after reaching approximately 1000 seconds of idle time.
It appears the OOBM background task logic might only trigger proper connection/transaction cleanup routines under high-frequency conditions (like the 60s or lower, while failing to close connections properly when longer intervals are configured.
Hope this helps to pinpoint the bug.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion) [cloudstack]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on issue #13382:
URL: https://github.com/apache/cloudstack/issues/13382#issuecomment-5346145820
## ๐ฏ Triage report
The Out-of-Band Management (OOBM) background task appears to leak DB connections (HikariCP or DBCP2) on each execution, eventually exhausting the pool (`db.cloud.maxActive`) and crashing the management server. The reporter and another user independently reproduced growing connection counts tied to OOBM being enabled, and a related discussion (#13542) reports thread dumps after disabling OOBM resolved crashes.
### ๐ Assessment
| Dimension | Value | Reasoning |
|---|---|---|
| **Type** | type:bug | Confirmed connection-pool exhaustion reproduced by multiple users, independent of pool backend (HikariCP and DBCP2 both affected). |
| **Component** | component:management-server, component:database | OOBM background task and DB connection pool management are management-server/database concerns. |
| **Severity** | Severity:Major | Leads to full management server outage (SQLTransientConnectionException) once the pool is exhausted; workaround (disable OOBM or shorten interval) exists but core feature becomes unusable at default settings. |
| **Labels** | type:bug, component:management-server, component:database, Severity:Major | See above |
| **Coding agent** | Needs more info | Root cause (missing `.close()`/connection not released to pool in the OOBM plugin execution path) is suspected but not pinpointed to a specific file/line; needs code-level investigation before a fix can be implemented. |
### ๐ Similar issues
- https://github.com/apache/cloudstack/discussions/13542 (related) โ separate report of management server crashes tied to OOBM, resolved by disabling OOBM; includes thread dumps that may help root-cause this.
<details><summary>๐ก Notes and suggestions</summary>
Confirmed reproduction steps from comments: enable OOBM for hosts, set `outofbandmanagement.background.task.execution.interval` to a longer interval (e.g. 300s), and watch `information_schema.processlist` grow. A maintainer (kiranchavala) already reproduced this. Suggest searching the OOBM background task/driver code for DB connection acquisition that isn't wrapped in try-with-resources or a finally-block release.
</details>
> Generated by [Daily Issue Triage](https://github.com/apache/cloudstack/actions/runs/32259459580) ยท sonnet50 262K ยท [โท](https://github.com/search?q=repo%3Aapache%2Fcloudstack+%22gh-aw-workflow-call-id%3A+apache%2Fcloudstack%2Fdaily-issue-triage%22&type=issues)
>
<details>
<summary>Add this agentic workflows to your repo</summary>
To install this agentic workflow, run
```
gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9
```
</details>
<!-- gh-aw-agentic-workflow: Daily Issue Triage, engine: copilot, version: 1.0.52, model: claude-sonnet-5, id: 32259459580, workflow_id: daily-issue-triage, run: https://github.com/apache/cloudstack/actions/runs/32259459580 -->
<!-- gh-aw-workflow-call-id: apache/cloudstack/daily-issue-triage -->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion) [cloudstack]
Posted by "shwstppr (via GitHub)" <gi...@apache.org>.
shwstppr commented on issue #13382:
URL: https://github.com/apache/cloudstack/issues/13382#issuecomment-4680823804
@mortenstevens thanks for the detailed update. I'll try to find time to test this and will update you
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion) [cloudstack]
Posted by "shwstppr (via GitHub)" <gi...@apache.org>.
shwstppr commented on issue #13382:
URL: https://github.com/apache/cloudstack/issues/13382#issuecomment-4679061317
@mortenstevens this would need some investigation. If it helps and you mentioned you can switch to using dbcp,
https://docs.cloudstack.apache.org/en/4.22.0.0/adminguide/tuning.html#selecting-database-connection-pool-library
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion) [cloudstack]
Posted by "boring-cyborg[bot] (via GitHub)" <gi...@apache.org>.
boring-cyborg[bot] commented on issue #13382:
URL: https://github.com/apache/cloudstack/issues/13382#issuecomment-4658097540
Thanks for opening your first issue here! Be sure to follow the issue template!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion) [cloudstack]
Posted by "shwstppr (via GitHub)" <gi...@apache.org>.
shwstppr commented on issue #13382:
URL: https://github.com/apache/cloudstack/issues/13382#issuecomment-5511216066
@mortenstevens this should be resolved in the recent 4.22.1.1 release. Would it be possible to confirm?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion) [cloudstack]
Posted by "kiranchavala (via GitHub)" <gi...@apache.org>.
kiranchavala commented on issue #13382:
URL: https://github.com/apache/cloudstack/issues/13382#issuecomment-4862684339
Able to reproduce the issue , count increases when oobm is configured
```
mysql> SELECT COUNT(*) FROM information_schema.processlist WHERE db = 'cloud';
+----------+
| COUNT(*) |
+----------+
| 84 |
+----------+
1 row in set, 1 warning (0.00 sec)
mysql> SELECT COUNT(*) FROM information_schema.processlist WHERE db = 'cloud';
+----------+
| COUNT(*) |
+----------+
| 92 |
+----------+
1 row in set, 1 warning (0.00 sec)
mysql> SELECT COUNT(*) FROM information_schema.processlist WHERE db = 'cloud';
+----------+
| COUNT(*) |
+----------+
| 96 |
+----------+
1 row in set, 1 warning (0.00 sec)
mysql> SELECT COUNT(*) FROM information_schema.processlist WHERE db = 'cloud';
+----------+
| COUNT(*) |
+----------+
| 100 |
+----------+
1 row in set, 1 warning (0.00 sec)
mysql> SELECT COUNT(*) FROM information_schema.processlist WHERE db = 'cloud';
+----------+
| COUNT(*) |
+----------+
| 100 |
+----------+
1 row in set, 1 warning (0.00 sec)
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion) [cloudstack]
Posted by "MitchDrage (via GitHub)" <gi...@apache.org>.
MitchDrage commented on issue #13382:
URL: https://github.com/apache/cloudstack/issues/13382#issuecomment-4890073259
I encountered what I thought was a similar issue and opened a discussion on the topic. I've since found that it was in fact the same issue - after disabling OOBM the management server, the crashes I was experiencing have ceased.
I have some thread dumps in the below discussion and thought I would link to the discussion in case it was useful.
https://github.com/apache/cloudstack/discussions/13542
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org