[
https://issues.apache.org/jira/browse/ACCUMULO-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15432924#comment-15432924
]
Josh Elser commented on ACCUMULO-4419:
--------------------------------------
bq. This ticket is to account for work done elsewhere in which I've made the
compression pool configurable such that we either don't use the pool at all or
use an adjustable pool based on commons-pool
[~phrocker], can you give a quick overview as to why we want wouldn't want to
use the pool or would want the adjustable pool as you described?
Best as I can recall, the pooling limits the number of Compressors we have
resident in memory to (de)compress data that we're reading/writing. Each of
these compressors has some internal byte array which consumed a "large" amount
of memory on heap, causing JVM issues. Is that appropriate background for this?
> Create Compressor factory allowing Compression settings to be updated
> ---------------------------------------------------------------------
>
> Key: ACCUMULO-4419
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4419
> Project: Accumulo
> Issue Type: Improvement
> Reporter: marco polo
> Assignee: marco polo
> Priority: Minor
> Labels: core
> Fix For: 1.7.3, 1.8.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This ticket is to account for work done elsewhere in which I've made the
> compression pool configurable such that we either don't use the pool at all
> or use an adjustable pool based on commons-pool
> Other configuration options are now updated through a CompressionUpdate
> mechanism.
> This PR will move us away from CodecPool, but will allow us greater control
> over trimming codecs from the pool itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
