anchor.diff:  
   ==== What can be listened
   .You can decorate the bucket by listener in order to track following events:
  -- When tokens consumed from bucket.
  -- When consumption requests was rejected by bucket.
  -- When thread was parked for wait of tokens refill in result of interaction with ``BlockingBucket``.
  -- When thread was interrupted during the wait of tokens refill  in result of interaction with ``BlockingBucket``.
  -- When delayed task was submit to ``ScheduledExecutorService`` in result of interaction with ``AsyncScheduledBucket``.
  +- When tokens are consumed from a bucket.
  +- When consumption requests were rejected by the bucket.
  +- When thread was parked to wait for tokens refill as a result of interaction with ``BlockingBucket``.
  +- When thread was interrupted during the wait for tokens to be refilled as a result of interaction with ``BlockingBucket``.
  +- When a delayed task was submitted to ``ScheduledExecutorService`` as a result of interaction with ``AsyncScheduledBucket``.
   
   ==== Listener API - corner cases
   ========
  -**Question:** How many listeners is need to create in case of application uses many buckets?
  +**Question:** How many listeners are needed to create an application that uses many buckets?
   
   **Answer:**  it depends:
   
  -- If you want to have aggregated statistics for all buckets then create single listener per application and reuse this listener for all buckets.
  -- If you want to measure statistics independently per each bucket then use listener per bucket model.
  +- If you want to have aggregated statistics for all buckets then create a single listener per application and reuse this listener for all buckets.
  +- If you want to measure statistics independently per each bucket then use a listener per bucket model.
   ========
   
   ========
  -**Question:** where is methods of listener are invoking in case of distributed usage?  
  +**Question:** where are methods the listener is invoking in case of distributed usage?
   
  -**Answer:** listener always invoked on client side, it is means that each client JVM will have own totally independent stat for same bucket.
  +**Answer:** listener always invoked on client side, it means that each client JVM will have its own totally independent stat for the same bucket.
   ========
   
   ========
  -**Question:** Why does bucket invoke the listener on client side instead of server side in case of distributed scenario? What I need to do if I need in aggregated stat across the whole cluster?  
  +**Question:** Why does bucket invoke the listener on client side instead of server side in case of distributed scenario? What do I need to do if I need an aggregated stat across the whole cluster?
   
   **Answer:** Because of planned expansion to non-JVM back-ends such as Redis, MySQL, PostgreSQL.
   It is not possible to serialize and invoke listener on this non-java back-ends, so it was decided to invoke listener on client side,
  
positive.code: You can do post-aggregation of monitoring statistics via features built-into your monitoring database or via mediator(like StatsD) between your application and monitoring database.
  ========
  
  ==== How to attach listener to bucket?
  The bucket can be decorated by listener via ``toListenable`` method.
  [source, java]
  ----
  BucketListener listener = new MyListener();
  
negative.code: ----
  
  ==== Example of integration with Dropwizard metrics-core
  `io.github.bucket4j.SimpleBucketListener` is a simple implementation of `io.github.bucket4j.BucketListener` interface that is available out of the box. Below the example of exposing statistics via Dropwizard Metrics(for Micrometer it should be quite similar):
  [source, java]
  ----
  public static Bucket decorateBucketByStatListener(Bucket originalBucket, String bucketName, MetricRegistry registry) {
    SimpleBucketListener stat = new SimpleBucketListener();
    registry.register(name + ".consumed", (Gauge<Long>) stat::getConsumed);
    registry.register(name + ".rejected", (Gauge<Long>) stat::getRejected);
    registry.register(name + ".parkedNanos", (Gauge<Long>) stat::getParkedNanos);
    registry.register(name + ".interrupted", (Gauge<Long>) stat::getInterrupted);
    registry.register(name + ".delayedNanos", (Gauge<Long>) stat::getDelayedNanos);
  
    return originalBucket.toListenable(stat);
  }
  ----