apache / apache/cloudstack

Connection Pool Leak in Out-of-Band Management (OOB) background task causes Management Server crash (HikariPool MaxActive Exhaustion)

Đang mở
#13,382 8 bình luận 0 reaction 0 người được giao Xem trên GitHub
component:database component:management-server Severity:Major type:bug
Ngôn ngữ chính
Java
Star
3.1k
Fork
1.4k
Merge trung bình
6 ngày 19 giờ
Pull request đã merge (30 ngày)
32

Mô tả

### 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?

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Hướng nghiên cứu

Bắt đầu bằng việc truy vết quá trình thực thi tác vụ nền OOBM và đường đi của việc thu nhận cũng như giải phóng kết nối cơ sở dữ liệu; issue không nêu các tệp hoặc bài kiểm thử cụ thể. Tái hiện với khoảng thời gian thực thi được rút ngắn, đồng thời so sánh các mục trong danh sách tiến trình MySQL với các chỉ số pool của CloudStack. Được xem là hoàn tất khi các lần chạy tác vụ lặp lại trả các kết nối về pool và số lượng kết nối đang hoạt động không còn tăng về phía mức tối đa đã cấu hình.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
java, mysql
Lĩnh vực
backend, database, infrastructure
Loại issue
Lỗi
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Sôi nổi
Độ rõ ràng
Khá rõ ràng
Mức phù hợp với người mới
48/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.