[
https://issues.apache.org/jira/browse/HBASE-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818530#comment-13818530
]
Benoit Sigoure commented on HBASE-9046:
---------------------------------------
I can further confirm this because in my current environment I use a single
coprocessor, so I devised a workaround for this bug: my coprocessor class has a
{{static int}} I use as a reference count: every time my coprocessor's
{{start}} is called, I increment it, and in {{stop}} I decrement it. In
{{stop}}, when the count drops down to 0, I call
{{CoprocessorClassLoader.clearCache()}}. This fixes the problem for me. This
trick doesn't work for multiple co-processors, because {{clearCache()}} would
clear everything.
Also note that {{clearCache()}} is only exposed for testing purposes so it's
technically not part of the public API.
Another workaround I can think of (but haven't tried) would be to use
reflection to access the underlying map and clear out the entry.
I think the right way to fix this bug is to maintain the reference count
manually by doing the increment/decrement from the {{startup()}} and
{{shutdown()}} methods of {{CoprocessorHost$Environment}}.
> Some region servers keep using an older version of coprocessor
> ---------------------------------------------------------------
>
> Key: HBASE-9046
> URL: https://issues.apache.org/jira/browse/HBASE-9046
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
> Affects Versions: 0.94.8, 0.96.0
> Environment: FreeBSD 8.2-RELEASE FreeBSD 8.2-RELEASE #0 r220198: Thu
> Mar 31 21:46:45 PDT 2011 amd64
> java version "1.6.0_07"
> Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
> Diablo Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
> hbase: 0.94.8, r1485407
> hadoop: 1.0.4, r1393290
> Reporter: iain wright
> Priority: Minor
>
> My team and another user from the mailing list have run into an issue where
> replacing the coprocessor jar in HDFS and reloading the table does not load
> the latest jar. It may load the latest version on some percentage of RS but
> not all of them.
> This may be a config oversight or a lack of understanding of a caching
> mechanism that has a purge capability, but I thought I would log it here for
> confirmation.
> Workaround is to name the coprocessor JAR uniquely, place in HDFS, and
> re-enable the table using the new jar's name.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
