Copyright © 2010 Caringo, Inc.All rights reserved 15Version 2.2December 2010Chapter 5. Running and Managing DX Content Router5.1. Starting DX Content Router ServicesDX Content Router Publisher and Replicator will attempt to start every time the server on which theyare installed boots. Admins should be sure to update the config files for Publisher and/or Replicatorafter installation to ensure DX Content Router has the necessary information to start correctly. Ifa service was stopped for any reason it can be manually started with a standard init.d script. Formirrored configurations with both services on the same server, Publisher and Replicator must bestarted separately as follows:$ sudo /etc/init.d/cr-publisher start$ sudo /etc/init.d/cr-replicator start5.2. Publisher and Replicator ShutdownTo 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 stop5.3. Customizing the Standard Rule SetsThe standard rule set can easily be customized to control what content is published on a givenchannel. 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 morethan 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 previouslyfiltered events is no longer guaranteed to be accurate for the new rules. Subscriber clients thatreceive 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 bemodified. This channel name is reserved and the filter criteria associated with it cannot be modifiedas 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 willdisplay on the Publisher console as 'PublishAll' (irrespective of the name displayed in the rules.xmlfile) and will behave in all other ways as the 'PublishAll' rule. If there are any filter criteria associatedwith either the 'PublishAll' or 'ReplicateAll' rule, Publisher will log an error and fail to start.The examples below illustrate multiple alternate rule implementations.NoteDelete events are considered to match all channels. They are sent to all subscribers. Fora Replicator subscriber, there is a configuration parameter, "ignoreDeleteEvents", whichtells Replicator to not propagate any deletes to the target cluster. Unless this parameteris set, all object deletes are propagated independent of which channels streams matchedwhen they were written. This ensures content replicated to a remote cluster via a previousrule version is still deleted. If a stream was never replicated to the target cluster, there willbe nothing to delete.5.3.1. Publish all streams on a single channelThis is the same as the default "PublishAll" case.