anchor.diff:  - replication (sending the input data to another machine to ensure that there is a remote copy of the data);
   - and business logic (the real processing work).
   
  -Looking at <<user-guide-models>> is possible to see that there are 3 Event Handlers listening (`JournalConsumer`, `ReplicationConsumer` and `ApplicationConsumer`) to the Disruptor, each of these Event Handlers will receive all of the messages available in the Disruptor (in the same order).
  +Looking at <<user-guide-models>> is possible to see that there are 3 ``EventHandler``s listening (`JournalConsumer`, `ReplicationConsumer` and `ApplicationConsumer`) to the Disruptor.
  +Each of these Event Handlers will receive *all* the messages available in the Disruptor (in the same order).
   This allows for work for each of these consumers to operate in parallel.
   ****
   
  
positive.code: | Run 6 | Disruptor=81,699,346 ops/sec
  |===
  
  ==== Alternative Wait Strategies
  
  The default wait strategy used by the Disruptor is the `BlockingWaitStrategy`.
  Internally the `BlockingWaitStrategy` uses a typical lock and condition variable to handle thread wake-up.
  The `BlockingWaitStrategy` is the slowest of the available wait strategies, but is the most conservative with the respect to CPU usage and will give the most consistent behaviour across the widest variety of deployment options.
  However, again knowledge of the deployed system can allow for additional performance.
  
  - **SleepingWaitStrategy** ->
  
  --
  Like the `BlockingWaitStrategy` the `SleepingWaitStrategy` it attempts to be conservative with CPU usage, by using a simple busy wait loop, but uses a call to link:http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/LockSupport.html#parkNanos(long)[`LockSupport.parkNanos(1)`^] in the middle of the loop.
  On a typical Linux system this will pause the thread for around 60µs.
  However it has the benefit that the producing thread does not need to take any action other increment the appropriate counter and does not require the cost of signalling a condition variable.
  However, the mean latency of moving the event between the producer and consumer threads will be higher.
  It works best in situations where low latency is not required, but a low impact on the producing thread is desired.
  A common use case is for asynchronous logging.
  --
  
negative.code: include::{gradle-rootdir}/src/examples/java/com/lmax/disruptor/examples/longevent/LongEventFactory.java[tag=example]
  ----
  
  Once we have the event defined, we need to create a consumer that will handle these events.
  As an example, we will create an `EventHandler` that will print the value out to the console.
  
  .Example `LongEventHandler`
  [source,java]
  