Knowledge Base
Knowledge Base
  • Login
Font Size:
Ask Joget AI

Database Monitoring and Leak Detection

Introduction

Joget DX is rigorously tested to guarantee no leaks in memory, database connections, or other resources at the platform level. However, developers implementing custom scripts and plugins must take additional precautions to manage resources correctly and ensure all database connections and other resources are properly released after use. This is best achieved using a try-catch-finally block in the code. Failure to adequately manage resources can lead to their exhaustion, causing the system to become unresponsive or appear to hang.

Platform database monitoring

The Performance Analyzer monitors database connections at runtime, with warnings of possible connection leaks. When logged in as an administrator, the Performance Analyzer displays the number of active and idle platform data source connections at the top left corner of the app user view.

What the numbers mean:

  • Active = connections currently being used right now.
  • Idle = connections that are open but not currently doing anything (kept ready for reuse).

What healthy looks like: these numbers go up when there's more traffic or activity, and come back down once that activity finishes.
What a leak looks like: the numbers keep climbing over time and never come back down, even when things are quiet. That's a sign something isn't releasing its connections.

Connection leak detection in custom JDBC code

While the platform data source is monitored by default, custom JDBC code in BeanShell scripts or plugins often utilizes separate JDBC connections. To address this, Joget includes a warning mechanism:

  • This system tracks unclosed JDBC connections that could lead to leaks. The detection is effective for both BeanShell and custom plugin code.
  • A warning is logged in the platform log file when a potential leak is detected. For example:
WARN 22 Aug 2016 12:06:10 org.joget.commons.util.Analyzer - Possible unclosed DB connections: 4; URL: /jw/web/userview/dbtest/v/_/form1_crud
  • The warning provides the URL path, aiding administrators in identifying which page is causing the issue.
It's important to note that the leak detection system might not catch every instance, as variations in custom code can lead to leaks in ways that are not always predictable. Nevertheless, this feature is a valuable tool for detecting many common issues with JDBC code.

Data Source Configuration for Connection Pool Tuning

In scenarios where connection pool exhaustion or potential connection leaks are observed, additional tuning of the platform data source configuration may help improve connection management and stability.

Administrators may consider adding or adjusting the following parameters in the data source profile:

maxActive=10000
maxWait=10000
minEvictableIdleTimeMillis=1800000
minIdle=100
removeAbandoned=true
removeAbandonedTimeout=600
timeBetweenEvictionRunsMillis=10000
It's important to note that these settings are intended as tuning options and should be applied with caution. We strongly recommend conducting thorough testing in a non-production environment before deploying these changes to production, as improper configuration may impact system performance or resource usage.
Created by Marcos Last modified by Siti Noratiqah on Sep 09, 2026
Tags:
Previous Customizing App Center NextUsing GIT for Feature Development in Joget