[jira] [Created] (HBASE-11817) HTable.batch() loses operations when region is splited

2014-08-25 Thread t samkawa (JIRA)
t samkawa created HBASE-11817:
-

 Summary: HTable.batch() loses operations when region is splited
 Key: HBASE-11817
 URL: https://issues.apache.org/jira/browse/HBASE-11817
 Project: HBase
  Issue Type: Bug
  Components: Admin, Client
Affects Versions: 0.98.4
 Environment: 0.98.4+hadoop 2.4.1, 0.98.4 stand-alone, jdk1.6
Reporter: t samkawa


Using HTable.batch() often loses increment operation when region split ran.

Test code snpipet is below; 
Running this 2 code blocks concurrently, different values were often recoreded 
although all value should be same 0x.

// --- code 1 ---
HTable table = new HTable(CONF);
byte[] rowKey = new byte[1];
for (int i=0;i0x;i++){
 ArrayListIncrement operations = new ArrayListIncrement();
 for (byte c1 = (byte)'A'; c1=(byte)'Z'; c1++) {
   rowKey[0] = c1;
   Increment opIncr = new Increment(rowKey);
   opIncr.addColumn(FAM, HConstants.EMPTY_BYTE_ARRAY, 1);
   operations.add(opIncr);
 }
 table.batch(operations, null);
}

// -- code2 --
HBaseAdmin admin = new HBaseAdmin(CONF);
byte[] rowKey = new byte[1];
for (byte c1 = (byte)'A'; c1=(byte)'Z'; c1++) {
 try { Thread.sleep(2000L); } catch (InterruptedException iex) {}
 rowKey[0] = c1;
 admin.split(TABLE_NAME, rowKey);
}
/

Using table.increment() instead of table.batch() works fine. But that change 
gets slower . 



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


[jira] [Commented] (HBASE-11817) HTable.batch() loses operations when region is splited

2014-08-25 Thread t samkawa (JIRA)

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

t samkawa commented on HBASE-11817:
---

Thanks.

This is my result:

{code}
scan 'test12345', COLUMNS='cf::toHex'
ROWCOLUMN+CELL  
   
 Acolumn=cf:, timestamp=1408960922305, value=
 Bcolumn=cf:, timestamp=1408960830519, value=c1
 Ccolumn=cf:, timestamp=1408960830493, value=c0
 Dcolumn=cf:, timestamp=1408960830493, value=c0
 Ecolumn=cf:, timestamp=1408960830499, value=c0
 Fcolumn=cf:, timestamp=1408960830499, value=c0
 Gcolumn=cf:, timestamp=1408960830500, value=c0
 Hcolumn=cf:, timestamp=1408960830501, value=bf
 Icolumn=cf:, timestamp=1408960830501, value=bf
 Jcolumn=cf:, timestamp=1408960830502, value=bf
 Kcolumn=cf:, timestamp=1408960830502, value=bf
 Lcolumn=cf:, timestamp=1408960830503, value=bf
 Mcolumn=cf:, timestamp=1408960830504, value=bf
 Ncolumn=cf:, timestamp=1408960830504, value=bf
 Ocolumn=cf:, timestamp=1408960830505, value=bf
 Pcolumn=cf:, timestamp=1408960830506, value=bf
 Qcolumn=cf:, timestamp=1408960830507, value=bf
 Rcolumn=cf:, timestamp=1408960830507, value=be
 Scolumn=cf:, timestamp=1408960830508, value=be
 Tcolumn=cf:, timestamp=1408960830509, value=be
 Ucolumn=cf:, timestamp=1408960830510, value=be
 Vcolumn=cf:, timestamp=1408960830510, value=be
 Wcolumn=cf:, timestamp=1408960830511, value=be
 Xcolumn=cf:, timestamp=1408960830512, value=be
 Ycolumn=cf:, timestamp=1408960830512, value=be
 Zcolumn=cf:, timestamp=1408960830513, value=be
{code}

Actually, this is just a test code, to reproduce easily.
This unexpected result occures even only 2 rows.


 HTable.batch() loses operations when region is splited
 --

 Key: HBASE-11817
 URL: https://issues.apache.org/jira/browse/HBASE-11817
 Project: HBase
  Issue Type: Bug
  Components: Admin, Client
Affects Versions: 0.98.4
 Environment: 0.98.4+hadoop 2.4.1, 0.98.4 stand-alone, jdk1.6
Reporter: t samkawa

 Using HTable.batch() often loses increment operation when region split ran.
 Test code snpipet is below; 
 Running this 2 code blocks concurrently, different values were often 
 recoreded although all value should be same 0x.
 {code}
 // --- code 1 ---
 HTable table = new HTable(CONF);
 byte[] rowKey = new byte[1];
 for (int i=0;i0x;i++){
  ArrayListIncrement operations = new ArrayListIncrement();
  for (byte c1 = (byte)'A'; c1=(byte)'Z'; c1++) {
rowKey[0] = c1;
Increment opIncr = new Increment(rowKey);
opIncr.addColumn(FAM, HConstants.EMPTY_BYTE_ARRAY, 1);
operations.add(opIncr);
  }
  table.batch(operations, null);
 }
 // -- code2 --
 HBaseAdmin admin = new HBaseAdmin(CONF);
 byte[] rowKey = new byte[1];
 for (byte c1 = (byte)'A'; c1=(byte)'Z'; c1++) {
  try { Thread.sleep(2000L); } catch (InterruptedException iex) {}
  rowKey[0] = c1;
  admin.split(TABLE_NAME, rowKey);
 }
 /
 {code}
 Using table.increment() instead of table.batch() works fine. But that change 
 gets slower . 



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


[jira] [Created] (HBASE-11676) Scan FORMATTER is not applied for columns using non-printable name in shell

2014-08-05 Thread t samkawa (JIRA)
t samkawa created HBASE-11676:
-

 Summary: Scan FORMATTER is not applied for columns using 
non-printable name in shell 
 Key: HBASE-11676
 URL: https://issues.apache.org/jira/browse/HBASE-11676
 Project: HBase
  Issue Type: Bug
  Components: shell
 Environment: 0.98 + hadoop2.2.0
Reporter: t samkawa
Priority: Minor


The FORMATTER does not work if the target cell`s column uses binary name.

 hbase create test1, f
 hbase incr test1, row1 , f:a, 1
 hbase incr test1, row1 , f:\x11, 1
 hbase scan test1, COLUMNS=[f:\x11:toLong,f:a:toLong]
ROW   COLUMN+CELL
 row1column=f:\x11, ..., value=\x00\x00\x00\x00\x00\x00\x00\x01
 row1column=f:a, ..., value=1




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