close

Filter

loading table of contents...

Release Notes / Version 12.2406.0

Table Of Contents

CoreMedia Core

Third-Party Update: Apache James Mime4J

Apache James Mime4J has been updated to version 0.8.10.

(CMS-24288)

Fixed a Bug Where A Publication Workflow With Content Errors Could Be Started

We fixed a timing issue where the start-workflow window would not show content errors and consequently, a publication workflow could be started.

(CMS-24229)

Postgresql driver has been updated

The postgresql driver org.postgresql:postgresql has been updated to 42.6.1.

(CMS-24216)

Third-Party Update: Apache Commons Compress

Third-party library Apache Commons Compress has been updated to 1.26.0 to fix known security vulnerabilities.

(CMS-24210)

Content Server DB Transaction Retry

The Content Server can now be configured to perform retries on database transactions in case of connection loss or read-only databases (MySQL only). These situations may arise in the context of database failovers in setups like, e.g., Amazon Aurora.

To configure the Content Server for retries, use these properties:

  • sql.pool.retry-on-connection-loss: enable retries on database connection loss when set to value true (default: false).

  • sql.pool.retry-on-read-only-db: enable retries on read-only database when set to value true (default: false).

  • sql.pool.retry-delay: wait given time before retrying (Duration; default: 15 seconds).

  • sql.pool.max-retries: maximum number of retries (default: 15).

Make sure to set DNS caching on your system to a very short time (probably shorter than sql.pool.retry-delay) to allow for refreshed hostname resolution before the next attempt on a previously failing database is started. This can be necessary to successfully contact the current primary database instance in a database failover setup.

The number of retries on a single database transaction and the delay are configurable. Set the maximum retries and delay values (see above) large enough to cover prolonged database unavailability during failover.

(CMS-24076)

Improved Performance Of Deriving Sites

Performance of Deriving Sites via Studio or API (com.coremedia.cap.multisite.SitesService#deriveSite(...)) has been improved.

(CMS-24075)

Improved Logging for Workflow Errors

The Workflow Server logs more details for errors from certain workflow actions. Previously, some important details were only visible with enabled DEBUG logging.

(CMS-24058)

Method Content#copyTo(...) fixed

Method Content#copyTo(...) showed an error with documents whose blob properties had data. This has now been fixed.

(CMS-24051)

Fixed CAE Feeder Partial Re-Indexing by Actuator or JMX

Fixed a bug in the CAE Feeder that not all content items were re-indexed after a request for partial re-indexing via Spring Boot actuator or JMX.

(CMS-23587)

Extended Workflow Server DB Transaction Retry

The Workflow Server can now be configured to perform retries on database transactions in case of connection loss or read-only databases (MySQL only). These situations may arise in the context of database failovers in setups like, e.g., Amazon Aurora.

To configure the Workflow Server for retries on connection loss, use these properties:

  • workflow.server.tx.retry-on-connection-loss: enable retries on database connection loss when set to value true (default: false).

  • workflow.server.tx.retry-on-connection-loss-delay: wait given time before retrying on database connection loss (Duration; default: 15 seconds).

To configure the Workflow Server for retries on a read-only database, use these properties. This is currently only supported on MySQL:

  • workflow.server.tx.retry-on-read-only-db: enable retries on read-only database when set to value true (default: false).

  • workflow.server.tx.retry-on-read-only-db-delay: wait given time before retrying on read-only database (Duration; default: 5 seconds).

Make sure to set DNS caching on your system to a very short time (probably shorter than workflow.server.tx.retry-on-read-only-db-delay) to allow for refreshed hostname resolution before the next attempt on a previously read-only database is started. This can be necessary to successfully contact the current primary database instance in a database failover setup.

Retries on a single database transaction are limited to 15 times - regardless of which concrete issue arises on each retry. Set the delay values (see above) large enough to cover prolonged database unavailability during failover.

(CMS-23428)

Search Results

Table Of Contents
warning

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.