hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jurriaan Mous (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12684) Add new AsyncRpcClient
Date Sun, 28 Dec 2014 13:39:14 GMT

    [ 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)

Mime
View raw message