[
https://issues.apache.org/jira/browse/CURATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16714864#comment-16714864
]
ASF GitHub Bot commented on CURATOR-487:
----------------------------------------
Github user Randgalt commented on the issue:
https://github.com/apache/curator/pull/282
Can you point to other libraries that have taken the approach of re-writing
these APIs? I see you opened
https://issues.apache.org/jira/browse/COMPRESS-473. Are they taking this change
as well?
> 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)
