Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 16 Apr 2015 04:14:59 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12820945.1429041558000.16111.1429157699556@Atlassian.JIRA>
In-Reply-To: <JIRA.12820945.1429041558000@Atlassian.JIRA>
References: <JIRA.12820945.1429041558000@Atlassian.JIRA>
 <JIRA.12820945.1429041558920@arcas>
Subject: [jira] [Commented] (HBASE-13467) Prototype using GRPC as IPC
 mechanism
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

stack commented on HBASE-13467:
-------------------------------

Looking at GRPCServer....

{code} * - Need to decide what to do about RPC scheduling and priorities in GRPC. Is HTTP2 (bandwidth)
 *   priority sufficient or do we also need to map onto thread priorities{code}

Being able to give requests different priorities is a facility we've leaned on in the past and one we want to do more with (a bunch of work was done here recently. The most basic example is that mapreduce clients should run at a lower priority than requests from the client trying to do low-latency serving... and in current code base, this basically works.

Contributors have also made scheduling pluggable; 'simple' (round robin) is the default but also a 'FIFO' option.

{code} * - Have largely dispensed with the connection header and will either use hardcoded defaults or
 *   headers to replace it over time. Do need a GrpcSession though to cache authentication state.{code}

http headers?

Sounds like server will be listening on two ports then or looking for http preamble in first few connection bytes when we have to support old clients.... (not important just now).

{code} * - Support for delayed calls removed.
{code}

Yes. It doesn't work anyways and needs to be removed.

Fix: public static final Log LOG = LogFactory.getLog(RpcServer.class);

bq.     // TODO(lryan): Bring back the buffer resevoir?

Yeah, or maybe now we should have netty do it for us not you've dragged us over on top of it.

So implementation so far leaves aside scheduling but it bypases Responder, Listener and Reader. How many less threads is that? The simplification is appreciated. My guess is that it will translate into perf gain -- you think so [~lryan] (I can give do some perf runs once something basic is working).

Looks great.

> Prototype using GRPC as IPC mechanism
> -------------------------------------
>
>                 Key: HBASE-13467
>                 URL: https://issues.apache.org/jira/browse/HBASE-13467
>             Project: HBase
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.0.0
>            Reporter: Louis Ryan
>            Priority: Minor
>
> GRPC provide an RPC layer for protocol buffers on top of Netty 4/5. This could be used to replace the current internal implementation.
> GRPC supports some advanced features like streaming, async, flow-control, cancellation & timeout which might be useful
> Will prototype on GitHub here if folks are interested 
> https://github.com/louiscryan/hbase


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)