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