[
https://issues.apache.org/jira/browse/HBASE-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993276#comment-12993276
]
ryan rawson commented on HBASE-3523:
------------------------------------
Things that are issues:
- the use of proxy means that the interfaces _must have_ InterruptedException
on the interface, or else you get "undeclared throwable exception", but now you
are conflating a business contract (the interfaces) and networking/execution
realities. Futhermore going through a proxy object isn't necessary, its just
more layers, since few people directly code against the interfaces.
- multiple level of timeouts causes unnecessary confusion. Also the retry loops
in HCM cause confusion and issues.
- client should support parallelism more directly, no more thread pools that
just sleep!
- lots of callables make the code harder to read, either get rid of them or use
more inner classes. Jumping around files makes for difficult comprehension.
Some good things:
- the base socket handling is actually in good shape. 1 socket per client-rs
pair is about where we want to be.
- multiplexing requests on the same socket is good, not spawning extra threads
server side just to handle more clients is also good. since every client will
have an open socket to at least the META region, this is very important!
- the handler pool is a natural side effect of the previous point, unbounding
it might not be a good idea.
Other constraints:
- we will want to provide an efficient blocking API, it's what is expected.
- an async api might be nice, perhaps it can layer on or something.
- Making HTable thread agnostic might be useful. Pooling the write buffer or
doing something else interesting there would be necessary.
> Rewrite our client
> ------------------
>
> Key: HBASE-3523
> URL: https://issues.apache.org/jira/browse/HBASE-3523
> Project: HBase
> Issue Type: Brainstorming
> Reporter: stack
>
> Is it just me or do others sense that there is pressure building to redo the
> client? If just me, ignore the below... I'll just keep notes in here.
> Otherwise, what would the requirements for a client rewrite look like?
> + Let out InterruptedException
> + Enveloping of messages or space for metadata that can be passed by client
> to server and by server to client; e.g. the region a.b.c moved to server
> x.y.z. or scanner is finished or timeout
> + A different RPC? One with tighter serialization.
> + More sane timeout/retry policy.
> Does it have to support async communication? Do callbacks?
> What else?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
