Separate disruptors for encoder and network communications #188
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.
If all destination servers are unavailable the log events fill the ring buffer. Usually it is not an issue, but if you use
LogstashAccessTcpSocketAppender
the memory footprint might be quite significant.In my project I'm using
Spring MVC
which stores a lot of data inHttpServletRequest
attributes - this map is copied toAccessEvent
istances. In my case the ring buffer with default size occupied about 600Mb of heap and caused OOM on my test environmentI believe that log appender should never cause OOM under any circumstances.
I suggest introducing a separate Disruptor for encoding the log events, so even in case of unreachable destination heap would not be occupied with strongly reachable big
AccessEvent
objects:Event -> RingBuffer -> Encoder -> RingBuffer -> TcpAppender