Configuring NetBeans Services Window Pool Metrics Update Frequency for GlassFish DataSource

Direct Answer

No, NetBeans cannot be configured to poll GlassFish DataSource pool metrics at a user‑defined interval independent of the server’s monitoring push. The IDE acts as a passive JMX consumer; it registers a NotificationListener for AttributeChangeNotification on the JDBCConnectionPoolMBean and updates the Services window only when the server emits a notification.

Modifying the global GlassFish heartbeat interval in domain.xml (heartbeat-interval-in-seconds) is not recommended for this purpose. That setting governs cluster membership, GMS failure detection, session replication, and deployment synchronization—not the monitoring sample rate. Reducing it increases network chatter and management CPU load across the entire domain and can destabilize clustered environments.

Confirmed Workaround: Raise the JDBC Pool Monitoring Level

The supported lever is the monitoring level for the jdbc-connection-pool module. Setting it to HIGH instructs GlassFish to emit pool statistics approximately every 2 seconds (default sample rate), which NetBeans will reflect without touching the global heartbeat.

Steps (external domain, persistent across restarts)

1. Stop the GlassFish domain.
2. Edit ${domain.dir}/config/domain.xml and locate the <monitoring-service> element.
3. Add or update the module monitoring level:
   

   <module-monitoring-levels jdbc-connection-pool="HIGH"/>

4. Restart the domain.
5. Verify with asadmin get monitoring-level.jdbc-connection-pool (should return HIGH).

Steps (embedded GlassFish started by NetBeans)

Embedded domains write a temporary domain.xml in the user directory; changes are lost when the IDE restarts. To persist, externalize the domain (Tools → Servers → GlassFish → Edit → Domain → Use existing domain) and apply the change there.

Side Effects and Limitations

• CPU/memory overhead grows proportionally to the number of monitored pools. Monitor server.log for increased monitoring log volume.
• UI granularity ceiling: NetBeans repaints the Services window roughly once per second, so sub‑second updates are not achievable.
• Cluster impact: HIGH monitoring is safe for standalone domains; in clusters it adds per‑instance load but does not alter heartbeat‑driven coordination.

True Near‑Real‑Time Alternative

For polling at a custom interval (e.g., 500 ms) without any server‑side configuration side effects, use GlassFish’s built‑in monitoring REST endpoint:
http://host:4848/monitoring/domain/server/resources/jdbc-connection-pool/*

Poll this endpoint from a script, Grafana, or a custom dashboard. It returns current pool statistics (numConnUsed, numConnFree, waitQueueLength, etc.) on demand and is completely decoupled from the IDE’s JMX listener.

Verification Checklist

• After enabling HIGH, connect jconsole or jmxterm to port 8686 and confirm AttributeChangeNotification frequency on amx:pp=/mon/server-mon[server],type=jdbc-connection-pool,name=*.
• Observe the Services window refresh cadence; it should align with the ~2 second sample interval.
• Check server.log for any warning about monitoring overhead.

One Missing Detail

Are you using the embedded GlassFish instance that NetBeans manages or an external, pre‑configured domain? The answer determines whether domain.xml edits persist across IDE restarts and whether the HIGH monitoring level change is practical for your workflow.