[
https://issues.apache.org/jira/browse/HBASE-29630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ray Mattingly updated HBASE-29630:
----------------------------------
Description:
At my day job, we wanted custom logic injected around HBase Operations. Our
primary use-case was to fast fail throttled traffic for API traffic. This
allows us to push throttle back-pressure as close to its source as possible, as
quickly as possible, rather than accruing back-pressure in proxy layers in
between a throttled source and the eventual HBase cluster.
We've written what we call [the OperationInterceptor in HubSpot's HBase
fork|https://github.com/HubSpot/hbase/blob/eaf422ca7c3f678100417dcfda1611bc516fb7aa/hbase-client/src/main/java/org/apache/hadoop/hbase/client/OperationInterceptor.java#L56-L56].
It is like the RetryingCallerInterceptor, except it is thread safe and works
for both singular and batch calls. The RetryingCallerInterceptor silently did
not work for batch calls, and is slated for removal in HBase 3+. I'd propose
that we merge HubSpot's OperationInterceptor into HBase 2.6, or similar, as the
successor to the RetryingCallerInterceptor.
was:
At my day job, we wanted custom logic injected around HBase Operations. Our
primary use-case was to fast fail throttled traffic for API traffic. This
allows us to push throttle back-pressure as close to its source as possible, as
quickly as possible, rather than accruing back-pressure in proxy layers in
between a throttled source and the eventual HBase cluster.
We've written what we call [the OperationInterceptor in HubSpot's HBase
fork|https://github.com/HubSpot/hbase/blob/eaf422ca7c3f678100417dcfda1611bc516fb7aa/hbase-client/src/main/java/org/apache/hadoop/hbase/client/OperationInterceptor.java#L56-L56].
It is like the RetryingCallerInterceptor, except it is thread safe and
> RetryingCallerInterceptor should have a successor wired up for both singular
> and batch calls
> --------------------------------------------------------------------------------------------
>
> Key: HBASE-29630
> URL: https://issues.apache.org/jira/browse/HBASE-29630
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 2.6.3
> Reporter: Ray Mattingly
> Assignee: Ray Mattingly
> Priority: Major
>
> At my day job, we wanted custom logic injected around HBase Operations. Our
> primary use-case was to fast fail throttled traffic for API traffic. This
> allows us to push throttle back-pressure as close to its source as possible,
> as quickly as possible, rather than accruing back-pressure in proxy layers in
> between a throttled source and the eventual HBase cluster.
> We've written what we call [the OperationInterceptor in HubSpot's HBase
> fork|https://github.com/HubSpot/hbase/blob/eaf422ca7c3f678100417dcfda1611bc516fb7aa/hbase-client/src/main/java/org/apache/hadoop/hbase/client/OperationInterceptor.java#L56-L56].
> It is like the RetryingCallerInterceptor, except it is thread safe and works
> for both singular and batch calls. The RetryingCallerInterceptor silently did
> not work for batch calls, and is slated for removal in HBase 3+. I'd propose
> that we merge HubSpot's OperationInterceptor into HBase 2.6, or similar, as
> the successor to the RetryingCallerInterceptor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
