search

jlorenzen / spymemcached

Automatically exported from code.google.com/p/spymemcached
0 stars 0 forks source link

BaseSerializingTranscoder.decompress() does not close resources #190

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What version of the product are you using? On what operating system?
2.7 
Windows 2008 R2

Tell me more...
lots of java.util.zip is implemented in native code and uses resources that 
must be cleaned up or bad things happen.

BaseSerializingTranscoder.decompress must call .close() on its GZipInputStream 
and should call .close() on its ByteArrayOutputStream in a finally {} block in 
a similar fashion to the code in .compress()

What I am seeing happen in spy with compression under load is lots of threads 
stuck / locked / running infinitely slowly in java.util.zip methods, and 
blowing up Par Survivor Space. The condition persists even with the load gone. 
I suspect the cause to be the above and will retest and confirm shortly.

Original issue reported on code.google.com by jonat...@gmail.com on 28 Jul 2011 at 4:44

GoogleCodeExporter commented 8 years ago 
Another symptom of this is issue is the java process consuming far more memory 
than the jvm's max heap setting; for example the process I observed this with 
had a 1G max heap, but was using 15G. (The memory leaked is malloced in native 
code)

Original comment by jonat...@gmail.com on 29 Jul 2011 at 10:41

GoogleCodeExporter commented 8 years ago 
Sounds like a minor fix and a major problem.

Original comment by dsalli...@gmail.com on 26 Aug 2011 at 6:42

GoogleCodeExporter commented 8 years ago

Original comment by ingen...@gmail.com on 31 Aug 2011 at 10:42

GoogleCodeExporter commented 8 years ago

Original comment by ingen...@gmail.com on 31 Aug 2011 at 10:42

GoogleCodeExporter commented 8 years ago 
Attached is a jar with the fix in the 2.7.2 branch.

Original comment by mikewie...@gmail.com on 7 Sep 2011 at 8:49

Attachments: