[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142033#comment-13142033
]
Hudson commented on HBASE-1744:
---
Integrated in HBase-TRUNK #2399 (See
[https://builds.apache.org/job/HBase-TRUNK/2399/])
HBASE-1744 Thrift server to match the new java api (Tim Sell)
tedyu :
Files :
* /hbase/trunk/CHANGES.txt
* /hbase/trunk/bin/hbase
* /hbase/trunk/src/examples/thrift2
* /hbase/trunk/src/examples/thrift2/DemoClient.java
* /hbase/trunk/src/examples/thrift2/DemoClient.py
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftHBaseServiceHandler.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftServer.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftUtilities.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TColumn.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TColumnIncrement.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TColumnValue.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TDelete.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TDeleteType.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TGet.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/THBaseService.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TIOError.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TIllegalArgument.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TIncrement.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TPut.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TResult.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TScan.java
*
/hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/generated/TTimeRange.java
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/thrift2/package.html
* /hbase/trunk/src/main/resources/org/apache/hadoop/hbase/thrift2
* /hbase/trunk/src/main/resources/org/apache/hadoop/hbase/thrift2/hbase.thrift
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/thrift2
*
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/thrift2/TestThriftHBaseServiceHandler.java
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142197#comment-13142197
]
Ted Yu commented on HBASE-1744:
---
From
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2399/artifact/trunk/target/surefire-reports/org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler-output.txt:
{code}
2011-11-02 09:18:25,930 INFO [main] zookeeper.MiniZooKeeperCluster(141):
Failed binding ZK Server to client port: 21818
2011-11-02 09:18:25,958 INFO [main] zookeeper.MiniZooKeeperCluster(164):
Started MiniZK Cluster and connect 1 ZK server on client port: 21819
{code}
Let's see what happens in build 2400.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
1744.addendum, HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142209#comment-13142209
]
Hudson commented on HBASE-1744:
---
Integrated in HBase-TRUNK #2400 (See
[https://builds.apache.org/job/HBase-TRUNK/2400/])
HBASE-1744 HBaseAdmin ctor should obtain Configuration from
HBaseTestingUtility
tedyu :
Files :
*
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/thrift2/TestThriftHBaseServiceHandler.java
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
1744.addendum, HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13141613#comment-13141613
]
Tim Sell commented on HBASE-1744:
-
I don't think the patch is getting submitted to jenkins.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13141648#comment-13141648
]
Ted Yu commented on HBASE-1744:
---
@Tim:
HadoopQA won't recognize patch v9 which requires -p1 at time of application.
I regenerated patch v10.
Once test result comes back clean, I can integrate.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13141793#comment-13141793
]
Hadoop QA commented on HBASE-1744:
--
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12501880/1744-trunk.10
against trunk revision .
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
-1 javadoc. The javadoc tool appears to have generated -165 warning
messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
-1 findbugs. The patch appears to introduce 40 new Findbugs (version
1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
-1 core tests. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/130//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/130//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/130//console
This message is automatically generated.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13141799#comment-13141799
]
Ted Yu commented on HBASE-1744:
---
@Tim:
Do you want to take care of the following ?
{code}
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/src/test/java/org/apache/hadoop/hbase/thrift2/TestThriftHBaseServiceHandler.java:[108,28]
unreported exception java.lang.Exception; must be caught or declared to be
thrown
{code}
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13141855#comment-13141855
]
Hadoop QA commented on HBASE-1744:
--
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12501883/HBASE-1744.11.patch
against trunk revision .
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 2 new or modified tests.
-1 javadoc. The javadoc tool appears to have generated -165 warning
messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
-1 findbugs. The patch appears to introduce 40 new Findbugs (version
1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.master.TestMasterFailover
org.apache.hadoop.hbase.master.TestDistributedLogSplitting
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/131//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/131//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/131//console
This message is automatically generated.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13141860#comment-13141860
]
Ted Yu commented on HBASE-1744:
---
Failed tested were caused by 'Too many open files'
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13141902#comment-13141902
]
stack commented on HBASE-1744:
--
+1 on commit to TRUNK.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13141911#comment-13141911
]
Ted Yu commented on HBASE-1744:
---
Integrated to TRUNK.
Thanks for the patch, Lars and Tim.
Thanks for the green light Stack.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10,
HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13138740#comment-13138740
]
Jonathan Gray commented on HBASE-1744:
--
One more requested change. Over in HBASE-4658 the map of attributes was added
to the available APIs in thrift. Could we add this to the new TScan, TGet,
etc. structs?
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13138751#comment-13138751
]
Tim Sell commented on HBASE-1744:
-
I think that should be a follow up issue to this rather than a block.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126051#comment-13126051
]
stack commented on HBASE-1744:
--
Fancy, you have democlient for thrift2 too!
Thanks for including a package.html. Should be more forceful about thrift one
being deprecated but I can fix on commit.
It doesn't look like much overlap between thrift2 utilities and the other
thrift utilities if any. Thats good.
There are a bunch of spelling mistakes in the patch. I can fix on commit (And
I though you were in skuhl Tim!) -- Size of pool configuraple
Bob and Tim, you fellas +1 on committing this latest patch. Do tests pass?
The new thrift2 tests? LarsF you have an opinion?
It looks good to me. If you fellas are good, will commit over next few days.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126065#comment-13126065
]
Tim Sell commented on HBASE-1744:
-
Well, Lars did a lot of the work and deserves credit, so not all the typos are
my fault :)
All the demo clients do is a single put and get. The aren't as standalone as
the current thrift package because thrift2 doesn't have a createTable method,
as we are matching HTable only.
The thrift2 tests pass, I haven't run all the hbase tests. I thought submit
patch would do that but it hasn't any of the times I've used it.
+1 on committing this latest patch (with typos fixed).
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126202#comment-13126202
]
Bob Copeland commented on HBASE-1744:
-
+1 from me.
Just tested with latest patch on our cluster, and it passes pybase's (small,
not at all exhaustive) test suite which does some puts, gets, deletes, a
checkAndPut, checkAndDelete, and a range scan with the scanner methods.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13124482#comment-13124482
]
Bob Copeland commented on HBASE-1744:
-
I think it would be useful to take care of this todo:
{quote}
+ * TODO: This is missing the KeyValue.Type.DeleteColumn semantic. I could add
a DeleteType or something like that
{quote}
Right now thrift2 is using deleteColumn() instead of deleteColumns() which I
find to be the least useful of the two (due to re-appearing old versions). I
made a candidate incremental patch on my tree adding a TDeleteType following
the TODO's hint. It's kind of ugly but works for me. I would also be happy
with just using deleteColumns() by default.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.7.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13124663#comment-13124663
]
Ted Yu commented on HBASE-1744:
---
@Bob:
Can you combine your patch with Tim's patch v7 ?
Thanks
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments:
0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch,
HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch,
HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123531#comment-13123531
]
Ted Yu commented on HBASE-1744:
---
+1 on patch v7.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.7.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122938#comment-13122938
]
Tim Sell commented on HBASE-1744:
-
Is run the HBase Thrift2 server ok?
What do you mean by experience? Do you mean examples of usage in different
languages?
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122947#comment-13122947
]
Ted Yu commented on HBASE-1744:
---
run the HBase Thrift2 server is fine.
By experience, usage in different programming languages would be nice to share.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123254#comment-13123254
]
Ted Yu commented on HBASE-1744:
---
src/examples/thrift2/DemoClient.java needs license.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121851#comment-13121851
]
Tim Sell commented on HBASE-1744:
-
Thanks Bob,
my patch still doesn't have tests, looking at that now.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122048#comment-13122048
]
Ted Yu commented on HBASE-1744:
---
I applied patch v4 and got the following:
http://pastebin.com/rmpXff7m
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13122083#comment-13122083
]
Ted Yu commented on HBASE-1744:
---
TestThriftHBaseServiceHandler passed for patch v5.
Can we change the wording for:
{code}
+ echo thrift2 run the new HBase Thrift server
{code}
I believe there would be newer Thrift server down the road :-)
Also, experience using thrift2 would be helpful for other users.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121512#comment-13121512
]
Bob Copeland commented on HBASE-1744:
-
Hi,
I put some fixes for the above issues Ted Yu noted and another fix in my git
tree here (will send Tim S. a pull request in a sec):
http://github.com/bcopeland/hbase-thrift
The other fix was to allow timeRange to be null in scannerOpen's TScan.
(I work on a small python library that wraps the thrift API. I just forward
ported it to thrift2 today and these were the first issues to pop up.)
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13121698#comment-13121698
]
Bob Copeland commented on HBASE-1744:
-
Also, seems checkAndPut() should allow value=null like checkAndDelete() -- I
also made this change on my branch.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.94.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084614#comment-13084614
]
Ted Yu commented on HBASE-1744:
---
I made ThriftServer package private so that the test compiles. But bin/hbase
uses org.apache.hadoop.hbase.thrift2.ThriftServer, I guess it should be public.
I don't see isMasterRunning() in ThriftHBaseServiceHandler so I commented out
the call in TestThriftServer
The new test runs much faster than the existing one:
{code}
Running org.apache.hadoop.hbase.thrift2.TestThriftServer
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.213 sec
Running org.apache.hadoop.hbase.thrift.TestThriftServer
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.776 sec
{code}
Maybe I am missing something.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084616#comment-13084616
]
Ted Yu commented on HBASE-1744:
---
TestThriftServer.testAll() is commented out.
Same with the tests it is supposed to run.
Please finish TestThriftServer.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081208#comment-13081208
]
Ted Yu commented on HBASE-1744:
---
Sorry to get back to this so late.
I got the following:
{code}
[INFO] Compilation failure
/home/hadoop/hbase/src/test/java/org/apache/hadoop/hbase/thrift2/TestThriftServer.java:[68,19]
ThriftServer() has private access in
org.apache.hadoop.hbase.thrift2.ThriftServer
/home/hadoop/hbase/src/test/java/org/apache/hadoop/hbase/thrift2/TestThriftServer.java:[83,22]
cannot find symbol
symbol : method isMasterRunning()
location: class org.apache.hadoop.hbase.thrift2.ThriftHBaseServiceHandler
{code}
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch,
HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056883#comment-13056883
]
Ted Yu commented on HBASE-1744:
---
@Tim, any update ?
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.2.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054029#comment-13054029
]
Ted Yu commented on HBASE-1744:
---
I tried to apply latest patch on TRUNK.
It doesn't compile:
{code}
/home/hadoop/hbase/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftHBaseClientHandler.java:[41,23]
unreported exception java.io.IOException; must be caught or declared to be
thrown
/home/hadoop/hbase/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftServer.java:[135,17]
cannot find symbol
symbol : constructor
TNonblockingServer(org.apache.hadoop.hbase.thrift2.generated.HbaseClient.Processor,org.apache.thrift.transport.TNonblockingServerTransport,org.apache.thrift.transport.TFramedTransport.Factory,org.apache.thrift.protocol.TProtocolFactory)
location: class org.apache.thrift.server.TNonblockingServer
/home/hadoop/hbase/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftServer.java:[138,17]
cannot find symbol
symbol : constructor
THsHaServer(org.apache.hadoop.hbase.thrift2.generated.HbaseClient.Processor,org.apache.thrift.transport.TNonblockingServerTransport,org.apache.thrift.transport.TFramedTransport.Factory,org.apache.thrift.protocol.TProtocolFactory)
location: class org.apache.thrift.server.THsHaServer
/home/hadoop/hbase/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftServer.java:[165,15]
cannot find symbol
symbol : constructor
TThreadPoolServer(org.apache.hadoop.hbase.thrift2.generated.HbaseClient.Processor,org.apache.thrift.transport.TServerTransport,org.apache.thrift.transport.TTransportFactory,org.apache.thrift.protocol.TProtocolFactory)
location: class org.apache.thrift.server.TThreadPoolServer
{code}
@Lars, can you take a look ?
Thanks
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.2.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054036#comment-13054036
]
Tim Sell commented on HBASE-1744:
-
I have been working on this, continuing work I did at the berlin buzzwords
hbase hackday.
https://github.com/tims/hbase-thrift
I'll make a patch the fixes I made to Lars stuff and upload it here asap.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.2.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13025153#comment-13025153
]
Lars Francke commented on HBASE-1744:
-
https://issues.apache.org/jira/browse/THRIFT-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024799#comment-13024799
Thrift is finally in the Maven repository!
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.2.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13025249#comment-13025249
]
stack commented on HBASE-1744:
--
@Lars Some fellas figured it ahead of you (smile). See
https://mail.google.com/mail/?shva=1#label/hbase-issues/12f8cf7db44d14fb
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.2.patch, HBASE-1744.preview.1.patch,
thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006375#comment-13006375
]
Lars Francke commented on HBASE-1744:
-
I'm afraid I will finally have to say that I have no idea when I'll be able to
work on this. I've promised it for a long time but if anyone else wants to take
a stab at it feel free.
I'm pretty confident in the Thrift definition file I've come up with. It needs
some minor updates for the updated API (increment for example) and the delete
method is still missing one of the possible cases (I've documented it in the
patch) and filters are not implemented yet either.
I'll gladly answer any questions about this in case anyone wants to work on it
and if I have the time I'll improve the patch but I can't promise anything,
sorry :(
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12994573#comment-12994573
]
ryan rawson commented on HBASE-1744:
talking about this recently with stack, I made the point that we should
probably put the new API in the same package/thrift file as the old. Use new
symbols, at the end of the .thrift file. That way people can use new and old
clients with the same server, making migration easier. It might make some names
a little ugly (we could go with the windowsy Ex suffix?) but making an easier
migration strategy is important I feel.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968988#action_12968988
]
stack commented on HBASE-1744:
--
@Lars Any chance of your updating this patch? I'd like to get it into TRUNK
for 0.92. Good on you.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12922173#action_12922173
]
Bryan Duxbury commented on HBASE-1744:
--
Stack asked me to take a look at your Thrift IDL. Here are the comments I came
up with:
- It's a little confusing to typedef binary to Bytes, but that's all cosmetic.
- All your files (types, admin, client) use the same java namespace. This means
they'll all generate a Constants.java with the same path, which means 2/3 of
them will be clobbered. You only have constants in one of the files, which is
good, but I think there's a good chance that class will be destroyed.
Otherwise, looks good to me.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921845#action_12921845
]
Lars Francke commented on HBASE-1744:
-
{quote}So, you are going to have a thrift2 package for the new stuff. I don't
know of any other way of deprecating the old thrift api while introducing the
new. Any ideas on how once we remove the original thrift, of how we'd move
thrift2 to thrift package?{quote}
That was the easiest option for now but if you have any other ideas? I could
throw all that stuff in the old package as well - I don't think there are any
name-clashes. The only idea I have for moving the stuff afterwards:
0.92: Deprecate thrift, introduce thrift2
0.94: Remove old thrift, deprecate thrift2, copy thrift2 to thrift
0.96: Remove thrift2
As I said: I can easily throw it all in the current thrift package I guess.
{quote}Why would I need an HBaseAdminPool? Why not just create one each time?
Why have one at all? Just let thriftians use shell if they want admin
functionality?{quote}
That class is a remnant from an earlier patch I never finished. Not used at the
moment. I think an optional Thrift-Admin interface would be nice but I'll
concentrate on the regular client stuff for now.
{quote}IRC, this does not make a new array each time - it just returns the
ByteBuffer backing array:{quote}
Yes that's the intention. I know it ain't the most proper way but it should
work. Otherwise I'd need to do something like
{code}
ByteBuffer bb = ...
byte[] arr = new byte[bb.remaining()];
bb.get(arr);
{code}
or use a CharsetDecoder or CharBuffer or something like that. I'm really not
sure how to best handle ByteBuffers. So any hint would be great.
{quote}There are missing licenses on new files and missing copyright
header.{quote}
Thanks will fix that!
{quote}I'd imagine this has to be public for some reason else you'd make it
private?{quote}
No that was just an oversight as far as I can see. Thanks, will look at it.
The rest you mentioned is not finished yet - it's just a literal copy paste
from the old code (that's why the tests are commented out). I didn't change a
thing yet. But it's on my list.
I just thought it was about time I finally showed some results :)
And sure this can go into 0.92 - it has very little dependencies on the rest of
the code so I'll keep the patch updated if needed.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921920#action_12921920
]
ryan rawson commented on HBASE-1744:
i would be against the thrift2 and package moving stuff. It would require our
users to start a particular version of thrift depending on which one they
wanted, and would make it difficult for users to migrate, unless you also came
up with a way to run both .thrift files in 1 server.
Thrift doesnt appear to offer any @deprecated tags, so we are probably going to
have to do this the old fashioned way.
But even so, I think the timeline to remove the old API is pretty aggressive.
We removed BatchUpdate fairly quickly, and unless there is a compelling reason
I'd rather keep old APIs around just a bit longer. Makes transition easier
since it gives users more time.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921924#action_12921924
]
Lars Francke commented on HBASE-1744:
-
Services can extend each other so I can - in theory - extend the old API so
both would be available in one server but I don't know if that is really a good
option. I don't think it would be a technical problem though. The APIs are so
different - I think they share some exceptions but that's it (and those are
fine). Come to think of it: Both have a get(...) method if I remember correctly
(Thrift does not know overloaded methods) so we'd have to rename one of the two.
Yeah unfortunately Thrift does not have any options for deprecating stuff so
we'll just have to communicate it prominently.
The timeline I posted up there was purely fictional. Nothing stops us from
keeping both APIs around. The maintenance overhead so far isn't that bad as far
as I can tell. But we should make it very clear that one of the two is probably
going away at some point to avoid confusion.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921787#action_12921787
]
stack commented on HBASE-1744:
--
So, you are going to have a thrift2 package for the new stuff. I don't know of
any other way of deprecating the old thrift api while introducing the new. Any
ideas on how once we remove the original thrift, of how we'd move thrift2 to
thrift package?
Why would I need an HBaseAdminPool? Why not just create one each time? Why
have one at all? Just let thriftians use shell if they want admin
functionality?
IIRC, this does not make a new array each time -- it just returns the
ByteBuffer backing array:
{code}
+HTableInterface htable = getTable(table.array());
{code}
I like your getFromThrift and getFromHBase namings.
Oh, nice, you are doing multiget (and multiput)... and incrementColumnValues.
There are missing licenses on new files and missing copyright header.
I'd imagine this has to be public for some reason else you'd make it private?
{code}
+ public ThriftServer() {
{code}
This is cool:
{code}
+options.addOption(f, framed, false, Use framed transport);
+options.addOption(c, compact, false, Use the compact protocol);
{code}
Just remove this I'd say:
{code}
+ public void testAll() throws Exception {
..
{code}
Start cluster once rather than per test?
{code}
+ @Before
+ public void setUp() throws Exception {
{code}
Oh, all tests are commented out? Or some of them?
Hmmm... looks kinda great to me Lars.
On what I said on IRC, I'd say, we can let this be 0.92. 0.92 is soon after
0.90 so that should help. Meantime anyone who needs new thrift can apply this
patch?
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Priority: Critical
Fix For: 0.92.0
Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12918211#action_12918211
]
Jonathan Gray commented on HBASE-1744:
--
Lars, what's time estimate for this? Should we punt to 0.92?
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Lars Francke
Fix For: 0.90.0
Attachments: Hbase.thrift, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-1744) Thrift server to match the new java api.
[
https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903511#action_12903511
]
Jean-Daniel Cryans commented on HBASE-1744:
---
I don't know if it's on your list Lars, but it would be nice when opening
scanners to be able to pass a scanner caching value. This would make more sense
than having to set a default value in the configuration to make scanning
faster, and it would play nice with numRows of getScannerRows.
Thrift server to match the new java api.
Key: HBASE-1744
URL: https://issues.apache.org/jira/browse/HBASE-1744
Project: HBase
Issue Type: Improvement
Components: thrift
Reporter: Tim Sell
Assignee: Tim Sell
Fix For: 0.90.0
Attachments: Hbase.thrift, thriftexperiment.patch
This mutateRows, etc.. is a little confusing compared to the new cleaner java
client.
Thinking of ways to make a thrift client that is just as elegant. something
like:
void put(1:Bytes table, 2:TPut put) throws (1:IOError io)
with:
struct TColumn {
1:Bytes family,
2:Bytes qualifier,
3:i64 timestamp
}
struct TPut {
1:Bytes row,
2:mapTColumn, Bytes values
}
This creates more verbose rpc than if the columns in TPut were just
mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and
still be intuitive from say python.
Presumably the goal of a thrift gateway is to be easy first.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
