[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[ https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14140800#comment-14140800 ] Solomon Duskis commented on HBASE-10602: HTable.getRegionLocations() is an internal deprecated API that's very useful internally. Switch the implementation to use Table and RegionLocator. Cleanup HTable public interface --- Key: HBASE-10602 URL: https://issues.apache.org/jira/browse/HBASE-10602 Project: HBase Issue Type: Umbrella Components: Client, Usability Reporter: Nick Dimiduk Assignee: Enis Soztutar Priority: Blocker Fix For: 0.99.1 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.3.4#6332)
[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[ https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126515#comment-14126515 ] Enis Soztutar commented on HBASE-10602: --- Converting this to be an umbrella jira. A lot of linked stuff has already been done, some more to do as linked jiras. Cleanup HTable public interface --- Key: HBASE-10602 URL: https://issues.apache.org/jira/browse/HBASE-10602 Project: HBase Issue Type: Umbrella Components: Client, Usability Reporter: Nick Dimiduk Assignee: Enis Soztutar Priority: Blocker Fix For: 0.99.1 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.3.4#6332)
[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[ https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14108950#comment-14108950 ] Nicolas Liochon commented on HBASE-10602: - bq. where does the ~100k objects # come from btw?), Just that you can do 100k of puts per second with HBase :-) bq. Wouldn't you want the async call to be the new signature, so it doesn't break backwards compatibility? Yes, agreed. One of the questions not clear to me is batch async and batch streaming. I'm not sure I don't prefer a callback mechanism for them (if you batch multiple operations, they can come back in any order, so the most efficient solution client side is to get the result as it's executed. bq. This also means that you can grow/evolve the Table interface rather than figuring out the future/async version in the first iteration. Agreed it's the right approach. 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)
[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[
https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105437#comment-14105437
]
Carter commented on HBASE-10602:
Wouldn't you want the async call to be the new signature, so it doesn't break
backwards compatibility? I guess it doesn't matter with put, but for
instance checkAndPut and other non-void methods:
{code}
public boolean checkAndPut(byte[], byte[], byte[], byte[], Put);
public FutureBoolean asyncCheckAndPut(byte[], byte[], byte[], byte[], Put);
{code}
This also means that you can grow/evolve the Table interface rather than
figuring out the future/async version in the first iteration.
Last point, following on Nick's assertion about object creation (where does the
~100k objects # come from btw?), you may not want to default the user to an
async call creates more garbage collection in the client, rather let them
decide if they need it.
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)
[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[ https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13993556#comment-13993556 ] Nicolas Liochon commented on HBASE-10602: - bq. We will have either putSync() or put() Seem ok to me, as having a putSync that returns a boolean and not a future (this will save hundred of thousands of object creation compared to a version that return a Future, so I like it). 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)
[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[ https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1392#comment-1392 ] Andrew Purtell commented on HBASE-10602: bq. 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. Server task management with a client API for querying task status was proposed also on HBASE-10170 for long running coprocessor endpoint invocations. 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)
[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[
https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 FutureCompactRegionResult 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 FuturePutResult 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)
[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[ https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981790#comment-13981790 ] Sergey Shelukhin commented on HBASE-10602: -- some feedback on R 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)
[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[
https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911841#comment-13911841
]
Andrew Purtell commented on HBASE-10602:
{quote}
interface Table {
// get, put related stuff
}
{quote}
+1, we get a clean slate to redo the interface and a better name for a client
facing interface.
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
Fix For: 0.99.0
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.1.5#6160)
[jira] [Commented] (HBASE-10602) Cleanup HTable public interface
[
https://issues.apache.org/jira/browse/HBASE-10602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911079#comment-13911079
]
Enis Soztutar commented on HBASE-10602:
---
Let me repeat my comments from dev@ for further discussion here.I propose we do
smt like this:
interface Table {
// get, put related stuff
}
@Deprecated
interface HTableInterface extends Table {
// users are encouraged to use the new Table interface
}
class HTable extends Table {
// all HTable constructors are deprecated
// Users are not encouraged to see this class
}
interface Connection extends Closeable{
getTable(), and rest of HConnection methods
getAdmin()
// no deprecated methods (cache related etc)
}
@Deprecated
interface HConnection extends Connection {
// users are encouraged to use Connection
}
class ConnectionManager {
createConnection(Configuration) // not sure whether we want a static factory
method to create connections or a ctor
}
@Deprecated
class HCM extends ConnectionManager {
// users are encouraged to use ConnectionManager
}
interface Admin {
createTable()
deleteTable()
// only truly client-facing public methods here
}
class HBaseAdmin extends Admin {
// all constructors are deprecated
}
We can introduce this as the default new API, and announce some stability
support for these in the 1.x line
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
Fix For: 0.99.0
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.1.5#6160)
