[jira] [Created] (HBASE-13073) refactor mutation's familyMap in case of multi mutation on same column
hongyu bi created HBASE-13073: - Summary: refactor mutation's familyMap in case of multi mutation on same column Key: HBASE-13073 URL: https://issues.apache.org/jira/browse/HBASE-13073 Project: HBase Issue Type: Bug Components: Client Reporter: hongyu bi Assignee: hongyu bi per HBASE-12948 it's found that we can do multi mutations on the same column for mutation object ,which will make no sense(even produce wrong results before HBASE-12948) but put more traffic to RS.So we want to refactor mutation's familyMap in case of multi mutation on same column . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12988) [Replication]Parallel apply edits on table-level
hongyu bi created HBASE-12988: - Summary: [Replication]Parallel apply edits on table-level Key: HBASE-12988 URL: https://issues.apache.org/jira/browse/HBASE-12988 Project: HBase Issue Type: Improvement Reporter: hongyu bi Assignee: hongyu bi we can apply edits to slave cluster in parallel on table-level to speed up replication . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12977) normalize handlerCount to keep handlers distributed evenly among callQueues
hongyu bi created HBASE-12977: - Summary: normalize handlerCount to keep handlers distributed evenly among callQueues Key: HBASE-12977 URL: https://issues.apache.org/jira/browse/HBASE-12977 Project: HBase Issue Type: Improvement Reporter: hongyu bi Assignee: hongyu bi Priority: Minor If enable multi callQueues , handlers may not be distributed evenly among multi queues, which mean the queue's capacity is not the same. Should we make handler's distribution even? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12968) SecureServer should not ignore CallQueueSize
hongyu bi created HBASE-12968: - Summary: SecureServer should not ignore CallQueueSize Key: HBASE-12968 URL: https://issues.apache.org/jira/browse/HBASE-12968 Project: HBase Issue Type: Bug Affects Versions: 0.94.15 Reporter: hongyu bi Assignee: hongyu bi Per HBASE-5190 HBaseServer will reject the request If callQueueSize exceed "ipc.server.max.callqueue.length", but SecureServer ignore this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12957) region_mover#isSuccessfulScan may extremely slow on region with lots of expired data
hongyu bi created HBASE-12957: - Summary: region_mover#isSuccessfulScan may extremely slow on region with lots of expired data Key: HBASE-12957 URL: https://issues.apache.org/jira/browse/HBASE-12957 Project: HBase Issue Type: Improvement Components: scripts Reporter: hongyu bi Priority: Minor region_mover will call isSuccessfulScan when region has moved to make sure it's healthy, however , if the moved region has lots of expired data region_mover#isSuccessfulScan will take a long time to finish ,that may even exceed "lease timeout".So I made isSuccessfulScan a get-like scan to achieve faster response in that case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-12948) Increment#addColumn on the same column multi times produce wrong result
hongyu bi created HBASE-12948:
-
Summary: Increment#addColumn on the same column multi times
produce wrong result
Key: HBASE-12948
URL: https://issues.apache.org/jira/browse/HBASE-12948
Project: HBase
Issue Type: Bug
Components: Client, regionserver
Reporter: hongyu bi
Priority: Critical
Case:
Initially get('row1'):
rowkey=row1 value=1
run:
Increment increment = new Increment(Bytes.toBytes("row1"));
for (int i = 0; i < N; i++) {
increment.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("c"), 1)
}
hobi.increment(increment);
get('row1'):
if N=1 then result is 2 else if N>1 the result will always be 1
Cause:
https://issues.apache.org/jira/browse/HBASE-7114 let increment extent mutation
which change familyMap from NavigableMap to List, so from client side, we can
buffer many edits on the same column；
However, HRegion#increment use idx to iterate the get's results, here
results.size1，so the latter edits on the same column
won't match the condition {idx < results.size() &&
CellUtil.matchingQualifier(results.get(idx), kv) }, meantime the edits share
the same mvccVersion ,so this case happen.
Fix:
according to the put/delete#add on the same column behaviour ,
fix from server side: process "last edit wins on the same column" inside
HRegion#increment to maintenance HBASE-7114's extension and keep the same
result from 0.94.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-12649) [0.94] port HBASE-11705 callQueueSize should be decremented in a fail-fast scenario
hongyu bi created HBASE-12649: - Summary: [0.94] port HBASE-11705 callQueueSize should be decremented in a fail-fast scenario Key: HBASE-12649 URL: https://issues.apache.org/jira/browse/HBASE-12649 Project: HBase Issue Type: Bug Components: IPC/RPC Reporter: hongyu bi Refer to https://issues.apache.org/jira/browse/HBASE-11705 which may lead to "callQueueSize leak" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-11769) Truncate table shouldn't revoke user privileges
hongyu bi created HBASE-11769: - Summary: Truncate table shouldn't revoke user privileges Key: HBASE-11769 URL: https://issues.apache.org/jira/browse/HBASE-11769 Project: HBase Issue Type: Bug Components: security Affects Versions: 0.94.15 Reporter: hongyu bi hbase(main):002:0> create 'a','cf' 0 row(s) in 0.2500 seconds => Hbase::Table - a hbase(main):003:0> grant 'usera','R','a' 0 row(s) in 0.2080 seconds hbase(main):007:0> user_permission 'a' User Table,Family,Qualifier:Permission usera a,,: [Permission: actions=READ] hbase(main):004:0> truncate 'a' Truncating 'a' table (it may take a while): - Disabling table... - Dropping table... - Creating table... 0 row(s) in 1.5320 seconds hbase(main):005:0> user_permission 'a' User Table,Family,Qualifier:Permission -- This message was sent by Atlassian JIRA (v6.2#6252)
