date:20140226

[jira] [Commented] (HBASE-10615) Make LoadIncrementalHFiles skip reference files

2014-02-26 Thread Hadoop QA (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912622#comment-13912622
]

Hadoop QA commented on HBASE-10615:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment

http://issues.apache.org/jira/secure/attachment/12631153/HBASE-10615-trunk.patch
against trunk revision .
ATTACHMENT ID: 12631153

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.

{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.

{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:green}+1 site{color}. The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}. The patch passed unit tests in .

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8810//console

This message is automatically generated.

Make LoadIncrementalHFiles skip reference files
---

Key: HBASE-10615
URL: https://issues.apache.org/jira/browse/HBASE-10615
Project: HBase
Issue Type: Improvement
Affects Versions: 0.96.0
Reporter: Jerry He
Assignee: Jerry He
Priority: Minor
Attachments: HBASE-10615-trunk.patch

There is use base that the source of hfiles for LoadIncrementalHFiles can be
a FileSystem copy-out/backup of HBase table or archive hfiles. For example,
1. Copy-out of hbase.rootdir, table dir, region dir (after disable) or
archive dir.
2. ExportSnapshot
It is possible that there are reference files in the family dir in these
cases.
We have such use cases, where trying to load back into HBase, we'll get
{code}
Caused by: org.apache.hadoop.hbase.io.hfile.CorruptHFileException: Problem
reading HFile Trailer from file
hdfs://HDFS-AMR/tmp/restoreTemp/117182adfe861c5d2b607da91d60aa8a/info/aed3d01648384b31b29e5bad4cd80bec.d179ab341fc68e7612fcd74eaf7cafbd
at
org.apache.hadoop.hbase.io.hfile.HFile.pickReaderVersion(HFile.java:570)
at
org.apache.hadoop.hbase.io.hfile.HFile.createReaderWithEncoding(HFile.java:594)
at org.apache.hadoop.hbase.io.hfile.HFile.createReader(HFile.java:636)
at
org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.groupOrSplit(LoadIncrementalHFiles.java:472)
at
org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles$2.call(LoadIncrementalHFiles.java:393)
at
org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles$2.call(LoadIncrementalHFiles.java:391)

[jira] [Commented] (HBASE-9914) Port fix for HBASE-9836 'Intermittent TestRegionObserverScannerOpenHook#testRegionObserverCompactionTimeStacking failure' to 0.94

2014-02-26 Thread Hadoop QA (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-9914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912629#comment-13912629
 ] 

Hadoop QA commented on HBASE-9914:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12631154/HBASE-9914-0.94.17-v01.patch
  against trunk revision .
  ATTACHMENT ID: 12631154

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8811//console

This message is automatically generated.

 Port fix for HBASE-9836 'Intermittent 
 TestRegionObserverScannerOpenHook#testRegionObserverCompactionTimeStacking 
 failure' to 0.94
 -

 Key: HBASE-9914
 URL: https://issues.apache.org/jira/browse/HBASE-9914
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Assignee: takeshi.miao
  Labels: noob
 Attachments: HBASE-9914-0.94.17-v01.patch


 According to this thread: http://search-hadoop.com/m/3CzC31BQsDd , 
 TestRegionObserverScannerOpenHook#testRegionObserverCompactionTimeStacking 
 sometimes failed.
 This issue is to port the fix from HBASE-9836 to 0.94



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10614) Master could not be stopped

2014-02-26 Thread Hudson (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912633#comment-13912633
]

Hudson commented on HBASE-10614:

