[
https://issues.apache.org/jira/browse/HBASE-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872018#action_12872018
]
Dave Latham commented on HBASE-2445:
------------------------------------
I have a use case where I'd like to perform a Get with a timeout of 500 ms or
so. If HBase is unable to retrieve the result within that time, an exception or
null result is fine, though most of the time, I expect it to work fine. The
same process has other uses where the normal retry policy makes sense, but in
this case, it has to be fast, or nothing. Right now I'm forced to create a
separate thread pool to handle these requests, and the threads can all get tied
up trying to hit one bad regionserver, for example.
Not sure if this case will be solved by this JIRA, but it seems related.
> Clean up client retry policies
> ------------------------------
>
> Key: HBASE-2445
> URL: https://issues.apache.org/jira/browse/HBASE-2445
> Project: HBase
> Issue Type: Improvement
> Components: client
> Reporter: Todd Lipcon
> Priority: Critical
> Fix For: 0.21.0
>
>
> Right now almost all retry behavior is governed by a single parameter that
> determines the number of retries. In a few places, there are also conf for
> the number of millis to sleep between retries. This isn't quite flexible
> enough. If we can refactor some of the retry logic into a RetryPolicy class,
> we could introduce exponential backoff where appropriate, clean up some of
> the config, etc
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
