As of 3.7 commercial extensions now require a license key to be set in mirth.properties. The machine running Mirth Connect also must have outbound internet access so that our licensing server can be reached. Before upgrading, contact the help desk through our Success Community to get your license key.

When installing the 3.7.0 update, a wizard will prompt you to enter the license key:

• Edit conf/mirth.properties
• Add a setting with key "license.key" and your license key for the value

• Restart the Mirth Connect service

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

The default keystore storepass and keypass is 81uWxplDtB. However when Mirth Connect starts up for the first time and the keystore file hasn't yet been created, Mirth Connect will automatically replace the default passwords with new auto-generated passwords.

If you are upgrading from a previous version nothing will change, your keystore and passwords will remain the same. This is only done for completely new servers where the keystore hasn't yet been created and the passwords are still set to the default values.