SUCCESS: Integrated in HBase-0.94-JDK7 #64 (See
[https://builds.apache.org/job/HBase-0.94-JDK7/64/])
HBASE-10614 Master could not be stopped (Jingcheng Du) (stack: rev 1571918)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/handler/ServerShutdownHandler.java

Master could not be stopped
---

Key: HBASE-10614
URL: https://issues.apache.org/jira/browse/HBASE-10614
Project: HBase
Issue Type: Bug
Components: master
Affects Versions: 0.94.16, 0.99.0
Reporter: Jingcheng Du
Assignee: Jingcheng Du
Fix For: 0.96.2, 0.98.1, 0.99.0, 0.94.18

Attachments: HBASE-10614-0.94.patch, HBASE-10614.patch

It's an issue when to run bin/hbase master stop to shutdown the cluster.
This could be reproduced by the following steps. Particularly for the trunk
code, we need to configure the hbase.assignment.maximum.attempts as 1.
1. Start one master and several region servers.
2. Stop all the region servers.
3. After a while, run bin/hbase master stop to shutdown the cluster.
As a result, the master could not be stopped within a short time, but will
be stopped after several hours. And after it's stopped, i find the error logs.
1. For the trunk:
A. lots of the logs which are java.io.IOException: Failed to find
location, tableName=hbase:meta, row=, reload=true
B..And at last, there's one exception before the master is stopped,
ServerShutdownHandler: Received exception accessing hbase:meta during server
shutdown of server-XXX, retrying hbase:meta read
java.io.InterruptedIOException: Interrupted after 0 tries on 350.
2. For the branch 0.94:
A. lots of the logs which are Looked up root region location,
connection=org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@44285d14;
serverName=.
B. And at last, there's one exception before the master is stopped,
ServerShutdownHandler: Received exception accessing META during server
shutdown of server-XXX, retrying META read
org.apache.hadoop.hbase.client.NoServerForRegionException: Unable to find
region for after 140 tries.
We could see the master are stopped after lots of reties which are not
necessary when the cluster is shutdown.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10614) Master could not be stopped

2014-02-26 Thread Hudson (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912657#comment-13912657
]

Hudson commented on HBASE-10614:

ABORTED: Integrated in HBase-0.94-on-Hadoop-2 #32 (See
[https://builds.apache.org/job/HBase-0.94-on-Hadoop-2/32/])
HBASE-10614 Master could not be stopped (Jingcheng Du) (stack: rev 1571918)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/handler/ServerShutdownHandler.java

Master could not be stopped
---

Attachments: HBASE-10614-0.94.patch, HBASE-10614.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10077) Per family WAL encryption

2014-02-26 Thread Anoop Sam John (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912679#comment-13912679
 ] 

Anoop Sam John commented on HBASE-10077:


So one Mutation write will involve write to 2 WALs.  Atomicity for 2 WAL writes 
(?)

 Per family WAL encryption
 -

 Key: HBASE-10077
 URL: https://issues.apache.org/jira/browse/HBASE-10077
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.0
Reporter: Andrew Purtell
Assignee: Andrew Purtell

 HBASE-7544 introduces WAL encryption to prevent the leakage of protected data 
 to disk by way of WAL files. However it is currently enabled globally for the 
 regionserver. Encryption of WAL entries should depend on whether or not an 
 entry in the WAL is to be stored within an encrypted column family.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10614) Master could not be stopped

2014-02-26 Thread Hudson (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912701#comment-13912701
]

Hudson commented on HBASE-10614:

