Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leaking memory through RingBuffer? #110

Closed
dimas opened this issue Jul 1, 2015 · 2 comments
Closed

Leaking memory through RingBuffer? #110

dimas opened this issue Jul 1, 2015 · 2 comments

Comments

@dimas
Copy link
Contributor

dimas commented Jul 1, 2015

I have a million dollar question - what releases an object from RingBuffer after it was handled by the appender? That is what nulls the entry in the ring buffer after we done with it?

I have a very bad feeling that it is not done so all these objects keep hanging in the memory until the current item pointer wraps and starts overwriting old items. Quick look at heap dumps confirms that but we did not dig deeper.

It it is the case, it can be really a catastrophic thing for any application. LogEntry objects can be HUGE as they contain not just a text message but also stack traces and all the parameters passed to log.debug() or log.warn(). And 3rd party libs can pass anything they like there expecting that toString() will be invoked on it. For example Hector (Cassandra client) passes entire connection object there so if that object sits in the ring buffer for a long time it prevents a significant amount of memory (megabytes) from being collected by GC.

@philsttr
Copy link
Collaborator

philsttr commented Jul 2, 2015

Hey @dimas,

Nice find. Yes, references were being kept around until they were overwritten the next time around. I've fixed this for version 4.4, to be released soon.

@philsttr
Copy link
Collaborator

4.4 has been released with this fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants