[jira] [Commented] (HBASE-6528) Raise the wait time for TestSplitLogWorker#testAcquireTaskAtStartup to reduce the failure probability

[ https://issues.apache.org/jira/browse/HBASE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454784#comment-13454784 ] ShiXing commented on HBASE-6528: [~lhofhansl] this test case was introduced when I fix

[jira] [Commented] (HBASE-6589) RegionServer can't load class for dynamically loaded coprocessors with self defined class

[ https://issues.apache.org/jira/browse/HBASE-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13437680#comment-13437680 ] ShiXing commented on HBASE-6589: It is when I try to invoke the CP. Because the

[jira] [Created] (HBASE-6589) RegionServer can't load class for dynamically loaded coprocessors with self defined class

ShiXing created HBASE-6589: -- Summary: RegionServer can't load class for dynamically loaded coprocessors with self defined class Key: HBASE-6589 URL: https://issues.apache.org/jira/browse/HBASE-6589 Project:

[jira] [Updated] (HBASE-6520) MSLab May cause the Bytes.toLong not work correctly for increment

[ https://issues.apache.org/jira/browse/HBASE-6520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6520: --- Attachment: HBASE-6520-0.94-v1.patch patch for 0.94 MSLab May cause the Bytes.toLong not

[jira] [Updated] (HBASE-6520) MSLab May cause the Bytes.toLong does not work correctly for increment

[ https://issues.apache.org/jira/browse/HBASE-6520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6520: --- Attachment: HBASE-6520-trunk-v1.patch MSLab May cause the Bytes.toLong does not work correctly for

[jira] [Commented] (HBASE-6520) MSLab May cause the Bytes.toLong does not work correctly for increment

[ https://issues.apache.org/jira/browse/HBASE-6520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13430418#comment-13430418 ] ShiXing commented on HBASE-6520: bq. -1 core tests. The patch failed these unit tests:

[jira] [Created] (HBASE-6528) Raise the wait time for TestSplitLogWorker#testAcquireTaskAtStartup to reduce the failure probability

ShiXing created HBASE-6528: -- Summary: Raise the wait time for TestSplitLogWorker#testAcquireTaskAtStartup to reduce the failure probability Key: HBASE-6528 URL: https://issues.apache.org/jira/browse/HBASE-6528

[jira] [Updated] (HBASE-6528) Raise the wait time for TestSplitLogWorker#testAcquireTaskAtStartup to reduce the failure probability

[ https://issues.apache.org/jira/browse/HBASE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6528: --- Attachment: HBASE-6528-trunk-v1.patch Raise the wait time for

[jira] [Created] (HBASE-6520) MSLab May cause the Bytes.toLong does not work correctly for increment

ShiXing created HBASE-6520: -- Summary: MSLab May cause the Bytes.toLong does not work correctly for increment Key: HBASE-6520 URL: https://issues.apache.org/jira/browse/HBASE-6520 Project: HBase

[jira] [Updated] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-3725: --- Attachment: HBASE-3725-0.92-V6.patch toTed bq. TestHRegion#testIncrementWithFlushAndDelete passed without

[jira] [Commented] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418892#comment-13418892 ] ShiXing commented on HBASE-3725: @Ted bq. I generate a region with 3 store files. The

[jira] [Commented] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418933#comment-13418933 ] ShiXing commented on HBASE-3725: @Ted, the reassignment is because there is no interface

[jira] [Commented] (HBASE-6327) HLog can be null when create table

[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13417989#comment-13417989 ] ShiXing commented on HBASE-6327: @Ted, what is this issue's progress now? Can we commit

[jira] [Updated] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-3725: --- Attachment: HBASE-3725-0.92-V5.patch @stack, I generate a region with 3 store files. The increment slows

[jira] [Commented] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418032#comment-13418032 ] ShiXing commented on HBASE-3725: In V5, if the increment does not got the data it will got

[jira] [Commented] (HBASE-6327) HLog can be null when create table

[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418037#comment-13418037 ] ShiXing commented on HBASE-6327: In deed, when create table, the hlog is no use

[jira] [Updated] (HBASE-6370) Add compression codec test at HMaster when createTable/modifyColumn/modifyTable

[ https://issues.apache.org/jira/browse/HBASE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6370: --- Attachment: HBASE-6370-trunk-V2.patch Yes, I think the configuration is more acceptable for heterogeneous

[jira] [Updated] (HBASE-6370) Add compression codec test at HMaster when createTable/modifyColumn/modifyTable

[ https://issues.apache.org/jira/browse/HBASE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6370: --- Attachment: runAllTests.out The v3 looks nice, runAllTests passed on my server. Add

[jira] [Updated] (HBASE-6370) Add compression codec test at HMaster when createTable/modifyColumn/modifyTable

[ https://issues.apache.org/jira/browse/HBASE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6370: --- Summary: Add compression codec test at HMaster when createTable/modifyColumn/modifyTable (was: Add

[jira] [Updated] (HBASE-6370) Add compression codec test at HMaster when createTable/modifyColumn/modifyTable

[ https://issues.apache.org/jira/browse/HBASE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6370: --- Attachment: HBASE-6370-trunk-V1.patch Use the already exists unit test through the HBaseAdmin's.

[jira] [Created] (HBASE-6370) Add compression codec test at HMaster when create table

ShiXing created HBASE-6370: -- Summary: Add compression codec test at HMaster when create table Key: HBASE-6370 URL: https://issues.apache.org/jira/browse/HBASE-6370 Project: HBase Issue Type:

[jira] [Commented] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409205#comment-13409205 ] ShiXing commented on HBASE-3725: The trunk does not have this bug, for the

[jira] [Commented] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409213#comment-13409213 ] ShiXing commented on HBASE-3725: Mean the performance is important than the correctness?

[jira] [Updated] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-3725: --- Attachment: HBASE-3725-0.92-V4.patch pls review it. HBase increments from old value after

[jira] [Commented] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406928#comment-13406928 ] ShiXing commented on HBASE-3725: bq.Is this a fix for 0.92 only ShiXing? yes bq.Doing a

[jira] [Commented] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406929#comment-13406929 ] ShiXing commented on HBASE-3725: bq. But the correctness is affected. I mean the 0.92

[jira] [Commented] (HBASE-6327) HLog can be null when create table

[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406948#comment-13406948 ] ShiXing commented on HBASE-6327: @Ted Not yet, I have commit this patch into our code,

[jira] [Commented] (HBASE-6327) HLog can be null when create table

[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407687#comment-13407687 ] ShiXing commented on HBASE-6327: TestServerCustomProtocol passed locally for me.

[jira] [Commented] (HBASE-6327) HLog can be null when create table

[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407688#comment-13407688 ] ShiXing commented on HBASE-6327: Maybe the thread leak is normal, because the

[jira] [Created] (HBASE-6327) HLog can be null when create table

ShiXing created HBASE-6327: -- Summary: HLog can be null when create table Key: HBASE-6327 URL: https://issues.apache.org/jira/browse/HBASE-6327 Project: HBase Issue Type: Bug Reporter:

[jira] [Updated] (HBASE-6327) HLog can be null when create table

[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6327: --- Attachment: createTableFailedMaster.log HLog can be null when create table

[jira] [Updated] (HBASE-6327) HLog can be null when create table

[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6327: --- Description: As HBASE-4010 discussed, the HLog can be null. We have meet createTable failed because the no

[jira] [Updated] (HBASE-6327) HLog can be null when create table

[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6327: --- Attachment: HBASE-6327-trunk-V1.patch The trunk code of the HLog.sync() use group sync, the interruption as

[jira] [Commented] (HBASE-6292) Compact can skip the security access control

[ https://issues.apache.org/jira/browse/HBASE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404667#comment-13404667 ] ShiXing commented on HBASE-6292: @Andrew, I see the ACL Matrix in HBASE-6192 {code}

[jira] [Updated] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-3725: --- Attachment: HBASE-3725-0.92-V3.patch If the Delete and next Increment occured the same millionsecond, the

[jira] [Created] (HBASE-6292) Compact can skip the security access control

ShiXing created HBASE-6292: -- Summary: Compact can skip the security access control Key: HBASE-6292 URL: https://issues.apache.org/jira/browse/HBASE-6292 Project: HBase Issue Type: Bug

[jira] [Commented] (HBASE-6195) Increment data will be lost when the memstore is flushed

[ https://issues.apache.org/jira/browse/HBASE-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403811#comment-13403811 ] ShiXing commented on HBASE-6195: yes, I think so. Increment data will be

[jira] [Updated] (HBASE-6292) Compact can skip the security access control

[ https://issues.apache.org/jira/browse/HBASE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6292: --- Attachment: HBASE-6292-trunk-V1.patch Patch for trunk If this patch can be commited, then the patches for

[jira] [Commented] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403165#comment-13403165 ] ShiXing commented on HBASE-3725: Is there any progress? HBase increments

[jira] [Commented] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403170#comment-13403170 ] ShiXing commented on HBASE-3725: Sorry for mistake of Ctrl+Enter. I think the fixup could

[jira] [Updated] (HBASE-3725) HBase increments from old value after delete and write to disk

[ https://issues.apache.org/jira/browse/HBASE-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-3725: --- Attachment: HBASE-3725-0.92-V1.patch remove the getLastIncrement function. HBase

[jira] [Updated] (HBASE-6269) Lazyseek should use the maxSequenseId StoreFile's KeyValue as the latest KeyValue

[ https://issues.apache.org/jira/browse/HBASE-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6269: --- Attachment: runAllTests.out.txt I run mvn test -P runAllTests and the output is in the runAllTests.out.txt

[jira] [Created] (HBASE-6269) Lazyseek should use the maxSequenseId StoreFile's KeyValue as the latest KeyValue

ShiXing created HBASE-6269: -- Summary: Lazyseek should use the maxSequenseId StoreFile's KeyValue as the latest KeyValue Key: HBASE-6269 URL: https://issues.apache.org/jira/browse/HBASE-6269 Project: HBase

[jira] [Updated] (HBASE-6269) Lazyseek should use the maxSequenseId StoreFile's KeyValue as the latest KeyValue

[ https://issues.apache.org/jira/browse/HBASE-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6269: --- Attachment: HBASE-6269-v1.patch Lazyseek should use the maxSequenseId StoreFile's KeyValue as the

[jira] [Commented] (HBASE-6195) Increment data will be lost when the memstore is flushed

[ https://issues.apache.org/jira/browse/HBASE-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13401267#comment-13401267 ] ShiXing commented on HBASE-6195: I find that the problem is introduced by the lazyseek. I

[jira] [Commented] (HBASE-6269) Lazyseek should use the maxSequenseId StoreFile's KeyValue as the latest KeyValue

[ https://issues.apache.org/jira/browse/HBASE-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13401383#comment-13401383 ] ShiXing commented on HBASE-6269: @anoop There are 2 StoreFiles after flush two times, the

[jira] [Updated] (HBASE-6269) Lazyseek should use the maxSequenseId StoreFile's KeyValue as the latest KeyValue

[ https://issues.apache.org/jira/browse/HBASE-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ShiXing updated HBASE-6269: --- Attachment: HBASE-6269-trunk-V1.patch Lazyseek should use the maxSequenseId StoreFile's KeyValue as the