[
https://issues.apache.org/jira/browse/HBASE-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911938#comment-13911938
]
Nicolas Liochon commented on HBASE-10606:
-----------------------------------------
That's the test result for v1. Still, I'm surprised it made it! I will run the
tests with v2 as well.
bq. Can't we just set it on construction and then be done w/ it rather than
provide exotic options?
I've used the same pattern as in HTable. I think it's useful, as you can do a
call with a different timeout if you need. That's the way I wrote a test for
HTable at least.
bq. private void beforeCall() {
It's replaced by the getRemaining(). It's better, as there is no state anymore
in the object.
bq. If we are removing some infinite timeout, good; commit and lets live w/
the consequence.
Yeah, there will some (bad) consequences for sure...
I'm waiting for the result of v2, I will commit if it's ok. Thanks a lot for
the review.
> Bad timeout in RpcRetryingCaller#callWithRetries w/o parameters
> ---------------------------------------------------------------
>
> Key: HBASE-10606
> URL: https://issues.apache.org/jira/browse/HBASE-10606
> Project: HBase
> Issue Type: Bug
> Components: Client
> Affects Versions: 0.99.0
> Reporter: Nicolas Liochon
> Assignee: Nicolas Liochon
> Fix For: 0.99.0
>
> Attachments: 10606.v1.patch, 10606.v2.patch
>
>
> When we call this method w/o parameters, we don't take into account the
> configuration, but use the hardcoded default (Integer.MAX).
> If someone was relying on having an infinite timeout whatever the setting,
> fixing this bug will cause him a surprise. But there is no magic...
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
