[ 
https://issues.apache.org/jira/browse/BLUR-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aaron McCurry closed BLUR-229.
------------------------------

    Resolution: Fixed

I am going to consider this issue closed.  A lot of testing has been performed 
on the new block cache and I think it's ready to go.

> Make V2 of the Block Cache production ready.
> --------------------------------------------
>
>                 Key: BLUR-229
>                 URL: https://issues.apache.org/jira/browse/BLUR-229
>             Project: Apache Blur
>          Issue Type: New Feature
>          Components: Blur
>    Affects Versions: 0.3.0, 0.2.1
>            Reporter: Aaron McCurry
>             Fix For: 0.3.0, 0.2.1
>
>
> This task will be to make the new version of the Block Cache production ready.
> The code can be found in:
> https://git-wip-us.apache.org/repos/asf?p=incubator-blur.git;a=shortlog;h=refs/heads/0.2.1
> The big features for this new code are the following:
> 1. Variable length cache block sizes.  The big need for this is in filtering. 
>  Creating huge bits sets on the heap to cache filters created by inbound 
> queries can be hard to manage.  It can also production performance problems 
> (GC issues) and can cause OOM errors if too many filters are created.  If a 
> filter can be written as a file per segment and cached as a single unit in 
> the block cache, then it will be as performant as on heap bitset but will 
> live off the heap and under the same resource constraints placed on the block 
> cache.  So basically when a cluster is over allocated (when it comes to 
> caching filters) the cluster will be less likely to fail and instead will 
> perform more slowly.
> 2. Block cache size can be dynamically changed.
> 3. Simpler implementation for the off heap slabs of memory.  Which should 
> also make it faster.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to