Mirth Connect Database Connection Pool Exhausted: Causes and Fix

A Mirth Connect database connection pool exhausted error surfaces in the server log as org.apache.commons.pool2.impl.GenericObjectPool - Timeout waiting for idle object, meaning every connection in the pool is already checked out when a channel tries to query. This usually isn't a database outage — the database is fine, but Mirth has simply run out of connections to reach it.

Below is what actually eats the pool, how to fix it without guessing at settings, and how to stop the same channel doing it again next week. Our free Mirth Health Check reviews active connection counts against your configured pool size, part of the Mirth Connect support work we do for US healthcare teams.

Every Database Reader and Database Writer connector in Mirth draws from a connection pool sized in that connector's own settings, not a single shared pool for the whole server. When more channels or threads request connections than the pool allows, or a connection is opened but never returned, every subsequent request waits until it times out and throws the exhaustion error. The trigger is almost always a specific connector, not the database engine itself, which is why the fix starts with finding which one.

Too Many Channels Sharing One Database Connection Pool

Several Database Writer channels pointed at the same database, each with a modest pool size, can collectively open more connections than the database server allows. The error can appear even when no single channel looks overloaded on its own.

Long-Running Queries Holding Connections Open

A slow report query or an unindexed lookup inside a Database Reader can hold its connection for far longer than a typical message-processing query. Under load, this single slow query is often enough to starve the rest of the pool.

Unclosed JDBC Resources in Custom JavaScript

Custom code that opens a Statement or ResultSet directly, outside the connector's managed query, must close it explicitly. A script that returns early on an exception without a finally block leaks that connection permanently until the channel restarts.

Pool Size Set Too Low for Current Message Volume

A pool sized correctly at launch can become undersized as message volume grows over months. The default pool size in many Mirth installs is conservative and rarely gets revisited once a channel is deployed and working.

Start by identifying which connector is actually holding the connections rather than immediately raising every pool size on the server. A blanket increase can mask a genuine leak instead of fixing it, and it just delays the same crash at a higher message volume later. The fixes below move from the least disruptive change, adjusting a single setting, to the most disruptive, restarting a production channel, so work through them in order.

Increase the Max Active Connections Setting

In the Database Reader or Writer connector's advanced settings, raise the max active connections value incrementally rather than doubling it outright. Redeploy the channel and monitor whether the pool still saturates under the same load pattern.

Add a Connection Validation Query

A simple validation query like SELECT 1 configured on the connector ensures dead connections are discarded and replaced rather than held as unusable pool slots. This alone resolves exhaustion caused by connections silently dropped by the database or network.

Close Statements and ResultSets in Custom Code

Any custom JavaScript that opens its own JDBC objects should close them in a finally block, not just after a successful query. Reviewing recently modified transformers for this pattern is the fastest way to find an active leak.

Restart the Channel to Release Stuck Connections

If connections are already exhausted, restarting the affected channel forces the pool to reset and release anything held by dead threads. This clears the immediate crash but does nothing for the underlying cause if a leak exists.

Once the immediate crash is resolved, the goal shifts to catching a growing pool before it saturates again rather than discovering the same problem through another production outage next quarter. This is largely a monitoring and code-review problem, not a one-time configuration fix, since pool exhaustion tends to return once message volume grows past whatever level the original settings were sized for.

Monitor Active vs Idle Connections

Most databases expose active and idle connection counts per application or user, checkable against Mirth's configured pool size on a schedule. A pool consistently near its ceiling during normal hours is a leading indicator, not just a post-mortem detail.

Give High-Volume Channels a Dedicated Pool

Isolating your highest-volume Database Writer channel to its own pool, separate from lower-priority channels sharing the same database, prevents one busy channel from starving another. This trades a little connection overhead for predictable behavior under load.

Set Sensible Connection and Query Timeouts

A connection or query timeout configured on the connector stops a single slow query from holding a connection indefinitely. Without a timeout, one bad query can effectively behave like a leak even though the code itself is correct.

Code Review Custom Database Scripts Regularly

Any custom JavaScript touching JDBC objects directly deserves periodic review as channels change over time, since an edit made months later can reintroduce a leak already fixed once. Treat it like any other production code path.

If you've raised the pool size and added a validation query and the error still recurs, the cause is almost always a leak in custom JDBC code that only shows up under real production load. Our free Mirth Connect health check reviews active connection counts against configured pool sizes as part of the standard diagnostic.

Book a Free Health Check →

Prefer to send the exact error first? Send us the log for a direct diagnosis, or check pricing for ongoing support plans.