FAILURE: Integrated in HBase-0.94 #1300 (See
[https://builds.apache.org/job/HBase-0.94/1300/])
HBASE-10614 Master could not be stopped (Jingcheng Du) (stack: rev 1571918)
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/handler/ServerShutdownHandler.java

Master could not be stopped
---

Attachments: HBASE-10614-0.94.patch, HBASE-10614.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (HBASE-10617) Value lost if $ element is before column element in json when posted to Rest Server

2014-02-26 Thread Liu Shaohui (JIRA)

Liu Shaohui created HBASE-10617:
---

 Summary: Value lost if $ element is before column element in 
json when posted to Rest Server
 Key: HBASE-10617
 URL: https://issues.apache.org/jira/browse/HBASE-10617
 Project: HBase
  Issue Type: Bug
  Components: REST
Affects Versions: 0.94.11
Reporter: Liu Shaohui
Priority: Minor


When post following json data to rest server, it return 200, but the value is 
null in HBase
{code}
{Row: { key:cjI=, Cell: {$:ZGF0YTE=, column:ZjE6YzI=}}}
{code}

From rest server log, we found the length of value is null after the server 
paste the json to RowModel object
{code}
14/02/26 17:52:14 DEBUG rest.RowResource: PUT 
{totalColumns:1,families:{f1:[{timestamp:9223372036854775807,qualifier:c2,vlen:0}]},row:r2}
{code}

When the order is that column before $,  it works fine.
{code}
{Row: { key:cjI=, Cell: {column:ZjE6YzI=, $:ZGF0YTE= }}}
{code}

DIfferent json libs may have different order of this two elements even if 
column is put before $.





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (HBASE-2166) Inconsistent/wrong treatment of timestamp parameters in the old Thrift API

2014-02-26 Thread Lars Francke (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Francke reassigned HBASE-2166:
---

Assignee: (was: Lars Francke)

 Inconsistent/wrong treatment of timestamp parameters in the old Thrift API
 --

 Key: HBASE-2166
 URL: https://issues.apache.org/jira/browse/HBASE-2166
 Project: HBase
  Issue Type: Bug
  Components: Thrift
Affects Versions: 0.20.2
Reporter: Lars Francke

 The old Thrift API treats timestamps wrong/inconsistent.
 getRowTs should return a specific version or null if that doesn't exist. 
 Currently it does seem to treat the timestamp as exclusive so the row is not 
 found. Same goes for getVerTs but there it might only be a documentation 
 problem.
 I'll go through the old API and will try to find any such problems and 
 correct them in a way that is consistent with the Java API where possible.
 Peter Falk reported this on the mailing list. Thanks!



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10614) Master could not be stopped

2014-02-26 Thread Hudson (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912756#comment-13912756
]

Hudson commented on HBASE-10614:

FAILURE: Integrated in hbase-0.96 #316 (See
[https://builds.apache.org/job/hbase-0.96/316/])
HBASE-10614 Master could not be stopped (Jingcheng Du) (stack: rev 1571917)
*
/hbase/branches/0.96/hbase-client/src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java
*
/hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/master/handler/ServerShutdownHandler.java

Master could not be stopped
---

Attachments: HBASE-10614-0.94.patch, HBASE-10614.patch

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10617) Value lost if $ element is before column element in json when posted to Rest Server

2014-02-26 Thread Jean-Marc Spaggiari (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912802#comment-13912802
 ] 

Jean-Marc Spaggiari commented on HBASE-10617:
-

Hi Liu,

Going to send a patch? Or looking for someone to look at it?

 Value lost if $ element is before column element in json when posted to 
 Rest Server
 ---

 Key: HBASE-10617
 URL: https://issues.apache.org/jira/browse/HBASE-10617
 Project: HBase
  Issue Type: Bug
  Components: REST
Affects Versions: 0.94.11
Reporter: Liu Shaohui
Priority: Minor

 When post following json data to rest server, it return 200, but the value is 
 null in HBase
 {code}
 {Row: { key:cjI=, Cell: {$:ZGF0YTE=, column:ZjE6YzI=}}}
 {code}
 From rest server log, we found the length of value is null after the server 
 paste the json to RowModel object
 {code}
 14/02/26 17:52:14 DEBUG rest.RowResource: PUT 
 {totalColumns:1,families:{f1:[{timestamp:9223372036854775807,qualifier:c2,vlen:0}]},row:r2}
 {code}
 When the order is that column before $,  it works fine.
 {code}
 {Row: { key:cjI=, Cell: {column:ZjE6YzI=, $:ZGF0YTE= }}}
 {code}
 DIfferent json libs may have different order of this two elements even if 
 column is put before $.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (HBASE-8304) Bulkload fail to remove files if fs.default.name / fs.defaultFS is configured without default port.

2014-02-26 Thread haosdent (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

haosdent updated HBASE-8304:


Attachment: (was: HBASE-8304.patch)

 Bulkload fail to remove files if fs.default.name / fs.defaultFS is configured 
 without default port.
 ---

 Key: HBASE-8304
 URL: https://issues.apache.org/jira/browse/HBASE-8304
 Project: HBase
  Issue Type: Bug
  Components: HFile, regionserver
Affects Versions: 0.94.5
Reporter: Raymond Liu
  Labels: bulkloader

 When fs.default.name or fs.defaultFS in hadoop core-site.xml is configured as 
 hdfs://ip, and hbase.rootdir is configured as hdfs://ip:port/hbaserootdir 
 where port is the hdfs namenode's default port. the bulkload operation will 
 not remove the file in bulk output dir. Store::bulkLoadHfile will think 
 hdfs:://ip and hdfs:://ip:port as different filesystem and go with copy 
 approaching instead of rename.
 The root cause is that hbase master will rewrite fs.default.name/fs.defaultFS 
 according to hbase.rootdir when regionserver started, thus, dest fs uri from 
 the hregion will not matching src fs uri passed from client.
 any suggestion what is the best approaching to fix this issue? 
 I kind of think that we could check for default port if src uri come without 
 port info.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10617) Value lost if $ element is before column element in json when posted to Rest Server

2014-02-26 Thread Liu Shaohui (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912807#comment-13912807
 ] 

Liu Shaohui commented on HBASE-10617:
-

[~jmspaggi]
After visiting the HBase rest code, I think that it is JAXBContextResolver 
which unmarshals the json to the RowModel.
But i don't know how to fix it. Would someone who is familar with this code 
take a look at this issue?
Thx.

 Value lost if $ element is before column element in json when posted to 
 Rest Server
 ---

 Key: HBASE-10617
 URL: https://issues.apache.org/jira/browse/HBASE-10617
 Project: HBase
  Issue Type: Bug
  Components: REST
Affects Versions: 0.94.11
Reporter: Liu Shaohui
Priority: Minor

 When post following json data to rest server, it return 200, but the value is 
 null in HBase
 {code}
 {Row: { key:cjI=, Cell: {$:ZGF0YTE=, column:ZjE6YzI=}}}
 {code}
 From rest server log, we found the length of value is null after the server 
 paste the json to RowModel object
 {code}
 14/02/26 17:52:14 DEBUG rest.RowResource: PUT 
 {totalColumns:1,families:{f1:[{timestamp:9223372036854775807,qualifier:c2,vlen:0}]},row:r2}
 {code}
 When the order is that column before $,  it works fine.
 {code}
 {Row: { key:cjI=, Cell: {column:ZjE6YzI=, $:ZGF0YTE= }}}
 {code}
 DIfferent json libs may have different order of this two elements even if 
 column is put before $.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (HBASE-8304) Bulkload fail to remove files if fs.default.name / fs.defaultFS is configured without default port.

2014-02-26 Thread haosdent (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

haosdent updated HBASE-8304:


Attachment: HBASE-8304.patch

Fix error while compile with hadoop 1.0

 Bulkload fail to remove files if fs.default.name / fs.defaultFS is configured 
 without default port.
 ---

 Key: HBASE-8304
 URL: https://issues.apache.org/jira/browse/HBASE-8304
 Project: HBase
  Issue Type: Bug
  Components: HFile, regionserver
Affects Versions: 0.94.5
Reporter: Raymond Liu
  Labels: bulkloader
 Attachments: HBASE-8304.patch


 When fs.default.name or fs.defaultFS in hadoop core-site.xml is configured as 
 hdfs://ip, and hbase.rootdir is configured as hdfs://ip:port/hbaserootdir 
 where port is the hdfs namenode's default port. the bulkload operation will 
 not remove the file in bulk output dir. Store::bulkLoadHfile will think 
 hdfs:://ip and hdfs:://ip:port as different filesystem and go with copy 
 approaching instead of rename.
 The root cause is that hbase master will rewrite fs.default.name/fs.defaultFS 
 according to hbase.rootdir when regionserver started, thus, dest fs uri from 
 the hregion will not matching src fs uri passed from client.
 any suggestion what is the best approaching to fix this issue? 
 I kind of think that we could check for default port if src uri come without 
 port info.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10617) Value lost if $ element is before column element in json when posted to Rest Server

2014-02-26 Thread Jean-Marc Spaggiari (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912814#comment-13912814
 ] 

Jean-Marc Spaggiari commented on HBASE-10617:
-

Is this:
{code}
{Row: { key:cjI=, Cell: {$:ZGF0YTE=, column:ZjE6YzI=}}}
{code}

Related to this? :
{code}
14/02/26 17:52:14 DEBUG rest.RowResource: PUT 
{totalColumns:1,families:{f1:[{timestamp:9223372036854775807,qualifier:c2,vlen:0}]},row:r2}
{code}

Or it's from 2 different calls? Because key seems to be different between the 
2. So is qualifier.

Do you have the exact URL to send to the rest server from your client side? Can 
you capture it and past it here?

 Value lost if $ element is before column element in json when posted to 
 Rest Server
 ---

 Key: HBASE-10617
 URL: https://issues.apache.org/jira/browse/HBASE-10617
 Project: HBase
  Issue Type: Bug
  Components: REST
Affects Versions: 0.94.11
Reporter: Liu Shaohui
Priority: Minor

 When post following json data to rest server, it return 200, but the value is 
 null in HBase
 {code}
 {Row: { key:cjI=, Cell: {$:ZGF0YTE=, column:ZjE6YzI=}}}
 {code}
 From rest server log, we found the length of value is null after the server 
 paste the json to RowModel object
 {code}
 14/02/26 17:52:14 DEBUG rest.RowResource: PUT 
 {totalColumns:1,families:{f1:[{timestamp:9223372036854775807,qualifier:c2,vlen:0}]},row:r2}
 {code}
 When the order is that column before $,  it works fine.
 {code}
 {Row: { key:cjI=, Cell: {column:ZjE6YzI=, $:ZGF0YTE= }}}
 {code}
 DIfferent json libs may have different order of this two elements even if 
 column is put before $.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10617) Value lost if $ element is before column element in json when posted to Rest Server

