web stats

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Mirth Connect 3.7 introduces dozens of new features, improvements, and bug fixes. Java support has expanded significantly, as Connect now supports Java 11, as well as most OpenJDK distributions. The database connections Connect uses can now be separated into read/write and read-only pools, which means you can leverage read-replica database scaling for running Connect in a cluster. Speaking of clustering, we've made improvements to Advanced Clustering to support Guaranteed Message Order for a particular channel across the entire cluster! Lots of other smaller enhancements as well such as JavaScript ES6 support, a "keep connection open" option for the File Writer, and more.

Java 11 Support
Java 11 Support
Java 11 Support


  • Option 1: Use two pools, one read/write and one read-only
    • This is the default in 3.7. To enable, set this in mirth.properties:
      • database.enable-read-write-split = true

    • When this setting is enabled, the database connection pool is split into two: A read-only pool, and a read/write pool. The read-only pool is used for many of the Administrator API calls that only fetch data. The read/write pool is used for all backend message processing, as well as any operation that creates/modifies/deletes data.

      When the connection pools are split, you can separately configure settings for the read-only pool, with the "database-readonly" options. By default none of the "database-readonly" options are set, meaning that the read-only pool will default to the same configuration as the main read/write pool.

      For example, if "database-readonly.max-connections" is not set, it defaults to the "database.max-connections" setting. So if you have your max connections set to 20 for the read/write pool, the read-only pool will also have up to 20 connections, meaning the total number database connections will be at most 40.

      These settings also allow you to point the read-only connection pool to a completely different database instance. You may want to do this if you have a master DB and a horizontally scaling cluster of read-replica DBs. You can point the main read/write pool to the master DB, and point the read-only pool to the read-replica cluster instead. By doing this you can potentially reduce the traffic and strain on your master database.

      When using read replicas however, the concept of "replica lag" should be taken into account. That refers to the amount of time a read replica DB is behind the master DB. If your replica lag is sufficiently large, all the selects done by the read-only pool may return out-of-date information, which can lead to unintended results in the Administrator.

      The server keeps internal caches for channels, channel groups, code templates, and code template libraries. By default these caches use the read-only pool. But if replica lag is a concern, a separate option, "database.write-pool-cache", allows you to switch the caches over to using the read/write pool instead.

  • Option 2: Use one connection pool for everything
    • To combine all database connections used by Connect into a single pool, set this in mirth.properties:
      • database.enable-read-write-split = false

    • All of the "database-readonly" options will be ignored in this case. If you switch to this mode, note that to you may want to increase "database.max-connections" to compensate for the "database-readonly.max-connections" value that will no longer be used.