You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Cameron McKenzie (JIRA)" <ji...@apache.org> on 2018/12/09 22:17:00 UTC
[jira] [Assigned] (CURATOR-487) GzipCompressionProvider produces a
lot of finalizable objects
[ https://issues.apache.org/jira/browse/CURATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cameron McKenzie reassigned CURATOR-487:
----------------------------------------
Assignee: Cameron McKenzie (was: Jordan Zimmerman)
> 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)