anchor.diff:  
       readerThread.join();
   }
  -```+```
  +
  +'''
  +
  +<<../README.adoc#,Back to Chronicle Queue>>
  
positive.code: 
  == Chronicle Queue Enterprise Replication
  
  Chronicle Queue Enterprise replication performs simple unidirectional multi-way replication by copying a chronicle queue
  from one host to one or more others via TCP/IP.
  
  .Chronicle Queue Replication
  image::images/queue-replication.png[]
  
  NOTE: for Chronicle-Engine based replication, see link:engine-replication.adoc[here]
  
  === The mechanics of Chronicle Queue Replication
  
  The queue that we write to we refer to as the source queue and the copy(-ies) we refer to as the sink queue.
  
  IMPORTANT: Chronicle requires exclusive write access to the Sink. Sink should be treated as read-only, and never manually written to.
  
  If we allowed messages to be written to the sink, its not hard to imagine a case where different messages are written to a source
  and sink at the same time, the messages on the source queue and sink queue could now be in a very different order,
  as such we don’t allow messages to be written to the sync queue. Or putting it another way Queues must maintain message
  ordering and the source queue and sink queue are identical. One of the reasons we enforce this is that in a microservices
  architecture, in order that you can get true replay-ability you should be able to guarantee the consistency and ordering of
  the messages in the queues, hence any service that's running on the source machine must receive the same events,
  and in the same order, as the service running on the sink machine.
  
  So in summary, any message written to source is copied to sink. The sink therefore becomes a mirror image of the source.
  
  At startup, replication locks Source queue and waits for Sink(s) to report the number of records it has, and if Sink has
  more records, they are replayed back to Source before it is unlocked and usable again. This is done to provide
  automatic data re-sync after failover to Sink.
  
  The set of hosts onto which the queue is replicated is defined as a cluster. The config for that looks as follows:
  
  ```
  !QueueReplicationCfg {
  
negative.code: }
  ```
  
  In the configuration shown above, the queue, `queue1`, is set to be replicated from `host1` (as indicated by `masterId`) to all other hosts defined for the cluster, `cluster1`.
  
  Queues will use storage paths defined by `baseSourcePath` and `baseSinkPath` for `source` and `sink`, respectively, followed by the queue name. For this example, the `source` queue will be at `replica/source/queue1`, while the `sink` will be written to `replica/sink/queue1`.
  
  === Using Enterprise Queue Replication
  
  To start replicating data, the user must create an instance of `ReplicatedQueue` for each host. This is done as follows:
  
  ```
  ReplicatedQueue repl = new ReplicatedQueue(config());
  