add reply to Groovy closure consumer
add cancel/reply to delegate decorator for closureEventConsumer
Running multiple event handlers in a Disruptor requires multiple threads for all of the event handlers to be invoked. But adding threads to a Processor starts dropping the throughput roughly 1/2 per thread added. In order to maintain consistently high throughput, the Processor Consumer is now a single Consumer rather than a List. If having multiple Consumers in a Processor is desirable, or there is a need to dynamically add or remove Consumers, the DelegatingConsumer can be used to manage the Consumer instances while the single DelegatingConsumer itself can be passed to the ProcessorSpec when creating the Processor.
Fix cut-and-paste typo error.
Fixes #140 Provides a special ConsumerSpec class that exposes event handling assignment in a way that's consistent with other areas within Reactor where a Spec class is used to configure components. Besides a close event handler, this TcpConnection.ConsumerSpec class exposes idleRead and idleWrite timeout handlers, which are invoked when reads or writes are idle for a given timeout value.
Changed the default RingBuffer wait strategy to YieldingWaitStrategy() because it performs better in throughput tests.
Fixed a typo in the javadoc.
Added an optimized event publishing pipeline for notifying a Reactor of events for a given key. Added a prepare(Object key) method that returns a Consumer<Event<T>> that will directly invoke the registered Consumers in the appropriate thread every time accept is called. It optimizes the notification by pre-selecting the Consumers registered for that key and then simply invokes them for each accept rather than following the dynamic path to routing the events.
Groovy builder for environment - reactor - first cut
In order to simplify groovy configuration, especially for simple scripts or grails services, reactor-groovy now provides a statically checked DSL for building environment, reactors and consumers
Leave a constructor to set threadpool name
call onComplete after all consumers
Add consumer support to groovy reactor builder
Renamed abstract Dispatcher class to BaseLifecycleDispatcher to be more consistent with its base class, the BaseDispatcher.
Added a simple $ helper to make it less code to do a String.format() in topic strings. Now you can succinctly format topic strings like `$("%s:%s", namespace, topic)`.
Reflect new name of BaseLifecycleDispatcher superclass.
Added reconnect accept logic into a dispatch to the Netty event loop to do the accept on the "next tick" to avoid a potential race condition with connection consumers.
Default to BlockingWaitStrategy to avoid potential high CPU in some situations. BusySpin and Yielding wait strategies can be utilized by creating a RingBufferDispatcher with those specifications.
Tweak ProcessorThroughputTests to measure raw producer throughput.
Tweak ProcessorThroughputTests to measure raw producer throughput.
Ensure that read idle does not fire when data's being read

The IdleStateHandler that is added to the pipeline to handle read
idle timeouts was being added as the last handler. Crucially, this
places it after NettyTcpConnectionChannelInboundHandler which does
not pass read events any further down the pipeline, thereby preventing
read events from reaching the IdleStateHandler. This meant that
IdleStateHandler's channelRead method was never being driven causing
it to timeout prematurely.

This problem has been addressed by using addFirst() to add the
IdleStateHandler to the start of the pipeline. This ensures that
it's positioned before NettyTcpConnectionChannelInboundHandler,
receives read events and therefore has its channelRead method driven
as required.

The IdleStateHandler used for write idle timeouts is left in its
position at the end of the pipeline where it will see write events.

The all idle timeout for both the read idle and write idle state
handlers has been set to zero to disable it. The all idle timeout
results in an ALL_IDLE event being fired, but only READ_IDLE and
WRITE_IDLE events were being acted upon.

Unit tests have been added to ensure that read idle does not fire
when data is being read from the connection and that write idle does
not fire when data is being written to the connection.