hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10602) Cleanup HTable public interface
Date Fri, 02 May 2014 18:56:17 GMT

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

Enis Soztutar commented on HBASE-10602:
---------------------------------------

I was thinking about how to do a good API for the admin operations like flush, compact, createTable,
etc. We already know that we should provide a default async API (or half-async), but with
the possibility of the client waiting for the operation results, and query the status later.
It has been a discussed (in the master redesign issue, and by Stack in RB for this issue)
that at the RPC layer, we would want to fire up a request like createTable to master, and
get a token back so that we can query the results later with it. But the client level API
does not need to be exposed to tokens etc. 

I am thinking of using Future's for this. What do you guys think? 
{code}
public Future<CompactRegionResult> compactRegion(); 
{code}

For Table APIs like Put, and Get, we might want the same thing. For puts, we won't have setAutoFlush().
We will have either putSync() or put()
{code}
public boolean putSync(Put); 
public Future<PutResult> put(Put); 
{code}

[~nkeywal] was talking about being able to inject a callback between retries so that the user
has greater control. For that though, a callback based API seems more appropriate. 

> Cleanup HTable public interface
> -------------------------------
>
>                 Key: HBASE-10602
>                 URL: https://issues.apache.org/jira/browse/HBASE-10602
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client, Usability
>            Reporter: Nick Dimiduk
>            Assignee: Enis Soztutar
>            Priority: Blocker
>             Fix For: 0.99.0
>
>         Attachments: hbase-10602_v1.patch
>
>
> HBASE-6580 replaced the preferred means of HTableInterface acquisition to the HConnection#getTable
factory methods. HBASE-9117 removes the HConnection cache, placing the burden of responsible
connection cleanup on whomever acquires it.
> The remaining HTable constructors use a Connection instance and manage their own HConnection
on the callers behalf. This is convenient but also a surprising source of poor performance
for anyone accustomed to the previous connection caching behavior. I propose deprecating those
remaining constructors for 0.98/0.96 and removing them for 1.0.
> While I'm at it, I suggest we pursue some API hygiene in general and convert HTable into
an interface. I'm sure there are method overloads for accepting String/byte[]/TableName where
just TableName is sufficient. Can that be done for 1.0 as well?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message