anchor.diff:  
   |=======
   |`Excerpt`| In Chronicle we refer to messages as excerpts.
  -|`PRIMARY`   | The master of the messages aka `source`; messages are replicated from the PRIMARY to the SECONDARY.
  -|`SECONDARY`    | The receiver of the messages aka `sink`; holds an real-time up-to-date copy of the PRIMARY's data.
  +|`PRIMARY`   | The master of the messages; this is also known as `source`. Messages are replicated from the PRIMARY to the SECONDARY.
  +|`SECONDARY`    | The receiver of the messages; this is also known as `sink`. Holds a real-time, up-to-date copy of the PRIMARY's data.
   |=======
   
   '''
  
positive.code:   }
  ----
  
  It is important that this `hostId` is unique as it is used by Chronicle Engine clustering. For Queue replication, by default, the host with `hostID` of `1` is assumed to be the PRIMARY, and the other hostids are assumed to be the SECONDARYs.
  
  == Creating an instance of the `ChronicleQueueView`
  
  
negative.code: 
  The code above:
  
  - sets up Chronicle Queue on port `localhost:8080`.
  - uses the specified configuration file. This configuration file should be stored at `config/etc/clusters.yaml`.
  - configures an asset on the Chronicle Engine asset tree at `/the/uri` with a `leafRule`. This `leafRule` is setup to provide a `ChronicleQueueView` when asked for a `ChronicleQueue`. The `ChronicleQueueView` is an implementation of the `ChronicleQueue` interface.
  
  Assuming that both the `host1` and `host2` instances of Chronicle Engine were run with the same java code above, then messages added to the Chronicle queue on `host1` would be replicated to `host2`.
  
  The interface of `ChronicleQueueView`, is as follows:
  
  [source, java]
  ----
  