At the platform level, Joget Workflow has been tested to ensure that there are no leaks in memory or database connections and other resources. However, for custom scripts and plugins, etc, developers will need to ensure that database connections and other resources are properly released after being used (i.e. using a try-catch-finally block). Improper management of resources will lead to eventual exhaustion of resources, causing the system to become unresponsive or appear to hang.
Platform Datasource Monitoring
In v6, a new feature incorporated into the Performance Analyzer now provides monitoring of database connections at runtime, with warnings of possible database connection leaks.When logged in as an administrator, the Performance Analyzer displays the number of active and idle platform datasource connections at the top left corner of the app userview.
In a stable environment, the number of active and idle connections will increase when load increases, and reduce accordingly once connections are released. When connections are not being released properly the number of connections will keep increasing without reducing, which would give an indication of possible connection leaks.
Connection Leak Detection in Custom JDBC Code
This connection monitoring keeps track of the platform datasource. However, there are also many cases where custom JDBC code in BeanShell scripts or custom plugins do not use the platform datasource, and utilize their own JDBC connections. To cater for this, there is a warning mechanism that checks for potential unclosed JDBC connections that may cause leaks. This detection works for both BeanShell and custom plugin code. When a possible leak is detected, a warning will be captured in the platform log file, e.g.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 includes the URL path, so this allows administrators to identify the page causing the problem.
Please note that the leak detection may not work 100% as there are many variations in which custom code may cause connection leaks, but it should help to detect problems in most common JDBC code.