Fix memory leak issues causing OOM after prolonged operation #62
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit addresses GitHub issue #61 where memory usage keeps increasing and garbage collection fails, eventually causing node crashes after several days. Root Causes: 1. SimpleDateFormat objects were created on every message send operation (expensive and thread-unsafe, causing significant memory pressure) 2. HashMap and StringBuilder objects were allocated on every message (constant allocations under high throughput causing GC pressure) Changes Made: PlainSender.java: - Added ThreadLocal<SimpleDateFormat> to reuse date formatter instances - Added ThreadLocal<StringBuilder> to reuse string builder instances CEFSender.java: - Added ThreadLocal<StringBuilder> to reuse string builder (512 byte capacity) FullSender.java: - Added ThreadLocal<HashMap> instances for structured data parameters - Added ThreadLocal<StringBuilder> for dumpMessage method - All maps are cleared and reused instead of creating new instances StructuredSender.java: - Added ThreadLocal<HashMap> instances for structured data parameters - Maps are cleared and reused on each message TransparentSyslogSender.java: - Added ThreadLocal<SimpleDateFormat> to reuse date formatter - Added ThreadLocal<StringBuilder> to reuse string builder (256 byte capacity) SnareWindowsSender.java: - Added ThreadLocal<SimpleDateFormat> for both syslog and MS Event formats - Added ThreadLocal<StringBuilder> to reuse string builder (512 byte capacity) Impact: These changes significantly reduce object allocations and GC pressure by reusing thread-local instances instead of creating new objects for every message. This is especially critical under high message throughput where the plugin was previously creating millions of short-lived objects. The ThreadLocal pattern ensures thread-safety while maintaining performance and dramatically reducing memory consumption. Fixes #61 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 commit addresses GitHub issue #61 where memory usage keeps increasing and garbage collection fails, eventually causing node crashes after several days.
Root Causes:
Changes Made:
PlainSender.java:
CEFSender.java:
FullSender.java:
StructuredSender.java:
TransparentSyslogSender.java:
SnareWindowsSender.java:
Impact:
These changes significantly reduce object allocations and GC pressure by reusing thread-local instances instead of creating new objects for every message. This is especially critical under high message throughput where the plugin was previously creating millions of short-lived objects.
The ThreadLocal pattern ensures thread-safety while maintaining performance and dramatically reducing memory consumption.
Fixes #61
🤖 Generated with Claude Code