anchor.diff:   - whether this message is user data or meta-data required to support the queue itself and
    - a bit to flag whether the message is complete or not.
   
  - When the message is not complete, it cannot be read.  However, if the length is known, a writer can skip such messages, attempt to write after it.
  - Say Thread1 is in the middle of writing a message, but it know how long it will be, it can write 4 bytes which indicate the length.
  - Thread2 can see that there will be a message and skip over it looking for a place to write.  This way multiple threads can be writing to the queue concurrently.
  - Any message which is detected as bad e.g. the thread died, can be marked as meta data and skipped by the reader.
  -
  - There is a special value which is a "poison pill" value, which indicates the file has been rolled.
  - This ensures all writers and readers roll at the same point in a timely manner.
  +When the message is not complete, it cannot be read.  However, if the length is known, a writer can skip such messages, attempt to write after it.
  +Say Thread1 is in the middle of writing a message, but it know how long it will be, it can write 4 bytes which indicate the length.
  +Thread2 can see that there will be a message and skip over it looking for a place to write.  This way multiple threads can be writing to the queue concurrently.
  +Any message which is detected as bad e.g. the thread died, can be marked as meta data and skipped by the reader.
  +
  +There is a special value which is a "poison pill" value, which indicates the file has been rolled.
  +This ensures all writers and readers roll at the same point in a timely manner.
   
   In the example above you can see the header
   
  
positive.code: For us a key feature of CQ is not just how the data structure is arranged,
  but also how transparently this binary data structure can be inspected.
  
  If we look at the last message, you can see the message type, the type of the payload and the value of all the fields.
  
  [source, java]
  
negative.code: === What makes Chronicle Queue different from similar solutions
  
  ==== Speed
  
  CQ is designed to support hundred of thousands of messages per second comfortably.
  It can also handle multi-second bursts into the millions of messages per second.
  One of our clients reported they are handling bursts of 24 million messages per second with a cluster of 6 servers.
  
  ==== Without Flow Control
  
  CQ is an unbounded queue without flow control between the producer and the consumer.
  Replication supports flow control but this is not used by default.
  A lack of flow control is what we call a "producer centric" solution.
  
  ==== Consumer Centric solution
  
  To put that in context, most messaging solutions have flow control.  They are what we call a "consumer centric" solution.
  Consumer centric solutions make sense in many application esp between servers and client GUIs.
  Any data you send to a client GUI is for display to a human.
  