Mirth Connect 3.7 introduces dozens of new features, improvements, and bug fixes. Java support has expanded significantly, as Mirth Connect now supports Java 11, as well as most OpenJDK distributions. The database connections Mirth Connect uses can now be separated into read/write and read-only pools, which means you can leverage read-replica database scaling for running Mirth 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
• OpenJDK Support
• Database Connection Pool Options
• Advanced Clustering – Guaranteed Message Order
• User Authorization – Channel Tags / Groups
• Other Features / Enhancements

You can find a list of issues completed for this release here.

Java 11 is the newest "major" release of Java, and with it comes lots of great features like TLS 1.3 support. It's also the latest LTS release for Oracle support customers. Java 8 is not yet EOL so it can still definitely be used.

Supported Java versions for each NextGen Connect version appear in this table:

In January 2019 Oracle will no longer provide free public security updates for their official distributions of Java 8. Java 9 and 10 are short-term releases and this are already EOL. Java 11 has been released, but even then, Oracle's new licensing changes means that you need to purchase Oracle support in order to use their official JDK in production: https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

Because of this, we've brought support to Mirth Connect for other OpenJDK distributions as well. The official Oracle OpenJDK JDK distribution is recommended as that's what we've done the most testing with. However you can use other distributions as well like Azul Zulu, AdoptOpenJDK, RedHat OpenJDK, or other custom builds.

So when public security updates cease for Oracle JDK 8, you won't be forced to purchase Oracle support. You can choose whatever Java distribution you want.

In previous versions, there was a connection pool dedicated to the Donkey engine (message processing), and a separate pool dedicated to everything else, like Administrator or API actions.

In 3.7, this has been changed somewhat. You have two options:

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.

To combine all database connections used by Mirth 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 you may want to increase database.max-connections to compensate for the database-readonly.max-connections value that will no longer be used.

Our Advanced Clustering extension is great for horizontally scaling your Mirth Connect servers. Paired with a load balancer (such as our Mirth Appliance load balancer or something else like HAproxy), you can greatly improve throughput by allowing a channel to deploy and run on multiple servers simultaneously.

However in some cases you may want messages for a particular channel to be processed in order. With 3.7 this is now possible with Advanced Clustering. A "Guarantee Message Order" option can be set on a per-channel basis, so that you can restrict order on one channel while leaving the rest alone. It can also be set at the individual destination queue level, where the queue will only be processed on a single node.

In previous versions you could select specific channels that a role should be restricted to. This has been expanded in 3.7 with additional tag/group options. With this you can create more fine-tuned roles. For example you can decide that a particular user should only be able to View/Manage channels that have a certain tag, or that belong to a certain group.

• JavaScript ES6: There is a new setting for mirth.properties that determines what JavaScript/ECMAScript version that the Rhino engine should use. For migrated servers the setting will remain as "default" so no behavior will change. For new installations the setting is "es6", which enables some ES6-specific features like arrow functions.
• File Writer – Keep Connection Open: The default behavior is for File Writers to open a new connection when the first message is sent, and keep that connection open forever until the connector is stopped. In 3.7 there are additional options so you can choose whether to keep connections open or not. When keeping connections open you can also choose how long a connection may remain idle before it gets automatically closed.
• Environment Name: In addition to the Server Name on the Server Settings tab, there is now a new Environment Name field. The difference is that the Environment Name is unique per database, whereas that Server Name is unique per server-instance. So if you have multiple servers in a cluster, there is a single environment name and possibly multiple server names.
• Enable / Disable Steps: Filter rules and transformer steps can now be disabled and enabled at your discretion. This can allow you to more easily troubleshoot, test, and work on changes without yet having them enabled in the channel.
• Reset Administrator Preferences: There are a lot of hidden preferences that are stored on your local machine when using the Administrator, like column size/order for the dashboard table. The Administrator settings tab now allows you to completely reset all of those preferences now if you want.
• Obfuscate Configuration Map Values: The values in the Configuration Map tab are now obfuscated by default, meaning they won't show up on screen unless you edit the value, or you check the "Show Values" option.