web stats
Skip to end of metadata
Go to start of metadata

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 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 Mirth Connect version appear in this table:

 

3.0.2 - 3.1.x3.2.x - 3.4.x3.5.x3.6.x3.7.x+
Java 6

(tick)

(error)

(error)

(error)(error)
Java 7

(tick)

(tick)

(error)

(error)(error)
Java 8

(tick)

(tick)

(tick)

(tick)(tick)
Java 9(error)(error)(error)(tick)(tick)
Java 10(error)(error)(error)(tick)(tick)
Java 11+(error)(error)(error)(error)

(tick)

OpenJDK Support

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 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.

Database Connection Pool Options

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:

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


Advanced Clustering – Guaranteed Message Order

 

Our Advanced Clustering extension is great for horizontally scaling your 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.

User Authorization – Channel Tags / Groups

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.

Other Features / Enhancements

  • 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.
  • No labels