Link Details

Link 201820 thumbnail
User 191337 avatar

By aviadbd
via chaoticjava.com
Published: Jul 11 2009 / 20:26

How a memory leak was found in a production environment.
  • 23
  • 0
  • 1993
  • 863

Comments

Add your comment
User 388907 avatar

MCII replied ago:

0 votes Vote down Vote up Reply

But what was the reason for the leak??

User 191337 avatar

Aviad Ben Dov replied ago:

0 votes Vote down Vote up Reply

It's all in the article - it was the implementation of java.util.logger together with a badly named logger..

User 388907 avatar

MCII replied ago:

0 votes Vote down Vote up Reply

But why, how, where, ...?
"I tried to look through all the usages of the logger, but it was impossible." - That's no enough.

User 191337 avatar

Aviad Ben Dov replied ago:

0 votes Vote down Vote up Reply

I also explained that we use the logger tool in many locations, so I couldn't seek the usage of the logger.
I later explain that eventually it was the request for a logger with a name that changes constantly - "apparently a user decided to have the timestamp (System.currentTimeMillis) added to one of the logger name requests." and the conclusion: "It seems that the Java Logger keeps a lot of information as cached".

The leak was not in java.util.logger per-se; it was a misuse of it that caused it.

User 61474 avatar

William Louth replied ago:

0 votes Vote down Vote up Reply

Note that the use of weak/soft references alluded to in the comments is not actually implemented in the Java runtime today - until Java 7 is released.

User 191337 avatar

Aviad Ben Dov replied ago:

0 votes Vote down Vote up Reply

Thanks for the info, William. Where can I find more about this, actually?

User 61474 avatar

William Louth replied ago:

0 votes Vote down Vote up Reply

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.