Database Explorer connection pool exhaustion with no configurable pool parameters or diagnostic visibility
0 reputation · 19 Apr 2021, 01:33 UTC
0 reputation · 19 Apr 2021, 01:33 UTC
Diagnose intermittent connection pool exhaustion when NetBeans Database Explorer interacts with databases or application servers that enforce connection limits.
The Data Sources UI exposes only URL, username, password, and driver class. HikariCP pool properties such as maximum pool size, idle timeout, minimum idle connections, and eviction policy are not configurable through the IDE. NetBeans 17 relies on HikariCP defaults (maximum pool size of 10), which may be unsuitable for environments with stricter connection caps. No built-in diagnostic surface—metrics, logs, or health endpoints—is provided to observe pool state, queue depth, or timeout events.
35275 reputation · 19 Apr 2021, 05:57 UTC
1. Programmatic exposure of HikariCP metrics – NetBeans does not expose pool settings in the Data Sources UI, but you can enable Hikari’s built‑in JMX support by creating a small wrapper driver that sets registerMbeans=true before the pool is instantiated. Once the MBean is registered, tools such as jconsole, jvisualvm, or a custom JMX client can read maximumPoolSize, activeConnections, and idleConnections in real time.
2. Custom JDBC wrapper or JMX client – Yes. Implement java.sql.Driver, delegate to the real driver, and inside connect() create a HikariConfig with the desired pool size and registerMbeans=true. Register the wrapper via the NetBeans module system (Services/META-INF/services/java.sql.Driver), then use it in the New Connection wizard. A JMX client can connect to the NetBeans JVM and query the com.zaxxer.hikari domain.
3. Extension points for injecting pool configuration – The public Database Explorer API (org.netbeans.api.db.explorer.DatabaseConnection) does not expose the underlying DataSource or HikariConfig. The only supported hook is DatabaseConnection.getDriverInstance(), which returns the raw java.sql.Driver. Therefore, there is no documented SPI for injecting pool parameters; the wrapper approach is the only supported path.
Open a terminal and run:
jcmd <netbeans-pid> VM.system_properties | grep java
Confirm you can attach a JMX client. If you prefer a GUI, launch jconsole and connect to the NetBeans process.
java.sql.Driver.connect() build a HikariConfig:HikariConfig cfg = new HikariConfig();
cfg.setJdbcUrl(url);
cfg.setUsername(user);
cfg.setPassword(pass);
cfg.setMaximumPoolSize(20); // adjust per your server limits
cfg.setRegisterMbeans(true);
HikariDataSource ds = new HikariDataSource(cfg);
return ds.getConnection();
Services/META-INF/services/java.sql.Driver.In the Data Sources UI, choose the wrapper class as the driver. The connection will now use your configured pool.
In jconsole, navigate to com.zaxxer.hikari → Pool → yourPoolName. Inspect attributes like MaximumPoolSize, ActiveConnections, IdleConnections, and QueueSize.
If you need programmatic access, write a small Java program that connects to the same MBeanServer:
MBeanServer server = ManagementFactory.getPlatformMBeanServer();
ObjectName name = new ObjectName("com.zaxxer.hikari:type=Pool,Name=yourPoolName");
Integer max = (Integer) server.getAttribute(name, "MaximumPoolSize");
System.out.println("Max pool: " + max);
To fine‑tune the wrapper, could you confirm which NetBeans version you’re running and how many data sources you typically open? That will help decide whether a single shared pool or per‑connection pools are more appropriate.
registerMbeans is the only programmatic path to metrics.Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.