You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/12/10 02:59:00 UTC
[jira] [Commented] (CURATOR-487) GzipCompressionProvider produces a
lot of finalizable objects
[ https://issues.apache.org/jira/browse/CURATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16714226#comment-16714226 ]
ASF GitHub Bot commented on CURATOR-487:
----------------------------------------
Github user cammckenzie commented on the issue:
https://github.com/apache/curator/pull/282
Thanks for the PR @alexbrasetvik I will merge this shortly.
> 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
>
> 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)