[
https://issues.apache.org/jira/browse/HBASE-10656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918968#comment-13918968
]
Hiroshi Ikeda commented on HBASE-10656:
---------------------------------------
[~stack]
bq. We use Unsafe in other areas of the code base too so a total purge would
take more than just our undoing use of high-scale-lib counters.
I know org.apache.hadoop.hbase.util.Bytes uses Unsafe but it swithces logic in
runtime so that Oracle JDK is indispensable only for build time. On the
contrary, high-scale-lib crachs in runtime when it fails to find Unsafe. I
don't find any things like this in code of HBase, though I'm not sure about the
other 3rd party libraries.
bq. Are we susceptible to the bug you've identified?
I worry a little about HBaseServer using the Counter for some threshold, but by
and large I agree that the effect of the bug itself doesn't seem so serious.
bq. Do we do the write while read w/o protection?
Without locks, reading the count is just only weakly consisntent like
ConcurrentHashMap.size(). While there are threads chainging the count, the
count read is just an estimate, but if there are no such threads while reading
the count it should give the correct count at the time.
[~nkeywal]
bq. Is there any reference to this bug in the high-scale-lib repo?
I just found the bug (or just buggy specification that allows losing counts?)
when I used it by way of experiment, and I didn't so hardly search information
about it in web, because I think the dependency to Oracle JRE is a much more
substantial problem. I think this is not listed up on the bug tickets in the
sourceforge's high-scale-lib page.
> high-scale-lib's Counter depends on Oracle (Sun) JRE, and also has some bug
> ----------------------------------------------------------------------------
>
> Key: HBASE-10656
> URL: https://issues.apache.org/jira/browse/HBASE-10656
> Project: HBase
> Issue Type: Bug
> Reporter: Hiroshi Ikeda
> Priority: Minor
> Attachments: MyCounter.java, MyCounterTest.java
>
>
> Cliff's high-scale-lib's Counter is used in important classes (for example,
> HRegion) in HBase, but Counter uses sun.misc.Unsafe, that is implementation
> detail of the Java standard library and belongs to Oracle (Sun). That
> consequently makes HBase depend on the specific JRE Implementation.
> To make matters worse, Counter has a bug and you may get wrong result if you
> mix a reading method into your logic calling writing methods.
> In more detail, I think the bug is caused by reading an internal array field
> without resolving memory caching, which is intentional the comment says, but
> storing the read result into a volatile field. That field may be not changed
> after you can see the true values of the array field, and also may be not
> changed after updating the "next" CAT instance's values in some race
> condition when extending CAT instance chain.
> Anyway, it is possible that you create a new alternative class which only
> depends on the standard library. I know Java8 provides its alternative, but
> HBase should support Java6 and Java7 for some time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
