I don't have access to the system at the moment (SE 6 RHEL 64-bit). Basically,
invoking a client Get operation causes the app server / JRE to core dump. I
wasn't able to find any specific IBM bug associated with this behavior, but
their issue tracking is not exactly transparent. I don't think that this will
work:
try { } catch(CoreDump) { :D }
Avro and others allow explicit avoidance:
if("false".equals(System.getProperty("hbase.disable.unsafe", "false"))
//attempt unsafe impl
else
//use pure impl
An alternative might be to whitelist java.vendor.
However, I think the explicit solution is better than trying to be too clever.
-----Original Message-----
From: "Ted Yu" <[email protected]>
Sent: Saturday, November 9, 2013 8:28pm
To: "[email protected]" <[email protected]>
Subject: Re: problems with theUnsafe
bq. The IBM JRE supplies Unsafe, but apparently it doesn't work
Can you give us a bit more detail (in this case, UnsafeComparer) ? Is there
a BUG associated with it ?
If there is a known procedure / test by which we can tell whether
UnsafeComparer
works or not, that would help make the decision of switching to pure Java
comparer.
Cheers
On Sat, Nov 9, 2013 at 4:24 PM, <[email protected]> wrote:
>
> Our WebSphere Application Server started core dumping immediately after we
> merged our hbase feature branch to our mainline. I've tracked this down to
> Bytes use of theUnsafe. The IBM JRE supplies Unsafe, but apparently it
> doesn't work worth a damn. I managed to temporarily work "around" the
> issue using some AOP wizardry. Would it be possible to add some property
> check to the static initializer to allow one to explicitly opt for the pure
> Java comparer?
>
>
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hbase/hbase/0.94.7/org/apache/hadoop/hbase/util/Bytes.java#Bytes.LexicographicalComparerHolder.getBestComparer%28%29
>
> thanks,
>
> -Jess
