anchor.diff:  
   Chronicle Queue attempts to handle more volume from a single thread, to a single partition and thus avoid the need for the complexity and downsides of having partitions.  Note: Chronicle Engine supports partitioning of queues across machines, though not the partitioning of a queue.
   
  -Unlike Karfka which uses a broker which uses the operating system's file system and cache.  Chronicle Queue relies entirely on the file system and cache.
  +Unlike Kafka which uses a broker which uses the operating system's file system and cache.  Chronicle Queue relies entirely on the file system and cache.
   
   === Similar product guides
   
  
positive.code: 
  === Efficiency
  
  We put significant effort into worring about latency you can't see.  Unlike products which focus on support of the web, we care about latency which are a fraction of the time you can see. For web application less than 40 ms is fine for web applications as it's faster than you can see (the frame rate of cinema is 24 Hz or about 40 ms)  However we attempt to be under 40 microsecond 99% to 99.99% of the time.  Using queue without replication we support applications with latencies below 40 microseconds end to end across multiple services.  Often the 99% latency of queue is entirely dependant on the chose of OS and disk subsystem.
  
  === Compression
  
  
negative.code: 
  - without self describing messages, users had to create their own functionality for dumping messages and long term storage of data.  With Q4 you dont have to do this but is you wish you can still do so.
  - Vanilla Chronicle Queue would create a file per thread. This is fine if the number of threads is controlled however many applications have little or no control over how many threads are used and this caused usability problems.
  - The configuration for Indexed and Vanilla Chronicle was entirely in code so the reader had to have the same configuration as the writers and it wasn't always clear what that was.
  - There was no way for the producer to know how much data had been replicated to the consumer. The only work around was to replicate data back to the producers.
  - You needed to specify the size of data to reserve, before you started to write your message.
  - You needed to do your own locking for the appender when using Indexed Chronicle.
  