2014-02-26 Thread Liu Shaohui (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912819#comment-13912819
 ] 

Liu Shaohui commented on HBASE-10617:
-

[~jmspaggi]
The json data is related to the log. cjI= is the  r2 base64 encode ,  and 
same for ZjE6YzI= - f1:c1,  ZGF0YTE= - data1

The test cmd is:
{code}
 curl -v -X PUT http://rest-server-ip:port/rest_test/r2/f1:c1 -H Content-Type: 
application/json --data '{Row:{key:cjI=, Cell: {$:ZGF0YTE=, 
column:ZjE6YzI=}}}'
{code}


 Value lost if $ element is before column element in json when posted to 
 Rest Server
 ---

 Key: HBASE-10617
 URL: https://issues.apache.org/jira/browse/HBASE-10617
 Project: HBase
  Issue Type: Bug
  Components: REST
Affects Versions: 0.94.11
Reporter: Liu Shaohui
Priority: Minor

 When post following json data to rest server, it return 200, but the value is 
 null in HBase
 {code}
 {Row: { key:cjI=, Cell: {$:ZGF0YTE=, column:ZjE6YzI=}}}
 {code}
 From rest server log, we found the length of value is null after the server 
 paste the json to RowModel object
 {code}
 14/02/26 17:52:14 DEBUG rest.RowResource: PUT 
 {totalColumns:1,families:{f1:[{timestamp:9223372036854775807,qualifier:c2,vlen:0}]},row:r2}
 {code}
 When the order is that column before $,  it works fine.
 {code}
 {Row: { key:cjI=, Cell: {column:ZjE6YzI=, $:ZGF0YTE= }}}
 {code}
 DIfferent json libs may have different order of this two elements even if 
 column is put before $.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (HBASE-10617) Value lost if $ element is before column element in json when posted to Rest Server

