Chapter 5. Running and Managing DX Content Router
5.1. Starting DX Content Router Services
DX Content Router Publisher and Replicator will attempt to start every time the server on which they
are installed boots. Admins should be sure to update the config files for Publisher and/or Replicator
after installation to ensure DX Content Router has the necessary information to start correctly. If
a service was stopped for any reason it can be manually started with a standard init.d script. For
mirrored configurations with both services on the same server, Publisher and Replicator must be
started separately as follows:
$ sudo /etc/init.d/cr-publisher start
$ sudo /etc/init.d/cr-replicator start
5.2. Publisher and Replicator Shutdown
To stop a DX Content Router service, use one of the following commands:
$ sudo /etc/init.d/cr-publisher stop
$ sudo /etc/init.d/cr-replicator stop
5.3. Customizing the Standard Rule Sets
The standard rule set can easily be customized to control what content is published on a given
channel. Each Publish statement, or channel', will be evaluated against the full list of known UUIDs.
Multiple replicators may subscribe to the same channel when replicating the same content to more
than one remote cluster. Channel names are case sensitive. Modifications to rules files, both real-
time and while Publisher is stopped, will delete all subscriber sessions as the list of previously
filtered events is no longer guaranteed to be accurate for the new rules. Subscriber clients that
receive a 404 on a request must restart their subscriber session(s).
The default channel in the sample rules file is a 'PublishAll' rule with no filter criteria that cannot be
modified. This channel name is reserved and the filter criteria associated with it cannot be modified
as the PublishAll case is optimized to speed performance by skipping the rule filtering process.
'PublishAll' is equivalent to the previous default of 'ReplicateAll'; customers using a 'ReplicateAll'
rule need not update their rule name to gain the same functionality. Legacy 'ReplicateAll' rules will
display on the Publisher console as 'PublishAll' (irrespective of the name displayed in the rules.xml
file) and will behave in all other ways as the 'PublishAll' rule. If there are any filter criteria associated
with either the 'PublishAll' or 'ReplicateAll' rule, Publisher will log an error and fail to start.
The examples below illustrate multiple alternate rule implementations.
Note
Delete events are considered to match all channels. They are sent to all subscribers. For
a Replicator subscriber, there is a configuration parameter, "ignoreDeleteEvents", which
tells Replicator to not propagate any deletes to the target cluster. Unless this parameter
is set, all object deletes are propagated independent of which channels streams matched
when they were written. This ensures content replicated to a remote cluster via a previous
rule version is still deleted. If a stream was never replicated to the target cluster, there will
be nothing to delete.
5.3.1. Publish all streams on a single channel
This is the same as the default "PublishAll" case.
Copyright © 2010 Caringo, Inc.
All rights reserved
15
Version 2.2
December 2010
Sayfayı Yazdır