[
https://issues.apache.org/jira/browse/HBASE-13784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562659#comment-14562659
]
Jurriaan Mous commented on HBASE-13784:
---------------------------------------
Thanks for your comments!
{quote}
This would be nice:
"38 * TODO: this class is actually tied to one region, because most of the
paths make use of
39 * the regioninfo part of location when building requests. The only
reason it works for
40 * multi-region requests (e.g. batch) is that they happen to not use the
region parts.
41 * This could be done cleaner (e.g. having a generic parameter and 2
derived classes,
42 * RegionCallable and actual RegionServerCallable with ServerName."
...because as you note, otherwise the TableName is superfluous here:
{quote}
That comment was already in RegionServerCallable which I renamed to
AbstractRegionServerCallable to be able to make an Async version which shares
code. So that good suggestion falls outside of my work :)
{quote}
We need this method below?
protected void setLocation(final HRegionLocation location) {
It can't figure it out internally? Has to have it passed in?
We need this method below?
protected void setLocation(final HRegionLocation location) {
It can't figure it out internally? Has to have it passed in?
The sleep, throwable, getExceptionMessageAdditionalDetail , etc., methods were
there already?
Should this be set on construction?
{quote}
It was already there in the non abstract version of the class. Changing this
flow falls outside of the scope of the issue.
{quote}
abstract void setClientByServiceName(ServerName serviceName) throws IOException;
Get a new instance if you want to connect to a different service?
{quote}
Yes with the blocking variants it will set a Stub on prepare and with the async
variant it will set an AsyncRpcChannel internally. Those channels are currently
bound to the service due to the protocol. I left it up to the implementing
class to actually set the right typed properties.
{quote}
What is your understanding around how timeouts work now? Have you ported the
mess we have in old client where we have retries and timeouts ... with it
difficult to set an overall timeout on a connection attempt?
{quote}
With the work I am doing I was trying to change as little as possible to the
current behaviour. The current behaviour is implemented in the new
RetryingResponsePromise.
It is also possible to do a timer (With Netty HashedWheelTimer) on the
RetryingResponsePromise so it shuts down after some amount of time of waiting.
Should I add an overall timeout to the RetryingResponsePromise? (It seems I
forgot to add a stop after max amount of retries has been reached in current
patch)
{quote}
Louis Ryan This route would jibe w/ the PoC you are doing?
{quote}
I just now discovered [~louiscryan] his work. From what I can see is that Louis
is building a new Client and Server RPC client based on GRPC. He builds on top
of some abstractions I did while creating the AsyncRpcClient so is good to see
it being used further. It is nice to have a generalized implementation of the
RPC layer with HTTP2, Streams and things like extra GZip ChannelEncoders.
A new async client table interface would in principle not conflict with his
work although to make it as efficient as possible I am exposing some internals
of the async client like its internal promise and eventloop for promise
creation on top of Netty Thread pool. With the code that I see in the github
and GRPC async Calls it should be possible to add those constructs to his
implementation. I have already abstracted the needed methods to interfaces and
since his implementation is also Netty based it should be not difficult to add
the methods to his GrpcClientImpl and expose an AsyncRpcChannel implementation
to communicate with.
> Add Async Client Table API
> --------------------------
>
> Key: HBASE-13784
> URL: https://issues.apache.org/jira/browse/HBASE-13784
> Project: HBase
> Issue Type: New Feature
> Reporter: Jurriaan Mous
> Assignee: Jurriaan Mous
> Attachments: HBASE-13784-v1.patch, HBASE-13784.patch
>
>
> With the introduction of the Async HBase RPC Client it is possible to create
> an Async Table API and more. This issue is focussed on creating a first async
> Table API so it is possible to do any non deprecated Table call in an async
> way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
