anchor.diff:  
   While this does not cause a technical problem, we are aware this does concern people who can find this out-of-the-ordinary. We plan to have a mode which reduces virtual memory use; even if it is a little slower for some use cases.
   
  -=== What was the library originally designed for?
  +== What was the library originally designed for?
   
   The original design was for a low-latency trading system which required persistence of everything in, and out, for a complete record of
   what happened, when, and for deterministic testing. The target round-trip time for persisting the request, processing, and persisting the response, was `1` micro-second.
  
positive.code: 
  Where `XML` is needed downstream, we suggest writing in binary format, and have the reader incur the overhead of the conversion, rather than slow down the producer.
  
  === Does Chronicle support a synchronous mode?
  
  Chronicle Queue v4.x does not currently support a synchronous mode.  The best approach is to wait for a replicated message to be acknowledged.
  
  === Can Chronicle Queue compete with Spark in this domain?
  
  To our knowledge, Spark Streaming is designed for real-time, but is looking to support a much lower message rate, and does not attempt to be ultra-low GC (minor GC less than once a day).  We have not 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 Chronicle Queue for Big Data style problems.
  
  Our largest Chronicle Queue client pulls in up to `100` TB into a single JVM using an earlier version of Chronicle Queue.
  
  === Could you please us more about the way they use Chronicle Queue?
  
  Chronicle Queue is compelling as it uses a no-flow control model.
  Chronicle Queue is designed to not slow down the producer if you have a slow consumer. Instead, you need to give it plenty of disk space as a buffer.  Disk space is cheaper than main memory, and is cheaper than heap space. You can buy a system with multiple `16` TB SSD drives today. No one would consider having a JVM heap with `100` TB.
  
negative.code:     ExcerptAppender appender = queue.acquireAppender(); // sequential writes.
      ExcerptTailer tailer = queue.createTailer();       // sequential reads ideally, but random reads/write also possible.
  
  == How does writing work?
  
  You can write using a try-with-resource block:
  
  