[
https://issues.apache.org/jira/browse/CURATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16705079#comment-16705079
]
ASF GitHub Bot commented on CURATOR-487:
----------------------------------------
GitHub user leventov opened a pull request:
https://github.com/apache/curator/pull/282
CURATOR-487 Make GzipCompressionProvider to recycle Deflaters and Inflaters
in pools
This PR addresses https://issues.apache.org/jira/browse/CURATOR-487 by
recycling Deflaters and Inflaters in static concurrent pools. Since Deflaters
and Inflaters are acquired and returned to the pools in try-finally blocks that
are free of blocking calls themselves, it's not expected that the number of
objects in the pools could exceed the number of hardware threads on the machine
much. Therefore it's accepted to have simple pools of strongly-referenced
objects.
Just an interesting cross project reference, similar task in Jetty:
https://github.com/eclipse/jetty.project/issues/300
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/leventov/curator
GzipCompressionProvider-references
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/curator/pull/282.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #282
----
commit 6457f267ad713854fb89d32a56f266202cf82cd5
Author: Roman Leventov <leventov.ru@...>
Date: 2018-11-30T17:49:10Z
Make GzipCompressionProvider to recycle Deflaters and Inflaters in pools
----
> 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: Jordan Zimmerman
> 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)
