[
https://issues.apache.org/jira/browse/HBASE-12856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-12856:
-----------------------------------
Fix Version/s: 1.1.0
0.98.10
2.0.0
Setting fix versions to put it on the radar.
I suppose a change we could make is to store normal references instead. We
would retain one classloader instance for each path to a table coprocessor
implementation jar. That doesn't seem unreasonable and can prevent the scenario
described above.
Thoughts?
> 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
> 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)
