hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (HBASE-12856) Revisit table coprocessor classloader caching
Date Wed, 14 Jan 2015 18:50:34 GMT

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

Andrew Purtell reassigned HBASE-12856:

    Assignee: Andrew Purtell

> Revisit table coprocessor classloader caching
> ---------------------------------------------
>                 Key: HBASE-12856
>                 URL: https://issues.apache.org/jira/browse/HBASE-12856
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Andrew Purtell
>            Assignee: Andrew Purtell
>             Fix For: 2.0.0, 0.98.10, 1.1.0
> For table coprocessors, we create coprocessor classloaders and cache them keyed on the
path to the coprocessor jar. However, we cache weak refs so it's quite possible if the refs
are not being retained due to heap pressure we might create a new classloader on the next
region open, i.e. after a split or relocation. If under very heavy write load, perhaps ingest
with all edits skipping the WAL for example, we'd be both generating a ton of garbage and
rapidly splitting at the same time. 
> We should revisit the notion of keeping only weak refs.

This message was sent by Atlassian JIRA

View raw message