hbase-issues mailing list archives

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

    [ https://issues.apache.org/jira/browse/HBASE-12684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259568#comment-14259568
] 

stack commented on HBASE-12684:
-------------------------------

I left some notes on rb but the patch is a bit older over there. Here are some notes on v13:

Is it possible to set a timeout on client ops?  It seems like you do as we currently have
with the n retries going by:

{code}
	267	  /**
268	   * Retry to connect or close
269	   *
270	   * @param bootstrap      to connect with
271	   * @param connectCounter amount of tries
272	   * @param e              exception of fail
273	   */
274	  private void retryOrClose(final Bootstrap bootstrap, int connectCounter, Throwable e)
{
275	    if (connectCounter < client.maxRetries) {
276	      AsyncRpcClient.WHEEL_TIMER.newTimeout(new TimerTask() {
277	        @Override public void run(Timeout timeout) throws Exception {
278	          connect(bootstrap);
279	        }
280	      }, client.failureSleep, TimeUnit.MILLISECONDS);
281	    } else {
282	      client.failedServers.addToFailedServers(address);
283	      close(e);
284	    }
285	  }
{code}

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)

Is HBASE_CLIENT_OPERATION_TIMEOUT the global timeout?

The patch is not removing the old client because it is possible to select one or the other?
(Can remove in another patch?)

Doing the below is convenience?

54	    ByteBufInputStream in = new ByteBufInputStream(inBuffer);

Means you can copy/paste and old code will work because it is still going against an InputStream
rather than netty ByteBuf?  Or is this an idiom?

RpcServer is doing this:

46	import java.util.*;

So is TestIPC.

FYI

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

Patch is excellent.  Lets get it in.  Thanks [~jurmous]





> 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