[
https://issues.apache.org/jira/browse/HBASE-12856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14277683#comment-14277683
]
Lars Hofhansl commented on HBASE-12856:
---------------------------------------
Thinking about this more... Are we using this map as a cache or as alternate
route to the classloader object (like an index)? In the latter case weak
references are what we want.
The classloader itself should still be strongly referenced by the objects
loaded through it.
So this is probably as it should be.
> 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
(v6.3.4#6332)
