You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2015/01/14 19:42:35 UTC
[jira] [Created] (HBASE-12856) Revisit table coprocessor
classloader caching
Andrew Purtell created HBASE-12856:
--------------------------------------
Summary: 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
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
(v6.3.4#6332)