LTS Changelog

The LTS changelog lists releases which are only accessible via a commercial subscription. All fixes and changes in LTS releases will be released the next minor release. Changes from LTS 1.4.x will be included in release 1.5.0.

1.6.4 (27.10.2020)

OrientDB: The included OrientDB version has been updated to version 3.1.4.

Clustering: The coordination feature will now be automatically disabled whenever clustering is disabled.

Core: The link renderer now tries to use url fields to render the link if it cannot be constructed using segment fields.

1.6.3 (21.10.2020)

OrientDB: The included OrientDB version has been updated to version 3.1.3.

Clustering: Internal caches will now be cleared when cluster topology changes occur.

Backup: The ?consistencyCheck query parameter was added to the /api/v2/admin/backup endpoint. When set to true it will run the consistency check before invoking the backup. The call will fail when inconsistencies were detected.

Clustering: An additional check has been added which will prevent nodes from joining a cluster which contains an outdated database. The -initCluster flag needs to be used for a single instance to migrate the cluster. This is done to prevent concurrency issues during changelog execution and cluster formation.

Tests: The path handling for the MeshContainer test container class has been updated. Container data will now be placed in the target/mesh-containers folder.

1.6.2 (06.10.2020)

Additional log output and checks have been added to the auth plugin mapping code. This fix also addresses the Null keys are not supported error which was thrown when handling mappings which provide no group and role names. #1138

OrientDB: The included OrientDB version has been updated to version 3.0.34.

Rest: The webroot cache error handling has been improved.

1.6.1 (24.09.2020)

Search: The memory footprint of the differential sync mechanism has been reduced. The sync operations will now be split into buckets. The size of the buckets can be influenced via the search.syncBatchSize setting.

The new sync mechanism requires a reindex of all documents. The Elasticsearch indices will be automatically cleared and re-synced during the first startup of this version.

Core: Fixed a bug that which prevented to update a node reference of a user if the user already had one set. #1114

Core: It is now possible to disable extracting of metadata or content from binaries on a per-field basis. See schema field types documentation for more information.

Plugins: The default plugin timeout has been increased from 15 seconds to two minutes.

Monitoring: The readiness probe will now also check for plugin status. Failed plugin deployments will let the readiness probe fail.

Monitoring: The readiness probe will now no longer fail when a plugin is not registered. Instead it will only fail when a plugin deployment has failed.

Monitoring: The liveness probe will now check for plugin status. Failed plugin deployments will let the liveness probe fail.

Clustering: The webroot handler no longer uses the cluster-wide write lock.

Logging: Failing readiness checks are now logged using the WARN level.

1.5.6 (22.10.2020)

OrientDB: The included OrientDB version has been updated to version 3.1.4.

Clustering: The coordination feature will now be automatically disabled whenever clustering is disabled.

Clustering: Internal caches will now be cleared when cluster topology changes occur.

Backup: The ?consistencyCheck query parameter was added to the /api/v2/admin/backup endpoint. When set to true it will run the consistency check before invoking the backup. The call will fail when inconsistencies were detected.

Clustering: An additional check has been added which will prevent nodes from joining a cluster which contains an outdated database. The -initCluster flag needs to be used for a single instance to migrate the cluster. This is done to prevent concurrency issues during changelog execution and cluster formation.

1.5.5 (06.10.2020)

OrientDB: The included OrientDB version has been updated to version 3.0.34.

Rest: The webroot cache error handling has been improved.

1.5.4 (24.09.2020)

Core: It is now possible to disable extracting of metadata or content from binaries on a per-field basis. See schema field types documentation for more information.

Monitoring: The readiness probe will now no longer fail when a plugin is not registered. Instead it will only fail when a plugin deployment has failed.

Monitoring: The liveness probe will now check for plugin status. Failed plugin deployments will let the liveness probe fail.

Clustering: The webroot handler no longer uses the cluster-wide write lock.

Logging: Failing readiness checks are now logged using the WARN level.

1.4.17 (27.10.2020)

OrientDB: The included OrientDB version has been updated to version 3.1.4.

Clustering: The coordination feature will now be automatically disabled whenever clustering is disabled.

Clustering: Internal caches will now be cleared when cluster topology changes occur.

Backup: The ?consistencyCheck query parameter was added to the /api/v2/admin/backup endpoint. When set to true it will run the consistency check before invoking the backup. The call will fail when inconsistencies were detected.

Clustering: An additional check has been added which will prevent nodes from joining a cluster which contains an outdated database. The -initCluster flag needs to be used for a single instance to migrate the cluster. This is done to prevent concurrency issues during changelog execution and cluster formation.

1.4.16 (06.10.2020)

OrientDB: The included OrientDB version has been updated to version 3.0.34.

Rest: The webroot cache error handling has been improved.

1.4.15 (23.09.2020)

Monitoring: The readiness probe will now no longer fail when a plugin is not registered. Instead it will only fail when a plugin deployment has failed.

Monitoring: The liveness probe will now check for plugin status. Failed plugin deployments will let the liveness probe fail.

Clustering: The webroot handler no longer uses the cluster-wide write lock.

Logging: Failing readiness checks are now logged using the WARN level.

1.4.14 (02.09.2020)

Core: Fixed a bug that which prevented to update a node reference of a user if the user already had one set. #1114

1.4.13 (26.08.2020)

Plugins: The default plugin timeout has been increased from 15 seconds to two minutes.

Monitoring: The readiness probe will now also check for plugin status. Failed plugin deployments will let the readiness probe fail.

1.4.12 (17.07.2020)

Clustering: The cluster coordinator will now detect changes caused by the OAuth token mapping and will redirect the request if necessary. Thus this change allows the use of the CUD mode when using request coordination in combination with authentication plugins.

Clustering: When using the cluster coordinator, forwarded requests will now contain the X-Mesh-Forwarded-From header.

1.4.11 (23.06.2020)

Plugins: A potential resource leak could cause thread exhaustion when using new REST Clients for each request. This has been fixed now.

1.4.10 (12.05.2020)

Plugins: Fixed an error which was triggered when trying to un-deploy a not yet deployed plugin.

Plugins: Fixed a bug in the plugin registration process in which plugin deployments would fail due to timeouts in clustered environments.

1.4.9 (07.05.2020)

Plugins: The plugin registration process was changed. Plugins will now no longer be directly registered when deployed. Instead the plugins will remain in a pre-registration status util Gentics Mesh is able to deploy them. This is especially useful when running plugins in clustered mode. Plugins will only be registered once the write quorum has been reached. Additionally the plugin deployment process will now utilize a lock in clustered mode to prevent concurrent deployments of plugins. The plugin status was added to the plugin endpoint response.

Clustering: The write lock was removed from the DELETE /api/v2/admin/plugins/:id and POST /api/v2/admin/plugins endpoints to prevent potential deadlocks.

1.3.4 (11.05.2020)

Microschema migrations since version 1.2.0 are very likely to cause a loss of data in nodes that contain micronodes of the migrated schema. This bug has been fixed in this version. At the first start with this version or higher, Gentics Mesh will try to restore affected nodes in projects with a single branch. However, because some data cannot be restored, we advise to restore a backup of a moment before the microschema migration, if possible. We apologize for the inconvenience.