[
https://issues.apache.org/jira/browse/HBASE-12684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259634#comment-14259634
]
Jurriaan Mous commented on HBASE-12684:
---------------------------------------
If I am correct revision 7 == v13. So review should be the same. If I check
revision 7 I see the changes I did in the last patch.
bq. Its a long-standing problem that we have had that you can't say retry for
10 seconds and then give up.. its always been retry N times and then give up
(it has been improving of late but as far as I know, we don't yet have cutoff
at 10 seconds implemented – could be wrong here)
This is the retry for connect failures. It sleeps with amount in
hbase.client.pause before trying to reconnect. Connect currently works with the
retries * sleeptime method. And connect only happens once on Channel creation.
Should I change it to include a max connect timeout?
After connection each operation has its own operation timeout which can be
overridden and is the total time of operation.
bq. Is HBASE_CLIENT_OPERATION_TIMEOUT the global timeout?
It is for all normal calls and is the total time to timeout. Anything scan
related uses HBASE_CLIENT_SCANNER_TIMEOUT_PERIOD.
bq. The patch is not removing the old client because it is possible to select
one or the other? (Can remove in another patch?)
Yes I am currently keeping both to have the option to make them configurable if
AsyncRpcClient is wanted on the 1.x branch as an experimental Rpc Channel. But
maybe if AsyncRpcClient is considered stable enough, RpcClientImpl and all
related classes can be deleted. I can submit a separate patch in this issue
when AsyncRpcClient is done.
bq. Doing the below is convenience? 54 ByteBufInputStream in = new
ByteBufInputStream(inBuffer);
ByteBuf does not implement InputStream. The protobuf writers need an
InputStream to write to. So it was a necessary evil.. I would have preferred to
do without it.
{quote}
RpcServer is doing this:
46 import java.util.*;
So is TestIPC.
{quote}
Will fix it, seems to have slipped in before I fixed my IDE its import settings.
bq. How comes we are an async client but we are doing callBlockingMethod still?
Should we be doing RpcChannel rather than BlockingRpcChannel (or is this
something we do after we get all this in)?
I have not included an RpcChannel implementation at this time since it is not
used in any place. I could include it with a simple test to ensure it works.
But it cannot be used while RpcClientImpl exists since that client cannot
support it.
> Add new AsyncRpcClient
> ----------------------
>
> Key: HBASE-12684
> URL: https://issues.apache.org/jira/browse/HBASE-12684
> Project: HBase
> Issue Type: Improvement
> Components: Client
> Reporter: Jurriaan Mous
> Assignee: Jurriaan Mous
> Attachments: HBASE-12684-v1.patch, HBASE-12684-v10.patch,
> HBASE-12684-v11.patch, HBASE-12684-v12.patch, HBASE-12684-v13.patch,
> HBASE-12684-v2.patch, HBASE-12684-v3.patch, HBASE-12684-v4.patch,
> HBASE-12684-v5.patch, HBASE-12684-v6.patch, HBASE-12684-v7.patch,
> HBASE-12684-v8.patch, HBASE-12684-v9.patch, HBASE-12684.patch
>
>
> With the changes in HBASE-12597 it is possible to add new RpcClients. This
> issue is about adding a new Async RpcClient which would enable HBase to do
> non blocking protobuf service communication.
> Besides delivering a new AsyncRpcClient I would also like to ask the question
> what it would take to replace the current RpcClient? This would enable to
> simplify async code in some next issues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
