curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-487) GzipCompressionProvider produces a lot of finalizable objects
Date Mon, 10 Dec 2018 15:04:00 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16714857#comment-16714857
] 

ASF GitHub Bot commented on CURATOR-487:
----------------------------------------

Github user leventov commented on the issue:

    https://github.com/apache/curator/pull/282
  
    Because `GZIPInputStream` and `GZIPOutputStream` are more generic mechanisms, they are
able to compress / decompress arbitrary streams of data, of unknown length, available only
byte-by-byte, etc. Also, `GZIPInputStream` is capable of decompressing series of GZipped sequences,
following one after another. In `GzipCompressionProvider`, the problem statement is much more
narrow: compress/decompress `byte[]`. When decompressing, the array is expected to contain
exactly one GZIP sequence.


> 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)

Mime
View raw message