send messages using a lmax disruptor instead of a blockng queue #10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
| This gives a significant performance increase in highly multithreaded jvms.
| http://lmax-exchange.github.io/disruptor/
|
| The lmax disruptor's ringBuffer size is initialised to 16k.
| Rationale here is that statsd msgs are short strings, and sending 10k/s is a normal use-case.
| If the Handler thread fails to send out the udp packets fast enough
| (given it also squashes statsd messages into available MTU space)
| and the ringBuffer becomes full then new statsd messages will be dropped and
| a InsufficientCapacityException passed to the exception handler…
|
| Exceptions from the lmax disruptor and handler are passed through to the exception handler.
| Throwables from the lmax disruptor are logged as SEVERE.
This branch is based off bugfix/vanilla-statsd-time-semantics which includes the commit in #8