Customer Knowledge Base
Customer Knowledge Base
Breadcrumbs

Running Multiple HCMS Output Channels in a Single Satellite

1. Overview

This KB explains how to operate more than one HCMS output channel in the same satellite container by using separate HCMS configurations. It covers the required configuration assets, typical issues, and recommended diagnostic steps.

2. Symptoms

  • Satellite fails to start when adding a second HCMS configuration

  • Errors indicating that a datastore directory is already in use or locked

  • Second HCMS endpoint does not respond or resolves to the original configuration

  • Synchronization not starting or taking unusually long after configuration changes

3. Common Causes

  • Both HCMS configurations pointing to the same datastore instance

  • Shared filesystem paths in the datastore configuration

  • Missing changes to instance identifiers in cloned XML assets

  • Host mappings or output channels not updated to unique values

  • Schema registry conflicts due to reused resource keys

4. Diagnostics

4.1 Customer/Partner

  • Verify that the DataStore.xml and HeadlessCms.xml assets were cloned and not overwritten.

  • Check that each cloned asset uses a unique instanceid.

  • Confirm that each HCMS configuration uses a unique output channel.

  • Verify that the datastore work-filesystem-url values do not point to the same directory.

  • Confirm that the hostmapping name is unique and resolves to a different URL path or port.

  • Check whether both datastores are intended to hold distinct data. If they overlap, evaluate whether a second datastore is actually required.

4.2 Infra/DevOps

  • Ensure the satellite container has isolated and persistent volume mappings for each datastore, if applicable.

  • Validate that the filesystem directory used by the datastore is not shared unless explicitly intended.

  • Check volume permissions to ensure the satellite can rebuild or reinitialize a datastore directory if needed

4.3 censhare Support

  • Confirm that schema registry resource keys are unique where required.

  • Validate that the correct datastore instance name is referenced in each HeadlessCms.xml.

  • Review configuration structure to ensure that no conflicting definitions exist in WebServer.xml or related assets.

5. Mitigation

  • Clone DataStore.xml and HeadlessCms.xml for each additional HCMS instance.

  • Assign a unique instanceid in each cloned configuration.

  • Update output channels to distinct values.

  • Update hostmapping names to separate URL prefixes or ports.

  • Ensure each datastore uses a separate filesystem directory or create an isolated datastore definition.

  • If datastore corruption is suspected, remove or reset the affected directory to force a full rebuild.

  • Remove the additional datastore configuration entirely if the intention is to serve the same content with only different HCMS settings.

6. Best Practices

  • Use separate containers for each HCMS configuration when possible for easier administration.

  • Avoid reusing schema registry keys unless intentional and validated.

  • Maintain clear naming conventions for instanceid, host mappings, and output channels.

7. When to Contact Support

  • The satellite does not start even after correcting instance identifiers and datastore paths.

  • Schema conflicts persist after configuration isolation.

  • HCMS endpoints remain unreachable after updating hostmapping and output channel values.

  • Suspected datastore corruption persists across resets. 

8. Information Required

  • The cloned DataStore.xml and HeadlessCms.xml configurations (sanitized)

  • Satellite configuration files relevant to datastore and web server setup

  • The exact error message observed during startup

  • Steps taken so far, including any datastore directory changes