[
https://issues.apache.org/jira/browse/HBASE-25251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17227514#comment-17227514
]
Andrew Kyle Purtell edited comment on HBASE-25251 at 11/6/20, 5:13 PM:
-----------------------------------------------------------------------
[~anoop.hbase] I already committed a patch which does that. All the calls we
make in the code are checked by UnsafeAvailChecker.
We recently had some issue on branch-1 where our code was passing 'int' params
instead of the required 'long', but that was not UnsafeAvailChecker issue, it
required a change to data types in our code. That fix was recently committed.
No changes are needed to UnsafeAvailChecker, it provides full coverage, that's
not the issue.
What we want to achieve with this goal is turning off Unsafe on the client
side. _Even where Unsafe is available_. Unsafe is very important on the server,
where we might do billions (possibly trillions?) of comparisons per day at
scale serving hundreds or thousands of clients. On the client side, the
operating conditions are different, and the risk-reward calculation is
different. The risk of memory corruptions that comes with Unsafe – in our case,
the hbase client using Unsafe is embedded in our business logic application
server – leading to hard to diagnose issues, especially when we are
diversifying Java versions there (11 vs. 8, etc.) is a risk we would like to
opt out of.
So we need a configuration variable that allows us to opt out. It will not be
the default so others don't get forced to make a change to opt back in.
On this basis I am going to approve the PR.
was (Author: apurtell):
[~anoop.hbase] I already committed a patch which does that. All the calls we
make in the code are checked by UnsafeAvailChecker.
We recently had some issue on branch-1 where our code was passing 'int' params
instead of the required 'long', but that was not UnsafeAvailChecker issue, it
required a change to data types in our code. That fix was recently committed.
No changes are needed to UnsafeAvailChecker, it provides full coverage, that's
not the issue.
What we want to achieve with this goal is turning off Unsafe on the client
side. _Even where Unsafe is available_. Unsafe is very important on the server,
where we might do billions (possibly trillions?) of comparisons per day at
scale serving hundreds or thousands of clients. On the client side, the
operating conditions are different, and the risk-reward calculation is
different. The risk of memory corruptions that comes with Unsafe – in our case,
our business logic application server – leading to hard to diagnose issues,
especially when we are diversifying Java versions there (11 vs. 8, etc.) is a
risk we would like to opt out of.
So we need a configuration variable that allows us to opt out. It will not be
the default so others don't get forced to make a change to opt back in.
On this basis I am going to approve the PR.
> Enable configuration based enable/disable of Unsafe package usage
> -----------------------------------------------------------------
>
> Key: HBASE-25251
> URL: https://issues.apache.org/jira/browse/HBASE-25251
> Project: HBase
> Issue Type: Improvement
> Reporter: Sandeep Guggilam
> Assignee: Sandeep Guggilam
> Priority: Major
>
> We need a provide away for clients to disable Unsafe package usage .
> Currently there is no way for clients to specify that they don't want to use
> Unsafe conversion for Bytes conversion.
> As a result there could be some issues with missing methods of Unsafe when
> client is on JDK 11 . So the clients can disable Unsafe package use and use
> normal conversion if they want to.
> Also we use static references to Unsafe Availability in Bytes class assuming
> that the Unsafe availability is set during class loading and no one can ever
> override it later. Now that we plan to expose a util for clients to override
> the availability if required, we need to avoid the static references for
> computing the availability whenever we do the comparisions
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
