CoreMedia Content Cloud v11 Upgrade Guide / Version 2110
Table Of ContentsThe Solr index schema for Content Feeder and CAE Feeder, and the configuration of the Content Feeder was changed to enable the search filter for validation issues by default, and to also support Solr nested documents in the CAE Feeder. See also the updated section Section 4.1.3, “Content Issues” in Search Manual.
Solr Configuration Changes
The Solr index fields _root_ and _nest_path_ were added in the index schema
for both Content Feeder and CAE Feeder indexes in content/conf/schema.xml and
cae/conf/schema.xml. These files are located in the Blueprint below
apps/solr/modules/search/solr-config/src/main/app/configsets.
The fields were optional since version 2104 but not defined by default. Adding them requires recreation of indexes from scratch. If you create new indexes with this version, or if you have already created new indexes with previous versions and these fields defined, then you should add/keep the fields in the schema. For the Content Feeder index, these fields are required if indexing of validation issues is enabled. It's important that you don't change the definition of these fields, if you keep an existing index.
Several deprecated configuration properties have been removed for the Content Feeder, the CAE Feeder, and for applications that connect to Solr for searching.
If you still use any of these properties, you have to replace them with the property that is listed right next to it in the following list (sorted alphabetically):
feeder.backgroundFeed.delay→feeder.content.background-feed-delayfeeder.executorQueueCapacity→feeder.core.executor-queue-capacityfeeder.executorRetryDelay→feeder.core.executor-retry-delayfeeder.indexDeleted→feeder.content.index-deletedfeeder.indexGroups→feeder.content.index-groupsfeeder.indexNameInTextBody→feeder.content.index-name-in-textbodyfeeder.indexReferrers→feeder.content.index-referrersfeeder.management.password→feeder.content.management.passwordfeeder.management.user→feeder.content.management.userfeeder.maxBatchBytes→feeder.batch.max-bytesfeeder.maxBatchByteSize→feeder.batch.max-bytesfeeder.maxBatchSize→feeder.batch.max-sizefeeder.maxOpenBatches→feeder.batch.max-openfeeder.maxProcessedBatches→feeder.batch.max-processedfeeder.partialUpdate.aspects→feeder.content.partial-update-aspectsfeeder.retryConnectToIndexDelay.seconds→feeder.content.retry-connect-to-index-delayfeeder.retrySendIdleDelay→feeder.batch.retry-send-idle-delay(see note below)feeder.retrySendMaxDelay→feeder.batch.retry-send-max-delay(see note below)feeder.sendIdleDelay→feeder.batch.send-idle-delay(see note below)feeder.sendMaxDelay→feeder.batch.send-max-delay(see note below)feeder.tika.timeout.milliseconds→feeder.tika.timeoutfeeder.tika.warn.milliseconds→feeder.tika.warn-time-thresholdfeeder.updateGroups.background.delay→feeder.content.background-feed-delayfeeder.updateGroups.immediately→feeder.content.update-groups-immediatelysolr.collection.cae→solr.cae.collectionsolr.collection.content→solr.content.collectionsolr.configSet→solr.cae.config-set(for the CAE Feeder),solr.content.config-set(for the Content Feeder)solr.partialUpdates→feeder.solr.partial-updates.enabledsolr.partialUpdatesSkipIndexCheck→feeder.solr.partial-updates.skip-index-check
Note, that the old properties feeder.sendIdleDelay, feeder.sendMaxDelay,
feeder.retrySendIdleDelay, and feeder.retrySendMaxDelay took a value in seconds
for the _Content Feeder_, but a value in milliseconds for the _CAE Feeder_. The new properties
feeder.batch.send-idle-delay, feeder.batch.send-max-delay,
feeder.batch.retry-send-idle-delay, and feeder.batch.retry-send-max-delay take
milliseconds for both Content Feeder and CAE Feeder (if the value does not specify a different Spring Boot duration
unit like 's').
Solr Terminology Changes
Apache Solr has replaced the names of their replication setup from Master/Slave to Leader/Follower. These names
have now been changed in Solr configuration files solrconfig.xml and CoreMedia documentation.
For details of the change in Solr, see
Solr Upgrade Notes.
The following system properties used to configure Solr replication have been renamed. If you are using the old names in your project, you must update them accordingly:
solr.master.url→solr.leader.urlsolr.master→solr.leadersolr.slave→solr.follower
Environment variables for the Docker image have also changed. The old environment variables still work, but are deprecated:
SOLR_MASTER→SOLR_LEADERSOLR_MASTER_URL→SOLR_LEADER_URLSOLR_SLAVE→SOLR_FOLLOWERSOLR_SLAVE_AUTOCREATE_CORES→SOLR_FOLLOWER_AUTOCREATE_CORESSOLR_SLAVE_AUTOCREATE_CORES_LIST→SOLR_FOLLOWER_AUTOCREATE_CORES_LISTSOLR_SLAVE_AUTOCREATE_THRESHOLD→SOLR_FOLLOWER_AUTOCREATE_THRESHOLD
The Maven commands to start and stop a Solr follower node for local development in
apps/solr/modules/search/solr-config/pom.xml have also changed to use "follower" instead
of "slave". For details, see the comments in that pom.xml file.
In addition to the system properties and environment variables, the following changes have been applied:
The default log-location for Solr followers changed:
slave-logs/→follower-logs/To start a Solr follower locally, you now need to call
mvn exec:exec@start-solr-follower(instead ofmvn exec:exec@start-solr-slave).
Content Feeder Configuration for Issue Feeding
The configuration of the Content Feeder was changed to index issues, by default. You can disable issue indexing
with configuration property feeder.content.issues.index=false, for example if you have decided
to not add the fields to the Solr schema to avoid reindexing, or if you are not using the default Solr integration
but a custom Indexer that does not support indexing issues as nested documents.
Recreate Index from Scratch for Improved CAE Feeder Database Usage
The CAE Feeder was improved to store data more efficiently in the database, which reduces database disk space requirements and improves throughput. To this end, the data type of some database columns was changed from a string type to a binary type. This change also applies to custom applications based on the Proactive Engine.
When the CAE Feeder is started with an empty database to feed everything from scratch, it will automatically create tables with improved definitions. If started with existing database tables from a previous release, then the CAE Feeder will work as before without improved database usage. Existing database tables are not upgraded. For best performance, it is recommended to start feeding with an empty database.
