[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)