anchor.diff:  :toc: macro
   
   image:https://maven-badges.herokuapp.com/maven-central/net.openhft/chronicle-queue/badge.svg[caption="", link=https://maven-badges.herokuapp.com/maven-central/net.openhft/chronicle-queue]
  +image:https://img.shields.io/github/license/OpenHFT/Chronicle-Queue[GitHub]
   image:https://img.shields.io/gitter/room/OpenHFT/Lobby.svg?style=popout[link="https://gitter.im/OpenHFT/Lobby"]
   
   image::images/Queue_line.png[]
   == Contents
   
   toc::[]
  -
  -== The Changes from Chronicle Queue version 4 to version 5
  -
  -In Chronicle Queue 5 tailers are now read-only, in Chronicle Queue 4 we have the concept of lazy indexing, where the appenders would not write indexes but instead the indexing was done by the tailer, or to be more precise,  when lazy indexing was turned on the indexing was done by the first tailer that read the data. Since in chronicle queue 4 tailers could do the indexing we could not rely on them to be read-only. We decided to drop lazy indexing in chronicle queue 5. Making tailers read-only not only simplifies Chronicle Queue but also allows us to add optimisations elsewhere in the code.
  -
  -The locking model of Chronicle Queue was changed, in Chronicle Queue 4 a write lock ( to prevent concurrent writes to the queue ) exists in the .cq4 file, In Chronicle Queue 5 this was moved to a single file called a table store (queuelock.cq4t). This simplifies the locking code internally as only the table store file has to be inspected.
  -
  -You can use Chronicle 5 to read messages written with Chronicle 4, however you should not concurrently run chronicle queue 4 and chronicle queue 5 at the same time. In other words avoid running Chronicle Queue 4’s appenders and tailers on a queue which at the same time is also be read and written to via Chronicle Queue 5.
   
   == About Chronicle Software
   
  
positive.code: we will often add a `net.openhft.chronicle.core.Jvm.safepoint` into the code because thread dumps are only reported at safe-points.
  
  
  ===== Summary
  
  In the test described above, the typical latency varied between 14 and 40 microseconds. The 99 percentile varied between 17 and 56 microseconds depending on the throughput being tested. Notably, the 99.93% latency varied between 21 microseconds and 41 milliseconds, a factor of 2000.
  
  
negative.code: Snapshots are available on https://oss.sonatype.org
  
  https://github.com/OpenHFT/Chronicle-Queue/releases[Chronicle Queue Release Notes]
  
  == Simple Step-By-Step Guide
  see https://github.com/OpenHFT/Chronicle-Queue-Sample
  