[
https://issues.apache.org/jira/browse/CURATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16714733#comment-16714733
]
ASF GitHub Bot commented on CURATOR-487:
----------------------------------------
Github user Randgalt commented on the issue:
https://github.com/apache/curator/pull/282
I came to this issue late. Are we certain merging this was the right thing
to do? Is there any additional referencing documentation of other projects
doing something similar? I'm concerned about replacing a JDK library method. If
the JDK authors had a better implementation surely they would've updated the
JDK no?
> GzipCompressionProvider produces a lot of finalizable objects
> -------------------------------------------------------------
>
> Key: CURATOR-487
> URL: https://issues.apache.org/jira/browse/CURATOR-487
> Project: Apache Curator
> Issue Type: Improvement
> Reporter: Roman Leventov
> Assignee: Cameron McKenzie
> Priority: Major
> Fix For: 4.1.0
>
>
> GzipCompressionProvider.compress() and decompress() methods are called a lot
> inside and outside of the framework and each such call produces a
> java.util.zip.Deflater or Inflater object that are finalizable, that is bad
> for GC.
>
> Compressing or decompressing a finite byte[] object (in contrast to
> compressing/decompressing an InputStream or an OutputStream of unknown
> length) is actually a happy case because even PhantomReference object could
> be avoided, the native resources could be created and freed in a single
> try-finally block.
>
> Curator must avoid that. [https://github.com/ymnk/jzlib] is a potential
> replacement, for example.
>
> A similar issue could be also fixed in Apache Commons Compress:
> https://issues.apache.org/jira/browse/COMPRESS-473 and Curator is made to
> depend on Commons Compress.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
