anchor.diff:  
   Chronicle works best in SEDA style event driven systems, where latency is critical and you need a record of exactly what was performed when. (Without expensive network sniffing/recording systems)
   
  -=== What is the performance like?
  -
  -While Vanilla and Index Chronicle support sub-microsecond latencies. If you use Wire, the typical latencies tend to be around one micro-second.  You can still use raw writing of bytes if you need maximum performance.
  -
   === How does Chronicle Queue use memory? 
   
   Chronicle Queue is designed to use virtual memory which can be much larger than main memory (or the heap) without a significant impact on your system. This allows you to access the data at random quickly.
  
positive.code: 
  === I want to store large messages, what is the limit.
  
  The limit is about 1 GB as Chronicle 4.x.
  The practical limit without tuning the configuration is about 16 MB.
  At this point you get significant inefficiencies unless you increase the data allocation chunk size.
  
  
negative.code: 
  Chronicle Queue v4.x doesn't at the moment.  The best approach is to wait for a replicated message to be acknowledged.
  
  === Can CQ compete with Spark in this domain ?
  
  To my knowledge, Spark Streaming is designed for real time but is looking to support a much lower message rate and doesn't attempt to be ultra low GC.
  e.g. minor GC less than once a day.  I haven't heard of any one using Spark in the core of a Trading system. It tends to be used for downstream monitoring and reporting.
  
  === It seems that you have some clients that use CQ for Big Data style problems.
  
  