accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4419) Create Compressor factory allowing Compression settings to be updated
Date Tue, 23 Aug 2016 14:41:21 GMT

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

Mime
View raw message