2014-02-26 Thread Liu Shaohui (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912822#comment-13912822
 ] 

Liu Shaohui commented on HBASE-10617:
-

[~jmspaggi]
A typo.
{code}
 curl -v -X PUT http://rest-server-ip:port/t1/r2/f1:c1 -H Content-Type: 
application/json --data '{Row:{key:cjI=, Cell: {$:ZGF0YTE=, 
column:ZjE6YzI=}}}'
{code}

 Value lost if $ element is before column element in json when posted to 
 Rest Server
 ---

 Key: HBASE-10617
 URL: https://issues.apache.org/jira/browse/HBASE-10617
 Project: HBase
  Issue Type: Bug
  Components: REST
Affects Versions: 0.94.11
Reporter: Liu Shaohui
Priority: Minor

 When post following json data to rest server, it return 200, but the value is 
 null in HBase
 {code}
 {Row: { key:cjI=, Cell: {$:ZGF0YTE=, column:ZjE6YzI=}}}
 {code}
 From rest server log, we found the length of value is null after the server 
 paste the json to RowModel object
 {code}
 14/02/26 17:52:14 DEBUG rest.RowResource: PUT 
 {totalColumns:1,families:{f1:[{timestamp:9223372036854775807,qualifier:c2,vlen:0}]},row:r2}
 {code}
 When the order is that column before $,  it works fine.
 {code}
 {Row: { key:cjI=, Cell: {column:ZjE6YzI=, $:ZGF0YTE= }}}
 {code}
 DIfferent json libs may have different order of this two elements even if 
 column is put before $.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

1 2 3 >

1 - 100 of 256 matches

Mail list logo