[jira] [Created] (HBASE-17815) Remove the unused field in PrefixTreeSeeker
Chia-Ping Tsai created HBASE-17815: -- Summary: Remove the unused field in PrefixTreeSeeker Key: HBASE-17815 URL: https://issues.apache.org/jira/browse/HBASE-17815 Project: HBase Issue Type: Improvement Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Priority: Trivial The "block" is never used due to HBASE-12298. We should remove it to stop the noise from FindBugs. (see HBASE-17664 and HBASE-17809) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17836) CellUtil#estimatedSerializedSizeOf is slow when input is ByteBufferCell
Chia-Ping Tsai created HBASE-17836: -- Summary: CellUtil#estimatedSerializedSizeOf is slow when input is ByteBufferCell Key: HBASE-17836 URL: https://issues.apache.org/jira/browse/HBASE-17836 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Chia-Ping Tsai Priority: Minor Fix For: 2.0.0 We call CellUtil#estimatedSerializedSize to calculate the size of rows when scanning. If the input is ByteBufferCell, the CellUtil#estimatedSerializedSizeOf parses many length components to get the qualifierLength stored in the backing buffer. We should consider using the KeyValueUtil#getSerializedSize. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17859) ByteBufferUtils#compareTo is wrong
Chia-Ping Tsai created HBASE-17859:
--
Summary: ByteBufferUtils#compareTo is wrong
Key: HBASE-17859
URL: https://issues.apache.org/jira/browse/HBASE-17859
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Fix For: 2.0.0
buf2.get( i ) & 0xFF; -> buf2.get(j) & 0xFF;
{noformat}
public static int compareTo(byte [] buf1, int o1, int l1, ByteBuffer buf2,
int o2, int l2) {
//
int end1 = o1 + l1;
int end2 = o2 + l2;
for (int i = o1, j = o2; i < end1 && j < end2; i++, j++) {
int a = buf1[i] & 0xFF;
int b = buf2.get(i) & 0xFF;
if (a != b) {
return a - b;
}
}
return l1 - l2;
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17821) The CompoundConfiguration#toString is wrong
Chia-Ping Tsai created HBASE-17821:
--
Summary: The CompoundConfiguration#toString is wrong
Key: HBASE-17821
URL: https://issues.apache.org/jira/browse/HBASE-17821
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Priority: Trivial
Find this bug when reading code. We dont use the API, so it is a trivial bug.
sb.append(this.configs); -> sb.append(m);
{noformat}
@Override
public String toString() {
StringBuffer sb = new StringBuffer();
sb.append("CompoundConfiguration: " + this.configs.size() + " configs");
for (ImmutableConfigMap m : this.configs) {
sb.append(this.configs);
}
return sb.toString();
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17803) PE always re-creates table when we specify the split policy
Chia-Ping Tsai created HBASE-17803:
--
Summary: PE always re-creates table when we specify the split
policy
Key: HBASE-17803
URL: https://issues.apache.org/jira/browse/HBASE-17803
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0, 1.4.0
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Priority: Minor
Fix For: 2.0.0, 1.4.0
I find this bug when i run the tests for HBASE-17623
The critical code is shown below.
{noformat}
if ((exists && opts.presplitRegions != DEFAULT_OPTS.presplitRegions)
|| (!isReadCmd && desc != null && desc.getRegionSplitPolicyClassName() !=
opts.splitPolicy)
|| (!isReadCmd && desc != null && desc.getRegionReplication() !=
opts.replicas)) {
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17805) We should remove BoundedByteBufferPool because it is replaced by ByteBufferPool
Chia-Ping Tsai created HBASE-17805: -- Summary: We should remove BoundedByteBufferPool because it is replaced by ByteBufferPool Key: HBASE-17805 URL: https://issues.apache.org/jira/browse/HBASE-17805 Project: HBase Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Chia-Ping Tsai Priority: Minor Fix For: 2.0.0 Follow the discussion in HBASE-15525. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17809) cleanup unused class
Chia-Ping Tsai created HBASE-17809: -- Summary: cleanup unused class Key: HBASE-17809 URL: https://issues.apache.org/jira/browse/HBASE-17809 Project: HBase Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Fix For: 2.0.0 inspired by HBASE-17805. We had left a lot of orphan class due to a bunch of commits. We shall remove them. ||class||last meeting||why||line count| |LruHashMap|HBASE-1822|get rid of|1100| |ScannerTimeoutException|HBASE-16266|get rid of|45| |SortedCopyOnWriteSet|HBASE-12748|get rid of|178| |TestSortedCopyOnWriteSet|HBASE-12748|get rid of|107| |DelegatingRetryingCallable|HBASE-9049|create but never used|65| |LockTimeoutException|HBASE-16786|get rid of|44| |OperationConflictException|HBASE-9899|get rid of|50| |InvalidQuotaSettingsException|HBASE-11598|create but never used|33| |ShareableMemory|HBASE-15735|get rid of|40| |BoundedArrayQueue|HBASE-14860|get rid of|82| |TestBoundedArrayQueue|HBASE-14860|get rid of|61| |ChecksumFactory|HBASE-11927|get rid of|100| |TokenDepthComparator|HBASE-4676|create but never used|65| |RegionMergeTransaction|HBASE-17470|get rid of|249| |MetaUtils|HBASE-1822|get rid of|156| -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (HBASE-17758) [RSGROUP] Add shell command to move servers and tables at the same time
[
https://issues.apache.org/jira/browse/HBASE-17758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai reopened HBASE-17758:
move_servers_tables_rsgroup.rb disappeared
[~apurtell] Would you please check it? Thanks.
> [RSGROUP] Add shell command to move servers and tables at the same time
> ---
>
> Key: HBASE-17758
> URL: https://issues.apache.org/jira/browse/HBASE-17758
> Project: HBase
> Issue Type: New Feature
> Components: rsgroup
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17758-v1.patch, HBASE-17758-v2.patch,
> HBASE-17758-v3.patch, HBASE-17758-v4.patch, HBASE-17758-v5.patch
>
>
> Currently add a new group perform the following steps:
> {code:javascript}
> hbase(main):001:0> add_rsgroup 'mygroup'
> Took 0.3840 seconds
> hbase(main):002:0> move_servers_rsgroup
> 'mygroup',['hbase-rs-01:16030','hbase-rs-02:16030']
> Took 3.5040 seconds
> hbase(main):003:0> move_tables_rsgroup 'mygroup',['example']
> Took 0.2710 seconds
> {code}
> 1. move_servers_rsgroup will unassign all regions on hbase-rs-01 and
> hbase-rs-02
> 2. move_tables_rsgroup will also reassign all the regions of the table
> example.
> This will lead to a large number of regions to migrate and affect the data
> locality.
> However, some regions of the table that are distributed on hbase-rs-01 and
> hbase-rs-02, do not need to be moved.
> So,we need a new shell command *move_servers_tables_rsgroup* which minimizes
> the number of regions needed to move.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17896) The FIXED_OVERHEAD of Segment is incorrect
Chia-Ping Tsai created HBASE-17896:
--
Summary: The FIXED_OVERHEAD of Segment is incorrect
Key: HBASE-17896
URL: https://issues.apache.org/jira/browse/HBASE-17896
Project: HBase
Issue Type: Sub-task
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Priority: Minor
{noformat}
5 * ClassSize.REFERENCE // cellSet, comparator, memStoreLAB, size,
timeRangeTracker
{noformat}
In fact, the Segment has 6 references.
# cellSet
# comparator
# memStoreLAB
# dataSize
# heapSize
# timeRangeTracker
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17895) TestAsyncProcess#testAction fails if unsafe support is false
Chia-Ping Tsai created HBASE-17895:
--
Summary: TestAsyncProcess#testAction fails if unsafe support is
false
Key: HBASE-17895
URL: https://issues.apache.org/jira/browse/HBASE-17895
Project: HBase
Issue Type: Sub-task
Components: test
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Fix For: 2.0.0
{noformat}
assertEquals(-1, action_0.compareTo(action_1));
assertEquals(1, action_1.compareTo(action_0));
{noformat}
The correction is shown below.
{noformat}
assertTrue(action_0.compareTo(action_1) < 0);
assertTrue(action_1.compareTo(action_0) > 0);
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-7292) HTablePool class description javadoc is unclear
[ https://issues.apache.org/jira/browse/HBASE-7292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-7292. --- Resolution: Won't Fix HTablePool had been removed in 0.98.1, so this jira should be closed. > HTablePool class description javadoc is unclear > --- > > Key: HBASE-7292 > URL: https://issues.apache.org/jira/browse/HBASE-7292 > Project: HBase > Issue Type: Improvement >Reporter: Gabriel Reid >Priority: Minor > Attachments: HBASE-7292.patch > > > The class description javadoc for HTablePool contains a sentence that makes > no sense in the context (it appears to be part of an incorrectly-applied > patch from the past). The sentence references the correct way of returning > HTables to the pool, but it actually makes it more difficult to understand > what the correct way of returning tables to the pool actually is. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17903) The alias for the link of HBASE-6580 is incorrect
Chia-Ping Tsai created HBASE-17903:
--
Summary: The alias for the link of HBASE-6580 is incorrect
Key: HBASE-17903
URL: https://issues.apache.org/jira/browse/HBASE-17903
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Priority: Trivial
{noformat}
Previous versions of this guide discussed `HTablePool`, which was deprecated in
HBase 0.94, 0.95, and 0.96, and removed in 0.98.1, by
link:https://issues.apache.org/jira/browse/HBASE-6580[HBASE-6500], or
`HConnection`, which is deprecated in HBase 1.0 by `Connection`.
Please use
link:http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Connection.html[Connection]
instead.
{noformat}
6500 -> 6580
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17872) Make ByteBufferUtils thread-safe
Chia-Ping Tsai created HBASE-17872:
--
Summary: Make ByteBufferUtils thread-safe
Key: HBASE-17872
URL: https://issues.apache.org/jira/browse/HBASE-17872
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Priority: Critical
A case is shown below.
We will get the wrong position of buffer in multithreaded environment, so the
method makes the invalid cell in MSLAB.
{noformat}
public static int copyFromBufferToBuffer(ByteBuffer in, ByteBuffer out, int
sourceOffset,
int destinationOffset, int length) {
if (in.hasArray() && out.hasArray()) {
// ...
} else if (UNSAFE_AVAIL) {
// ...
} else {
int outOldPos = out.position();
out.position(destinationOffset);
ByteBuffer inDup = in.duplicate();
inDup.position(sourceOffset).limit(sourceOffset + length);
out.put(inDup);
out.position(outOldPos);
}
return destinationOffset + length;
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-7326) SortedCopyOnWriteSet is not thread safe due to leaked TreeSet implementations
[ https://issues.apache.org/jira/browse/HBASE-7326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-7326. --- Resolution: Duplicate > SortedCopyOnWriteSet is not thread safe due to leaked TreeSet implementations > - > > Key: HBASE-7326 > URL: https://issues.apache.org/jira/browse/HBASE-7326 > Project: HBase > Issue Type: Bug > Components: util >Reporter: Gary Helmling > Fix For: 2.0.0 > > > The SortedCopyOnWriteSet implementation uses an internal TreeSet that is > copied and replaced on mutation operations. However, in a few areas, > SortedCopyOnWriteSet leaks references to the underlying TreeSet > implementations, allowing for unsafe usage: > * iterator() > * subSet() > * headSet() > * tailSet() > For Iterator.remove(), we can wrap in an implementation that throws > UnsupportedOperationException. For the sub set methods, we could return new > SortedCopyOnWriteSet instances (which would not modify the parent set), or > wrap with a new sub set implementation that safely allows modification of the > parent set. > To be clear, the current usage of SortedCopyOnWriteSet does not make use of > any of these non-thread-safe methods, but the implementation should be fixed > to be completely thread safe and prevent any new issues. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-8220) can we record the count opened HTable for HTablePool
[ https://issues.apache.org/jira/browse/HBASE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-8220. --- Resolution: Won't Fix > can we record the count opened HTable for HTablePool > > > Key: HBASE-8220 > URL: https://issues.apache.org/jira/browse/HBASE-8220 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Jianwei Cui > Attachments: 8220-trunk-v1.txt, 8220-trunk-v2.txt, > 8220-trunk-v3-reattached.txt, 8220-trunk-v3.txt, 8220-trunk-v4.txt, > HBASE-8220-0.94.3.txt, HBASE-8220-0.94.3.txt, HBASE-8220-0.94.3.txt-v2, > HBASE-8220-0.94.3-v2.txt, HBASE-8220-0.94.3-v3.txt, HBASE-8220-0.94.3-v4.txt, > HBASE-8220-0.94.3-v5.txt > > > In HTablePool, we have a method getCurrentPoolSize(...) to get how many > opened HTable has been pooled. However, we don't know ConcurrentOpenedHTable > which means the count of HTable get from HTablePool.getTable(...) and don't > return to HTablePool by PooledTable.close(). The ConcurrentOpenedHTable may > be meaningful because it indicates how many HTables should be opened for the > application which may help us set the appropriate MaxSize of HTablePool. > Therefore, we can and a ConcurrentOpenedHTable as a counter in HTablePool. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-10396) The constructor of HBaseAdmin may close the shared HConnection
[
https://issues.apache.org/jira/browse/HBASE-10396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-10396.
Resolution: Won't Fix
0.94 is EOL. Reopen it if objection on mailing list.
> The constructor of HBaseAdmin may close the shared HConnection
> ---
>
> Key: HBASE-10396
> URL: https://issues.apache.org/jira/browse/HBASE-10396
> Project: HBase
> Issue Type: Bug
> Components: Admin, Client
>Affects Versions: 0.94.16
>Reporter: Jianwei Cui
> Attachments: HBASE-10396-0.94-v1.patch, HBASE-10396-0.94-v2.patch
>
>
> HBaseAdmin has the constructor:
> {code}
> public HBaseAdmin(Configuration c)
> throws MasterNotRunningException, ZooKeeperConnectionException {
> this.conf = HBaseConfiguration.create(c);
> this.connection = HConnectionManager.getConnection(this.conf);
> ...
> {code}
> As shown in above code, HBaseAdmin will get a cached HConnection or create a
> new HConnection and use this HConnection to connect to Master. Then,
> HBaseAdmin will delete the HConnection when connecting to master fail as
> follows:
> {code}
> while ( true ){
> try {
> this.connection.getMaster();
> return;
> } catch (MasterNotRunningException mnre) {
> HConnectionManager.deleteStaleConnection(this.connection);
> this.connection = HConnectionManager.getConnection(this.conf);
> }
> {code}
> The above code will invoke HConnectionManager#deleteStaleConnection to delete
> the HConnection from global HConnection cache. The risk is that the deleted
> HConnection might be sharing by other threads, such as HTable or HTablePool.
> Then, these threads which sharing the deleted HConnection will get closed
> HConnection exception:
> {code}
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@61bc59aa
> closed
> {code}
> If users use HTablePool, the situation will become worse because closing
> HTable will only return HTable to HTablePool which won't reduce the reference
> count of the closed HConnection. Then, the closed HConnection will always be
> used before clearing HTablePool. In 0.94, some modules such as Rest server
> are using HTablePool, therefore may suffer from this problem.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17882) Why do the WalEdit implement the Writable interface
Chia-Ping Tsai created HBASE-17882: -- Summary: Why do the WalEdit implement the Writable interface Key: HBASE-17882 URL: https://issues.apache.org/jira/browse/HBASE-17882 Project: HBase Issue Type: Brainstorming Reporter: Chia-Ping Tsai Priority: Minor Do we have any use cases? (serialize/deserialize the WalEdit between mapper and reducer?) If not, we should make WalEdit not implement the Writable interface. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17881) Remove the ByteBufferCellImpl
Chia-Ping Tsai created HBASE-17881: -- Summary: Remove the ByteBufferCellImpl Key: HBASE-17881 URL: https://issues.apache.org/jira/browse/HBASE-17881 Project: HBase Issue Type: Sub-task Components: test Affects Versions: 2.0.0 Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Priority: Minor Fix For: 2.0.0 We should substitute ByteBufferKeyValue for ByteBufferCellImpl -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-17882) Why do the WalEdit implement the Writable interface
[ https://issues.apache.org/jira/browse/HBASE-17882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-17882. Resolution: Duplicate > Why do the WalEdit implement the Writable interface > --- > > Key: HBASE-17882 > URL: https://issues.apache.org/jira/browse/HBASE-17882 > Project: HBase > Issue Type: Brainstorming >Reporter: Chia-Ping Tsai >Priority: Minor > > Do we have any use cases? (serialize/deserialize the WalEdit between mapper > and reducer?) If not, we should make WalEdit not implement the Writable > interface. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17897) StripeStoreFileManager#nonOpenRowCompare use the wrong comparison function.
Chia-Ping Tsai created HBASE-17897:
--
Summary: StripeStoreFileManager#nonOpenRowCompare use the wrong
comparison function.
Key: HBASE-17897
URL: https://issues.apache.org/jira/browse/HBASE-17897
Project: HBase
Issue Type: Sub-task
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
{noformat}
private final int nonOpenRowCompare(byte[] k1, byte[] k2) {
assert !isOpen(k1) && !isOpen(k2);
return cellComparator.compareRows(new KeyOnlyKeyValue(k1), k2, 0,
k2.length);
}
{noformat}
The inputs aren't KeyValue format, so it is wrong to use KeyOnlyKeyValue to
parse the row.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (HBASE-17895) TestAsyncProcess#testAction fails if unsafe support is false
[
https://issues.apache.org/jira/browse/HBASE-17895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai reopened HBASE-17895:
After attaching the patch, you should click the "submit patch" to trigger QA
> TestAsyncProcess#testAction fails if unsafe support is false
>
>
> Key: HBASE-17895
> URL: https://issues.apache.org/jira/browse/HBASE-17895
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Reporter: Chia-Ping Tsai
>Assignee: Wen-Hsiu,Chang
>Priority: Trivial
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-17895-v0.patch
>
>
> {noformat}
> assertEquals(-1, action_0.compareTo(action_1));
> assertEquals(1, action_1.compareTo(action_0));
> {noformat}
> The correction is shown below.
> {noformat}
> assertTrue(action_0.compareTo(action_1) < 0);
> assertTrue(action_1.compareTo(action_0) > 0);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-17843) JUnit test timed out in TestRegionReplicaFailover.java
[ https://issues.apache.org/jira/browse/HBASE-17843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-17843. Resolution: Not A Problem > JUnit test timed out in TestRegionReplicaFailover.java > -- > > Key: HBASE-17843 > URL: https://issues.apache.org/jira/browse/HBASE-17843 > Project: HBase > Issue Type: Improvement >Reporter: Qilin Cao >Priority: Trivial > Attachments: HBASE-17843-v1.patch > > > Junit test sometimes failed in TestRegionReplicaFailover.java, so I changed > the testPrimaryRegionKill method test timeout to 24ms, and add sleep > 5000ms for verify result. > error logs: > Tests run: 6, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 285.221 sec > <<< FAILURE! - in > org.apache.hadoop.hbase.regionserver.TestRegionReplicaFailover > testPrimaryRegionKill[0](org.apache.hadoop.hbase.regionserver.TestRegionReplicaFailover) > Time elapsed: 125.963 sec <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 12 > milliseconds > at java.lang.Object.wait(Native Method) > at java.lang.Object.wait(Object.java:460) > at java.util.concurrent.TimeUnit.timedWait(TimeUnit.java:348) > at > org.apache.hadoop.hbase.client.ResultBoundedCompletionService.pollForSpecificCompletedTask(ResultBoundedCompletionService.java:258) > at > org.apache.hadoop.hbase.client.ResultBoundedCompletionService.pollForFirstSuccessfullyCompletedTask(ResultBoundedCompletionService.java:214) > at > org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.call(RpcRetryingCallerWithReadReplicas.java:209) > at org.apache.hadoop.hbase.client.HTable.get(HTable.java:428) > at org.apache.hadoop.hbase.client.HTable.get(HTable.java:392) > at > org.apache.hadoop.hbase.HBaseTestingUtility.verifyNumericRows(HBaseTestingUtility.java:2197) > at > org.apache.hadoop.hbase.regionserver.TestRegionReplicaFailover.verifyNumericRowsWithTimeout(TestRegionReplicaFailover.java:227) > at > org.apache.hadoop.hbase.regionserver.TestRegionReplicaFailover.testPrimaryRegionKill(TestRegionReplicaFailover.java:200) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region
[
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai reopened HBASE-17943:
There is a test failure after I commit it.
{noformat}
testSelectiveFlushWithBasicAndMerge(org.apache.hadoop.hbase.regionserver.TestWalAndCompactingMemStoreFlush)
Time elapsed: 0.902 sec <<< FAILURE!
java.lang.AssertionError: expected:<13536> but was:<13472>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at
org.apache.hadoop.hbase.regionserver.TestWalAndCompactingMemStoreFlush.testSelectiveFlushWithBasicAndMerge(TestWalAndCompactingMemStoreFlush.java:879)
{noformat}
I will check it asap. Thanks for the reminder. [~yuzhih...@gmail.com]
> The in-memory flush size is different for each CompactingMemStore located in
> the same region
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.v0.patch
>
>
> {noformat}
> private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
> // Family number might also be zero in some of our unit test case
> numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores()
> may be different for each CompactingMemStore.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17941) CellArrayMap#getCell may throw IndexOutOfBoundsException
Chia-Ping Tsai created HBASE-17941:
--
Summary: CellArrayMap#getCell may throw IndexOutOfBoundsException
Key: HBASE-17941
URL: https://issues.apache.org/jira/browse/HBASE-17941
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Chia-Ping Tsai
Priority: Minor
Fix For: 2.0.0
{noformat}
@Override
protected Cell getCell(int i) {
if( (i < minCellIdx) && (i >= maxCellIdx) ) return null;
return block[i];
}
{noformat}
&& -> ||
We have checked the index of bound before calling this method, so the exception
doesn't happen at current trunk.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region
Chia-Ping Tsai created HBASE-17943:
--
Summary: The in-memory flush size is different for each
CompactingMemStore located in the same region
Key: HBASE-17943
URL: https://issues.apache.org/jira/browse/HBASE-17943
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 2.0.0
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Fix For: 2.0.0
{noformat}
private void initInmemoryFlushSize(Configuration conf) {
long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
int numStores = getRegionServices().getNumStores();
if (numStores <= 1) {
// Family number might also be zero in some of our unit test case
numStores = 1;
}
inmemoryFlushSize = memstoreFlushSize / numStores;
{noformat}
We initialize each store in parallel, so the return value from getNumStores()
may be different for each CompactingMemStore.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17778) Remove the testing code in the AsyncRequestFutureImpl
Chia-Ping Tsai created HBASE-17778: -- Summary: Remove the testing code in the AsyncRequestFutureImpl Key: HBASE-17778 URL: https://issues.apache.org/jira/browse/HBASE-17778 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0, 1.4.0 Reporter: Chia-Ping Tsai Priority: Trivial HBASE-16224 left some testing code in the AsyncRequestFutureImpl. It iterates all mutations in order to get the data size. The cost is directly proportional to the size of batch. We should remove it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17735) The usage of getTable() is different between AsyncConnection and Connection
CHIA-PING TSAI created HBASE-17735: -- Summary: The usage of getTable() is different between AsyncConnection and Connection Key: HBASE-17735 URL: https://issues.apache.org/jira/browse/HBASE-17735 Project: HBase Issue Type: Wish Reporter: CHIA-PING TSAI Priority: Minor I'm employing the AsyncConnection to rewrite our application. I find the AsyncConnection#getTable() and Connection#getTable() have some "slightly" differences. # Connection#getTable() throws IOException; # AsyncConnection#getTable() requires the pool; # AsyncTable doesn't need to be closed It may confuse the developers if they have no time to trace the source code (smile). May be we can unify them? Any suggestion is welcomed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17734) guard against possibly coping the qualifier in the ScanDeleteTracker
CHIA-PING TSAI created HBASE-17734:
--
Summary: guard against possibly coping the qualifier in the
ScanDeleteTracker
Key: HBASE-17734
URL: https://issues.apache.org/jira/browse/HBASE-17734
Project: HBase
Issue Type: Improvement
Reporter: CHIA-PING TSAI
Priority: Minor
If the input cell is ByteBufferKeyValue, the
ByteBufferKeyValue#getQualifierArray will copy the qualifier bytes.
ScanDeleteTracker should keep the cell rather than qualifier array.
{noformat}
public void add(Cell cell) {
long timestamp = cell.getTimestamp();
byte type = cell.getTypeByte();
if (!hasFamilyStamp || timestamp > familyStamp) {
if (type == KeyValue.Type.DeleteFamily.getCode()) {
hasFamilyStamp = true;
familyStamp = timestamp;
return;
} else if (type == KeyValue.Type.DeleteFamilyVersion.getCode()) {
familyVersionStamps.add(timestamp);
return;
}
if (deleteBuffer != null && type < deleteType) {
// same column, so ignore less specific delete
if (CellUtil.matchingQualifier(cell, deleteBuffer, deleteOffset,
deleteLength)) {
return;
}
}
// new column, or more general delete type
deleteBuffer = cell.getQualifierArray();
deleteOffset = cell.getQualifierOffset();
deleteLength = cell.getQualifierLength();
deleteType = type;
deleteTimestamp = timestamp;
}
// missing else is never called.
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17736) Some options can't be configured by the shell
CHIA-PING TSAI created HBASE-17736: -- Summary: Some options can't be configured by the shell Key: HBASE-17736 URL: https://issues.apache.org/jira/browse/HBASE-17736 Project: HBase Issue Type: Bug Affects Versions: 2.0.0 Reporter: CHIA-PING TSAI Priority: Minor Fix For: 2.0.0 The lost options for table are shown below. # setFlushPolicyClassName # setPriority # setRegionMemstoreReplication # setRegionSplitPolicyClassName The lost options for column are shown below. # setCacheBloomsOnWrite # setCacheDataInL1 # setCacheIndexesOnWrite # setCompactionCompressionType # setEvictBlocksOnClose -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-16575) unify the semantic of RRCI#callWithRetries and RRCI#callWithoutRetries when the maxAttempts is configured to one
[ https://issues.apache.org/jira/browse/HBASE-16575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-16575. Resolution: Not A Problem > unify the semantic of RRCI#callWithRetries and RRCI#callWithoutRetries when > the maxAttempts is configured to one > > > Key: HBASE-16575 > URL: https://issues.apache.org/jira/browse/HBASE-16575 > Project: HBase > Issue Type: Improvement >Reporter: Chia-Ping Tsai >Priority: Minor > > It seems to me that RRCI#callWithRetries and RRCI#callWithoutRetries should > have the same logic if the maxAttempts is configured to one. But there are > some difference are shown below: > 1) timeout > 2) failure handle > The quick solution is that we always call the RRCI#callWithRetries in the > RRCI#callWithoutRetries when the maxAttempts is configured to one. > Any comment? Thanks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17894) make sure all tests without unsafe pass
Chia-Ping Tsai created HBASE-17894: -- Summary: make sure all tests without unsafe pass Key: HBASE-17894 URL: https://issues.apache.org/jira/browse/HBASE-17894 Project: HBase Issue Type: Umbrella Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai The HBASE-17890, HBASE-17882, and HBASE-17859 expose the bugs happening when the unsafe support is false. This jira keeps submitting the patch to run all tests without unsafe until they pass. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-18259) HBase book link to "beginner" issues includes resolved issues
[ https://issues.apache.org/jira/browse/HBASE-18259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-18259. Resolution: Fixed Hadoop Flags: Reviewed [~psomogyi] Thanks for the patch. > HBase book link to "beginner" issues includes resolved issues > - > > Key: HBASE-18259 > URL: https://issues.apache.org/jira/browse/HBASE-18259 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Mike Drob >Assignee: Peter Somogyi > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18259.master.001.patch, > HBASE-18259.master.ADDENDUM.patch > > > The link at http://hbase.apache.org/book.html#getting.involved for beginner > issues is > https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner) > but this includes resolved issues as well, which is not useful to folks > looking for new issues to cut their teeth on. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18488) Backport HBASE-15710(Include issue servers information in RetriesExhaustedWithDetailsException message) to branch-1.2
Chia-Ping Tsai created HBASE-18488: -- Summary: Backport HBASE-15710(Include issue servers information in RetriesExhaustedWithDetailsException message) to branch-1.2 Key: HBASE-18488 URL: https://issues.apache.org/jira/browse/HBASE-18488 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18480) The cost of BaseLoadBalancer.cluster is changed even if the rollback is done
Chia-Ping Tsai created HBASE-18480: -- Summary: The cost of BaseLoadBalancer.cluster is changed even if the rollback is done Key: HBASE-18480 URL: https://issues.apache.org/jira/browse/HBASE-18480 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai If the cost of cluster isn't restored after the undo action, StochasticLoadBalancer will be hard to generate the "good" action to balance the cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-18476) HTable#put should call RS#mutate rather than RS#multi
[ https://issues.apache.org/jira/browse/HBASE-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-18476. Resolution: Duplicate see HBASE-18500 > HTable#put should call RS#mutate rather than RS#multi > - > > Key: HBASE-18476 > URL: https://issues.apache.org/jira/browse/HBASE-18476 > Project: HBase > Issue Type: Bug >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 3.0.0, 1.4.0, 1.5.0, 2.0.0-alpha-2 > > > The HBASE-18374 separates the metric for a single put and batched puts so the > HTable#put shouldn't use the RS#mulit. It messes up the metrics. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18502) Change MasterObserver to use TableDescriptor
Chia-Ping Tsai created HBASE-18502: -- Summary: Change MasterObserver to use TableDescriptor Key: HBASE-18502 URL: https://issues.apache.org/jira/browse/HBASE-18502 Project: HBase Issue Type: Umbrella Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Priority: Critical MasterObserver is IA.Private so we can make some Incompatible change for 3.0 and 2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18503) Change ***Util to use TableDescriptor and ColumnFamilyDescriptor
Chia-Ping Tsai created HBASE-18503: -- Summary: Change ***Util to use TableDescriptor and ColumnFamilyDescriptor Key: HBASE-18503 URL: https://issues.apache.org/jira/browse/HBASE-18503 Project: HBase Issue Type: Umbrella Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai These helper classes accept the HTD and HCD as argument. We need to make some changes for them, otherwise we will be forced to use HTD and HCD. # SecureTestUtil # MobSnapshotTestingUtils -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18501) Use TableDescriptor and ColumnFamilyDescriptor as far as possible
Chia-Ping Tsai created HBASE-18501: -- Summary: Use TableDescriptor and ColumnFamilyDescriptor as far as possible Key: HBASE-18501 URL: https://issues.apache.org/jira/browse/HBASE-18501 Project: HBase Issue Type: Umbrella Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai We need to do some cleanup for the *public* class as much as possible. Otherwise, the HTD and HCD may linger in the code base for a long time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18515) Introduce Delete.add as a replacement for Delete#addDeleteMarker
Chia-Ping Tsai created HBASE-18515:
--
Summary: Introduce Delete.add as a replacement for
Delete#addDeleteMarker
Key: HBASE-18515
URL: https://issues.apache.org/jira/browse/HBASE-18515
Project: HBase
Issue Type: Task
Reporter: Chia-Ping Tsai
Fix For: 3.0.0, 2.0.0-alpha-2
{quote}
public Delete addDeleteMarker(Cell kv) throws IOException {
// TODO: Deprecate and rename 'add' so it matches how we add KVs to Puts.
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18609) Apply HBASE-15511 in code base
Chia-Ping Tsai created HBASE-18609: -- Summary: Apply HBASE-15511 in code base Key: HBASE-18609 URL: https://issues.apache.org/jira/browse/HBASE-18609 Project: HBase Issue Type: Improvement Reporter: Chia-Ping Tsai HBASE-15511 enable us to get the cluster status by scope. We should apply it in code base so as to prevent the useless information. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18554) Append#add doesn't check the row of passed cell
Chia-Ping Tsai created HBASE-18554:
--
Summary: Append#add doesn't check the row of passed cell
Key: HBASE-18554
URL: https://issues.apache.org/jira/browse/HBASE-18554
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
{code}
@SuppressWarnings("unchecked")
public Append add(final Cell cell) {
// Presume it is KeyValue for now.
byte [] family = CellUtil.cloneFamily(cell);
List list = this.familyMap.get(family);
if (list == null) {
list = new ArrayList<>(1);
}
// find where the new entry should be placed in the List
list.add(cell);
this.familyMap.put(family, list);
return this;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18572) Delete#addColumn can't remove the cell which has no visibility label
Chia-Ping Tsai created HBASE-18572:
--
Summary: Delete#addColumn can't remove the cell which has no
visibility label
Key: HBASE-18572
URL: https://issues.apache.org/jira/browse/HBASE-18572
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
{code:title=DefaultVisibilityLabelServiceImpl.java}
@Override
public boolean matchVisibility(List putVisTags, Byte putTagsFormat,
List deleteVisTags,
Byte deleteTagsFormat) throws IOException {
if ((deleteTagsFormat != null && deleteTagsFormat ==
SORTED_ORDINAL_SERIALIZATION_FORMAT)
&& (putTagsFormat == null || putTagsFormat ==
SORTED_ORDINAL_SERIALIZATION_FORMAT)) {
if (putVisTags.isEmpty()) {
// Early out if there are no tags in the cell
return false;
}
if (putTagsFormat == null) {
return matchUnSortedVisibilityTags(putVisTags, deleteVisTags);
} else {
return matchOrdinalSortedVisibilityTags(putVisTags, deleteVisTags);
}
}
throw new IOException("Unexpected tag format passed for comparison,
deleteTagsFormat : "
+ deleteTagsFormat + ", putTagsFormat : " + putTagsFormat);
}
{code}
If the putVisTags is empty, it will return the false directly. Hence, the
Delete#addColumn can't "see" the cell as well as deleting it. The
Delete#addColumns, by contrast, doesn't invoke the
cp#prePrepareTimeStampForDeleteVersion so it can remove the cell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-18558) clean up duplicate dependency management entries for hbase-shaded-miscellaneous
[
https://issues.apache.org/jira/browse/HBASE-18558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-18558.
Resolution: Fixed
Hadoop Flags: Reviewed
Thanks all contributors!
> clean up duplicate dependency management entries for
> hbase-shaded-miscellaneous
> ---
>
> Key: HBASE-18558
> URL: https://issues.apache.org/jira/browse/HBASE-18558
> Project: HBase
> Issue Type: Task
> Components: dependencies, pom
>Affects Versions: 3.0.0
>Reporter: Sean Busbey
>Assignee: ChunHao
>Priority: Minor
> Labels: beginner
> Fix For: 3.0.0
>
>
> our root pom's dependency management section has two entries like:
> {code}
>
> org.apache.hbase.thirdparty
> hbase-shaded-miscellaneous
> ${hbase-thirdparty.version}
>
> {code}
> which causes a bunch of warnings at build time. remove one.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18582) Correct the docs for Mutation#setCellVisibility
Chia-Ping Tsai created HBASE-18582:
--
Summary: Correct the docs for Mutation#setCellVisibility
Key: HBASE-18582
URL: https://issues.apache.org/jira/browse/HBASE-18582
Project: HBase
Issue Type: Task
Reporter: Chia-Ping Tsai
Priority: Minor
{code}
/**
* Sets the visibility expression associated with cells in this Mutation.
* It is illegal to set CellVisibility on Delete
mutation.
* @param expression
*/
{code}
HBASE-10885 enable Delete to be specified with Cell Visibility, so we should
remove the comment " It is illegal to set..."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-17803) PE always re-creates table when we specify the split policy
[
https://issues.apache.org/jira/browse/HBASE-17803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-17803.
Resolution: Fixed
Fix Version/s: 1.2.7
1.3.2
> PE always re-creates table when we specify the split policy
> ---
>
> Key: HBASE-17803
> URL: https://issues.apache.org/jira/browse/HBASE-17803
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-17803.branch-1.3.v0.patch,
> HBASE-17803.branch-1.v0.patch, HBASE-17803.v0.patch
>
>
> I find this bug when i run the tests for HBASE-17623
> The critical code is shown below.
> {noformat}
> if ((exists && opts.presplitRegions != DEFAULT_OPTS.presplitRegions)
> || (!isReadCmd && desc != null && desc.getRegionSplitPolicyClassName()
> != opts.splitPolicy)
> || (!isReadCmd && desc != null && desc.getRegionReplication() !=
> opts.replicas)) {
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18365) Eliminate the findbugs warnings for hbase-common
Chia-Ping Tsai created HBASE-18365: -- Summary: Eliminate the findbugs warnings for hbase-common Key: HBASE-18365 URL: https://issues.apache.org/jira/browse/HBASE-18365 Project: HBase Issue Type: Sub-task Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18344) Replace Append#add(byte[], byte[], byte[]) by Append#addColumn
Chia-Ping Tsai created HBASE-18344: -- Summary: Replace Append#add(byte[], byte[], byte[]) by Append#addColumn Key: HBASE-18344 URL: https://issues.apache.org/jira/browse/HBASE-18344 Project: HBase Issue Type: Task Reporter: Chia-Ping Tsai Priority: Trivial Fix For: 3.0.0, 2.0.0-alpha-2 We have Put#addColumn and Increment#addColumn but there is no Append#addColumn. We should add Append#addColumn for consistency. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-13287) Append is missing methods, such as addColumn()
[
https://issues.apache.org/jira/browse/HBASE-13287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-13287.
Resolution: Duplicate
> Append is missing methods, such as addColumn()
> --
>
> Key: HBASE-13287
> URL: https://issues.apache.org/jira/browse/HBASE-13287
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Assignee: Jan Hentschel
>
> Analog to Put, Delete, Get, etc. Append should have the same common method
> signature, namely {{addColumn()}} as opposed to the older {{add()}}. Also
> consider adding the other variant that Put has, including the _immutable_
> versions.
> Question related: should those methods not better be in the Mutation class?
> All derived classes implement them. {{setTTL()}} is in Mutation, and throws
> an exception when used with {{Delete}}. So why not moved those down too? (cc
> [~saint@gmail.com])
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18391) List the stuffs which are using the patent grant license (PATENTS file) of Facebook; And then discuss and remove them.
Chia-Ping Tsai created HBASE-18391: -- Summary: List the stuffs which are using the patent grant license (PATENTS file) of Facebook; And then discuss and remove them. Key: HBASE-18391 URL: https://issues.apache.org/jira/browse/HBASE-18391 Project: HBase Issue Type: Task Reporter: Chia-Ping Tsai See ["Apache Foundation disallows use of the Facebook “BSD+Patent” license"|https://news.ycombinator.com/item?id=14779881] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (HBASE-18390) Sleep too long when finding region location failed
[ https://issues.apache.org/jira/browse/HBASE-18390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai reopened HBASE-18390: We don't get response from QA for branch-1...TestClientScannerRPCTimeout fails in branch-1 on my machine. Would you please take a look? Thanks. > Sleep too long when finding region location failed > -- > > Key: HBASE-18390 > URL: https://issues.apache.org/jira/browse/HBASE-18390 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6, 1.1.11, 2.0.0-alpha-1 >Reporter: Phil Yang >Assignee: Phil Yang > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-2, 1.1.12 > > Attachments: HBASE-18390.v01.patch, HBASE-18390.v02.patch, > HBASE-18390.v03.patch > > > If RegionServerCallable#prepare failed when getRegionLocation, the location > in this callable object is null. And before we retry we will sleep. However, > when location is null we will sleep at least 10 seconds. And the request will > be failed directly if operation timeout is less than 10 seconds. I think it > is no need to keep MIN_WAIT_DEAD_SERVER logic. Use backoff sleeping logic is > ok for most cases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18449) Fix client.locking.TestEntityLocks
Chia-Ping Tsai created HBASE-18449:
--
Summary: Fix client.locking.TestEntityLocks
Key: HBASE-18449
URL: https://issues.apache.org/jira/browse/HBASE-18449
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 2.0.0-alpha-1, 3.0.0
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Priority: Minor
Fix For: 3.0.0, 2.0.0-alpha-2
{noformat}
Wanted but not invoked:
abortable.abort(
,
isA(org.apache.hadoop.hbase.HBaseIOException)
);
-> at
org.apache.hadoop.hbase.client.locking.TestEntityLocks.testHeartbeatException(TestEntityLocks.java:195)
Actually, there were zero interactions with this mock.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (HBASE-17131) Avoid livelock caused by HRegion#processRowsWithLocks
[
https://issues.apache.org/jira/browse/HBASE-17131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai reopened HBASE-17131:
> Avoid livelock caused by HRegion#processRowsWithLocks
> -
>
> Key: HBASE-17131
> URL: https://issues.apache.org/jira/browse/HBASE-17131
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0, 1.4.0, 1.3.1
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-17131.branch-1.v0.patch, HBASE-17131.v0.patch
>
>
> {code:title=HRegion.java|borderStyle=solid}
> try {
> // STEP 2. Acquire the row lock(s)
> acquiredRowLocks = new ArrayList(rowsToLock.size());
> for (byte[] row : rowsToLock) {
> // Attempt to lock all involved rows, throw if any lock times out
> // use a writer lock for mixed reads and writes
> acquiredRowLocks.add(getRowLockInternal(row, false));
> }
> // STEP 3. Region lock
> lock(this.updatesLock.readLock(), acquiredRowLocks.size() == 0 ? 1 :
> acquiredRowLocks.size());
> locked = true;
> boolean success = false;
> long now = EnvironmentEdgeManager.currentTime();
> try {
> {code}
> We should lock all involved rows in the second try-finally. Otherwise, we
> won’t release the previous locks if any subsequent lock times out.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-18464) Backport HBASE-17131 (Avoid livelock caused by HRegion#processRowsWithLocks) into branch-1.3 and branch-1.2
[ https://issues.apache.org/jira/browse/HBASE-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-18464. Resolution: Duplicate > Backport HBASE-17131 (Avoid livelock caused by HRegion#processRowsWithLocks) > into branch-1.3 and branch-1.2 > --- > > Key: HBASE-18464 > URL: https://issues.apache.org/jira/browse/HBASE-18464 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6 >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 1.3.2, 1.2.7 > > > see HBASE-17131 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18464) Backport HBASE-17131 (Avoid livelock caused by HRegion#processRowsWithLocks) into branch-1.3 and branch-1.2
Chia-Ping Tsai created HBASE-18464: -- Summary: Backport HBASE-17131 (Avoid livelock caused by HRegion#processRowsWithLocks) into branch-1.3 and branch-1.2 Key: HBASE-18464 URL: https://issues.apache.org/jira/browse/HBASE-18464 Project: HBase Issue Type: Bug Affects Versions: 1.2.6, 1.3.1 Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Fix For: 1.3.2, 1.2.7 see HBASE-17131 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-18390) Sleep too long when finding region location failed
[ https://issues.apache.org/jira/browse/HBASE-18390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-18390. Resolution: Fixed > Sleep too long when finding region location failed > -- > > Key: HBASE-18390 > URL: https://issues.apache.org/jira/browse/HBASE-18390 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.1, 1.2.6, 1.1.11, 2.0.0-alpha-1 >Reporter: Phil Yang >Assignee: Phil Yang > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-2, 1.1.12 > > Attachments: HBASE-18390.v01.patch, HBASE-18390.v02.patch, > HBASE-18390.v03.patch > > > If RegionServerCallable#prepare failed when getRegionLocation, the location > in this callable object is null. And before we retry we will sleep. However, > when location is null we will sleep at least 10 seconds. And the request will > be failed directly if operation timeout is less than 10 seconds. I think it > is no need to keep MIN_WAIT_DEAD_SERVER logic. Use backoff sleeping logic is > ok for most cases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18415) Fix client.TestClientScannerRPCTimeout
Chia-Ping Tsai created HBASE-18415:
--
Summary: Fix client.TestClientScannerRPCTimeout
Key: HBASE-18415
URL: https://issues.apache.org/jira/browse/HBASE-18415
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Priority: Minor
{quote}
Running org.apache.hadoop.hbase.client.TestClientScannerRPCTimeout
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.046 sec <<<
FAILURE! - in org.apache.hadoop.hbase.client.TestClientScannerRPCTimeout
testScannerNextRPCTimesout(org.apache.hadoop.hbase.client.TestClientScannerRPCTimeout)
Time elapsed: 4.186 sec <<< ERROR!
org.apache.hadoop.hbase.TableExistsException: testScannerNextRPCTimesout
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
at
org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
at
org.apache.hadoop.hbase.util.ForeignExceptionUtil.toIOException(ForeignExceptionUtil.java:45)
at
org.apache.hadoop.hbase.client.HBaseAdmin$ProcedureFuture.convertResult(HBaseAdmin.java:4773)
at
org.apache.hadoop.hbase.client.HBaseAdmin$ProcedureFuture.waitProcedureResult(HBaseAdmin.java:4731)
at
org.apache.hadoop.hbase.client.HBaseAdmin$ProcedureFuture.get(HBaseAdmin.java:4664)
at
org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:678)
at
org.apache.hadoop.hbase.HBaseTestingUtility.createTable(HBaseTestingUtility.java:1500)
at
org.apache.hadoop.hbase.HBaseTestingUtility.createTable(HBaseTestingUtility.java:1547)
at
org.apache.hadoop.hbase.HBaseTestingUtility.createTable(HBaseTestingUtility.java:1438)
at
org.apache.hadoop.hbase.HBaseTestingUtility.createTable(HBaseTestingUtility.java:1414)
at
org.apache.hadoop.hbase.HBaseTestingUtility.createTable(HBaseTestingUtility.java:1370)
at
org.apache.hadoop.hbase.client.TestClientScannerRPCTimeout.testScannerNextRPCTimesout(TestClientScannerRPCTimeout.java:92)
Caused by: org.apache.hadoop.ipc.RemoteException: testScannerNextRPCTimesout
at
org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.prepareCreate(CreateTableProcedure.java:286)
at
org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:107)
at
org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:59)
at
org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:139)
at
org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:506)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1152)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execLoop(ProcedureExecutor.java:940)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execLoop(ProcedureExecutor.java:893)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$400(ProcedureExecutor.java:76)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor$2.run(ProcedureExecutor.java:478)
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18420) Some methods of Admin don't use ColumnFamilyDescriptor
Chia-Ping Tsai created HBASE-18420: -- Summary: Some methods of Admin don't use ColumnFamilyDescriptor Key: HBASE-18420 URL: https://issues.apache.org/jira/browse/HBASE-18420 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18293) Only add the spotbugs dependency when jdk8 is active
Chia-Ping Tsai created HBASE-18293:
--
Summary: Only add the spotbugs dependency when jdk8 is active
Key: HBASE-18293
URL: https://issues.apache.org/jira/browse/HBASE-18293
Project: HBase
Issue Type: Sub-task
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Fix For: 1.4.0, 1.3.2, 1.2.7, 1.1.12
The spotbugs requires the java 8 so we should only add the spotbugs dependency
when jdk8 is active.
{noformat}
[INFO] Fork Value is true
[java] Exception in thread "main" java.lang.UnsupportedClassVersionError:
edu/umd/cs/findbugs/FindBugs2 : Unsupported major.minor version 52.0
[java] at java.lang.ClassLoader.defineClass1(Native Method)
[java] at java.lang.ClassLoader.defineClass(ClassLoader.java:803)
[java] at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
[java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:442)
[java] at java.net.URLClassLoader.access$100(URLClassLoader.java:64)
[java] at java.net.URLClassLoader$1.run(URLClassLoader.java:354)
[java] at java.net.URLClassLoader$1.run(URLClassLoader.java:348)
[java] at java.security.AccessController.doPrivileged(Native Method)
[java] at java.net.URLClassLoader.findClass(URLClassLoader.java:347)
[java] at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
[java] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:312)
[java] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
[java] at
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-18157) TestLockProcedure is flaky in master branch
[
https://issues.apache.org/jira/browse/HBASE-18157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-18157.
Resolution: Duplicate
see HBASE-18292
> TestLockProcedure is flaky in master branch
> ---
>
> Key: HBASE-18157
> URL: https://issues.apache.org/jira/browse/HBASE-18157
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>
> From
> https://builds.apache.org/job/PreCommit-HBASE-Build/7060/artifact/patchprocess/patch-unit-hbase-server.txt
> :
> {code}
> testLocalMasterLockRecovery(org.apache.hadoop.hbase.master.locking.TestLockProcedure)
> Time elapsed: 30.049 sec <<< ERROR!
> java.lang.Exception: Appears to be stuck in thread ResponseProcessor for
> block BP-387952765-172.17.0.2-1496577331729:blk_1073741842_1018
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at
> org.apache.hadoop.net.SocketIOWithTimeout$SelectorPool.select(SocketIOWithTimeout.java:335)
> at
> org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:157)
> at
> org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:161)
> at
> org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:131)
> at
> org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:118)
> {code}
> TestLockProcedure is a small test. Its failure would prevent medium / large
> tests from running.
> According to
> https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html
> , its flaky rate is 33%.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18295) TestAcidGuarantees fails again
Chia-Ping Tsai created HBASE-18295: -- Summary: TestAcidGuarantees fails again Key: HBASE-18295 URL: https://issues.apache.org/jira/browse/HBASE-18295 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Priority: Blocker Fix For: 2.0.0, 3.0.0 >From the [flaky >dashboard|https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18306) Get rid of TableDescriptor#getConfiguration
Chia-Ping Tsai created HBASE-18306: -- Summary: Get rid of TableDescriptor#getConfiguration Key: HBASE-18306 URL: https://issues.apache.org/jira/browse/HBASE-18306 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Fix For: 3.0.0, 2.0.0-alpha-2 We should substitute TD#Value for the TD#Configuration. The TD#Configuration is rarely used in code base. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18315) Eliminate the findbugs warnings for hbase-rest
Chia-Ping Tsai created HBASE-18315: -- Summary: Eliminate the findbugs warnings for hbase-rest Key: HBASE-18315 URL: https://issues.apache.org/jira/browse/HBASE-18315 Project: HBase Issue Type: Sub-task Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Fix For: 3.0.0, 2.0.0-alpha-2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18314) Eliminate the findbugs warnings for hbase-examples
Chia-Ping Tsai created HBASE-18314: -- Summary: Eliminate the findbugs warnings for hbase-examples Key: HBASE-18314 URL: https://issues.apache.org/jira/browse/HBASE-18314 Project: HBase Issue Type: Sub-task Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Fix For: 3.0.0, 2.0.0-alpha-2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18308) Eliminate the findbugs warnings for hbase-server
Chia-Ping Tsai created HBASE-18308: -- Summary: Eliminate the findbugs warnings for hbase-server Key: HBASE-18308 URL: https://issues.apache.org/jira/browse/HBASE-18308 Project: HBase Issue Type: Sub-task Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-15583) Any HTableDescriptor we give out should be immutable
[ https://issues.apache.org/jira/browse/HBASE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-15583. Resolution: Fixed The "rebased" code is some hunks. Thanks for the reviewing. [~yuzhih...@gmail.com], [~stack] > Any HTableDescriptor we give out should be immutable > > > Key: HBASE-15583 > URL: https://issues.apache.org/jira/browse/HBASE-15583 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Gabor Liptak >Assignee: Chia-Ping Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-15583.v0.patch, HBASE-15583.v1.patch, > HBASE-15583.v2.patch, HBASE-15583.v3.patch, HBASE-15583.v4.patch, > HBASE-15583.v5.patch, HBASE-15583.v6.patch, HBASE-15583.v7.patch > > > From [~enis] in https://issues.apache.org/jira/browse/HBASE-15505: > PS Should UnmodifyableHTableDescriptor be renamed to > UnmodifiableHTableDescriptor? > It should be named ImmutableHTableDescriptor to be consistent with > collections naming. Let's do this as a subtask of the parent jira, not here. > Thinking about it though, why would we return an Immutable HTD in > HTable.getTableDescriptor() versus a mutable HTD in > Admin.getTableDescriptor(). It does not make sense. Should we just get rid of > the Immutable ones? > We also have UnmodifyableHRegionInfo which is not used at the moment it > seems. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-10540) HBaseAdmin.createTable(HTableDescriptor, splitKeys) doesn't need to call isLegalTableName.
[
https://issues.apache.org/jira/browse/HBASE-10540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-10540.
Resolution: Won't Fix
The isLegalTableName has removed by HBASE-8408. 0.94 is EOL.
> HBaseAdmin.createTable(HTableDescriptor, splitKeys) doesn't need to call
> isLegalTableName.
> --
>
> Key: HBASE-10540
> URL: https://issues.apache.org/jira/browse/HBASE-10540
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.16
>Reporter: Jean-Marc Spaggiari
>Assignee: Jean-Marc Spaggiari
>Priority: Minor
> Attachments: HBASE-10540-v0-0.94.patch
>
>
> {code}
> public void createTable(final HTableDescriptor desc, byte [][] splitKeys)
> throws IOException {
> HTableDescriptor.isLegalTableName(desc.getName());
> try {
> createTableAsync(desc, splitKeys);
> } catch (SocketTimeoutException ste) {
> LOG.warn("Creating " + desc.getNameAsString() + " took too long", ste);
> }
> {code}
> crateTable calls isLegalTableName and few lines after, createTableAsync.
> However, createTableAsync also calls isLegalTableName which results to a
> double call.
> Therefor, we can remove the call to isLegalTableName from crateTable.
> Trunk does'nt call isLegalTableName (Should it?). Nor is 0.96.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-15626) RetriesExhaustedWithDetailsException#getDesc won't return the full message
[
https://issues.apache.org/jira/browse/HBASE-15626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-15626.
Resolution: Duplicate
.
> RetriesExhaustedWithDetailsException#getDesc won't return the full message
> --
>
> Key: HBASE-15626
> URL: https://issues.apache.org/jira/browse/HBASE-15626
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.0.0
>Reporter: Jianwei Cui
>Priority: Minor
> Attachments: HBASE-15626-v1.patch
>
>
> The RetriesExhaustedWithDetailsException#getDesc will include server
> addresses as:
> {code}
> public static String getDesc(List exceptions,
>List actions,
>List hostnamePort) {
> String s = getDesc(classifyExs(exceptions));
> StringBuilder addrs = new StringBuilder(s);
> addrs.append("servers with issues: ");
> Set uniqAddr = new HashSet();
> uniqAddr.addAll(hostnamePort);
> for(String addr : uniqAddr) {
> addrs.append(addr).append(", ");
> }
> return s; // ==> should be addrs.toString()
> }
> {code}
> However, the returned value is {{s}}, only includes the exceptions. To
> include the server addresses, the returned value should be
> {{addrs.toString()}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-15208) AsyncProcess seems to rely on regionId() to be unique which is not
[
https://issues.apache.org/jira/browse/HBASE-15208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-15208.
Resolution: Duplicate
It is fixed. see HBASE-15479
> AsyncProcess seems to rely on regionId() to be unique which is not
> --
>
> Key: HBASE-15208
> URL: https://issues.apache.org/jira/browse/HBASE-15208
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 2.0.0, 1.2.0, 1.3.0, 1.0.3, 1.1.3, 0.98.16.1
>Reporter: Matteo Bertozzi
>
> AsyncProcess is using getRegionId() to identify a region. It looks like the
> original implementation was using encodedName which is unique, but then we
> switched to regionIds with HBASE-9988.
> {code}
> protected boolean canTakeOperation(HRegionLocation loc,
> Map regionsIncluded,
> Map
> serversIncluded) {
> long regionId = loc.getRegionInfo().getRegionId();
> Boolean regionPrevious = regionsIncluded.get(regionId);
> if (regionPrevious != null) {
> // We already know what to do with this region.
> return regionPrevious;
> }
> {code}
> The RegionId is not unique, since it is a timestamp. and specifically in case
> we create a table with splits each region get the same regionId. (from the
> doc of HRegionInfo about regionId, looks like that field should be named
> creationTimestamp or something like that for a more expressive name).
> I'm unsure on what are the consequences. from a couple of tests and the code
> looks like it may just allow more tasks than the one configured by the max
> task allowed conf. but I'd let someone else familiar with this code look into
> it.
> Also TestAsyncProcess has the HRegionInfo hr1, hr2, hr3 with different
> regionIds, if we switch them to be the same id we have a
> testSubmitBusyRegionServer() failing
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-7278) Some bugs of HTableDesciptor
[
https://issues.apache.org/jira/browse/HBASE-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-7278.
---
Resolution: Duplicate
The setMetaFlags and isLegalTableName are fixed by HBASE-8408.
> Some bugs of HTableDesciptor
>
>
> Key: HBASE-7278
> URL: https://issues.apache.org/jira/browse/HBASE-7278
> Project: HBase
> Issue Type: Bug
>Reporter: Hiroshi Ikeda
>Priority: Minor
>
> There are some bugs of the class HTableDescriptor.
> {code}
> public HTableDescriptor(final byte [] name) {
> super();
> setMetaFlags(this.name);
> this.name = this.isMetaRegion()? name: isLegalTableName(name);
> this.nameAsString = Bytes.toString(this.name);
> }
> {code}
> I think "setMetaFlags(this.name)" should be "setMetaFlags(name)".
> {code}
> /**
>* Check passed byte buffer, "tableName", is legal user-space table name.
>* @return Returns passed tableName param
>* @throws NullPointerException If passed tableName is null
>* @throws IllegalArgumentException if passed a tableName
>* that is made of other than 'word' characters or underscores: i.e.
>* [a-zA-Z_0-9].
>*/
> public static byte [] isLegalTableName(final byte [] tableName) {
> if (tableName == null || tableName.length <= 0) {
> throw new IllegalArgumentException("Name is null or empty");
> }
> {code}
> The implementation is against the contract of throwing NullPointerException.
> I'm not sure the contract is wrong or the implementation is wrong.
> Also the contract of throwing IllegalArgumentException is a little different
> from the actual implementation, and in general we must actually call this
> method and catch IllegalArgumentException in order to know whether the given
> name can be used as a table name.
> I feel HTableDescriptor allows itself to be in invalid states, and I cannot
> fix the class well.
> I think we should start to remove implementing WritableComparable, but it
> might greatly break the compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (HBASE-18259) HBase book link to "beginner" issues includes resolved issues
[ https://issues.apache.org/jira/browse/HBASE-18259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai reopened HBASE-18259: > HBase book link to "beginner" issues includes resolved issues > - > > Key: HBASE-18259 > URL: https://issues.apache.org/jira/browse/HBASE-18259 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Mike Drob >Assignee: Peter Somogyi > Labels: beginner > Fix For: 3.0.0 > > Attachments: HBASE-18259.master.001.patch > > > The link at http://hbase.apache.org/book.html#getting.involved for beginner > issues is > https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner) > but this includes resolved issues as well, which is not useful to folks > looking for new issues to cut their teeth on. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18476) HTable#put should call RS#mutate rather than RS#multi
Chia-Ping Tsai created HBASE-18476: -- Summary: HTable#put should call RS#mutate rather than RS#multi Key: HBASE-18476 URL: https://issues.apache.org/jira/browse/HBASE-18476 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Fix For: 3.0.0, 1.4.0, 1.5.0, 2.0.0-alpha-2 The HBASE-18374 separates the metric for a single put and batched puts so the HTable#put shouldn't use the RS#mulit. It messes up the metrics. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-18266) Eliminate the warnings from the spotbugs
[ https://issues.apache.org/jira/browse/HBASE-18266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-18266. Resolution: Fixed All sub-tasks are resolved. > Eliminate the warnings from the spotbugs > > > Key: HBASE-18266 > URL: https://issues.apache.org/jira/browse/HBASE-18266 > Project: HBase > Issue Type: Umbrella >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 2.0.0-alpha-2 > > > It is hard to get +1 from QA currently because spotbugs is always unhappy... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18544) Move the HRegion#addRegionToMETA to TestDefaultMemStore
Chia-Ping Tsai created HBASE-18544: -- Summary: Move the HRegion#addRegionToMETA to TestDefaultMemStore Key: HBASE-18544 URL: https://issues.apache.org/jira/browse/HBASE-18544 Project: HBase Issue Type: Task Components: regionserver Affects Versions: 2.0.0-alpha-1, 3.0.0 Reporter: Chia-Ping Tsai Priority: Minor Fix For: 3.0.0, 2.0.0-alpha-2 The usages of addRegionToMETA are almost removed by HBASE-17470. HRegion#addRegionToMETA is used only by TestDefaultMemStore now. Let us reduce the file size of HRegion. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18483) The RpcRetryingCaller#translateException doesn't handle RemoteException
Chia-Ping Tsai created HBASE-18483:
--
Summary: The RpcRetryingCaller#translateException doesn't handle
RemoteException
Key: HBASE-18483
URL: https://issues.apache.org/jira/browse/HBASE-18483
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Priority: Minor
{code}
if (t instanceof ServiceException) {
ServiceException se = (ServiceException)t;
Throwable cause = se.getCause();
if (cause != null) {
if (cause instanceof DoNotRetryIOException) {
throw (DoNotRetryIOException)cause;
} else if (cause instanceof NeedUnmanagedConnectionException) {
throw new DoNotRetryIOException(cause);
}
}
// Don't let ServiceException out; its rpc specific.
t = cause;
// t could be a RemoteException so go aaround again.
translateException(t);
} else if (t instanceof DoNotRetryIOException) {
throw (DoNotRetryIOException)t;
} else if (t instanceof NeedUnmanagedConnectionException) {
throw new DoNotRetryIOException(t);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18546) Append/Increment a cell with custom timestamp
Chia-Ping Tsai created HBASE-18546:
--
Summary: Append/Increment a cell with custom timestamp
Key: HBASE-18546
URL: https://issues.apache.org/jira/browse/HBASE-18546
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
We don't pass the custom timestamp for Increment, and the increment's timestamp
always be rewrite. Hence, user can't increment a cell with custom timestamp.
{code:title=ProtobufUtil.java}
if (values != null && values.size() > 0) {
for (Cell cell: values) {
valueBuilder.clear();
valueBuilder.setQualifier(UnsafeByteOperations.unsafeWrap(
cell.getQualifierArray(), cell.getQualifierOffset(),
cell.getQualifierLength()));
valueBuilder.setValue(UnsafeByteOperations.unsafeWrap(
cell.getValueArray(), cell.getValueOffset(),
cell.getValueLength()));
if (cell.getTagsLength() > 0) {
valueBuilder.setTags(UnsafeByteOperations.unsafeWrap(cell.getTagsArray(),
cell.getTagsOffset(), cell.getTagsLength()));
}
columnBuilder.addQualifierValue(valueBuilder.build());
}
}
{code}
In contrast to Increment, user can append the cell with custom timestamp. It
would be better that make their behavior consistent.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18519) Use zero-copy strategy to optimize CellUtil.createCell
Chia-Ping Tsai created HBASE-18519: -- Summary: Use zero-copy strategy to optimize CellUtil.createCell Key: HBASE-18519 URL: https://issues.apache.org/jira/browse/HBASE-18519 Project: HBase Issue Type: Improvement Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai The IndividualBytesFieldCell, which is introduced by HBASE-14882, carries the input arguments without copying. We can substitute IndividualBytesFieldCell for KeyValue used by CellUtil.createCell. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18528) Support to modify TableDescriptor/ColumnFamilyDescriptor through MasterObserver; Or disable that.
Chia-Ping Tsai created HBASE-18528: -- Summary: Support to modify TableDescriptor/ColumnFamilyDescriptor through MasterObserver; Or disable that. Key: HBASE-18528 URL: https://issues.apache.org/jira/browse/HBASE-18528 Project: HBase Issue Type: Sub-task Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Priority: Critical Fix For: 3.0.0, 2.0.0-alpha-2 We are replacing the HTableDescriptor by TableDescriptor from code base. The TableDescriptor is designed to be a read-only object so user can't modifiy it through MasterObserver. HBASE-18502 change many methods of MasterObserver to use TableDescriptor but some deprecated methods still accept the HTableDescriptor. User may be confused by why some methods can't modify the table descriptor. In short, Should we allow user to modify the passed table descriptor? # if yes, we should introduce a mechanism that user can return a modified table descripror # if no, we should pass ImmutableHTableDescriptor to user. Or we just remove all methods accepting the HTableDescriptor Ditto for HColumnDescriptor. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18611) Copy all tests from o.a.h.h.p.TestProtobufUtil to o.a.h.h.s.p.TestProtobufUtil
Chia-Ping Tsai created HBASE-18611: -- Summary: Copy all tests from o.a.h.h.p.TestProtobufUtil to o.a.h.h.s.p.TestProtobufUtil Key: HBASE-18611 URL: https://issues.apache.org/jira/browse/HBASE-18611 Project: HBase Issue Type: Task Components: Protobufs Affects Versions: 2.0.0-alpha-1, 3.0.0 Reporter: Chia-Ping Tsai Priority: Minor Fix For: 2.0.0 We copied all codes from o.a.h.h.p.TestProtobufUtil to o.a.h.h.s.p.ProtobufUtil, but we ignored the test codes. Let us increase the code coverage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18634) Fix client.TestClientClusterStatus
Chia-Ping Tsai created HBASE-18634:
--
Summary: Fix client.TestClientClusterStatus
Key: HBASE-18634
URL: https://issues.apache.org/jira/browse/HBASE-18634
Project: HBase
Issue Type: Bug
Components: test
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Fix For: 2.0.0
After HBASE-18511, the master doesn't carry any regions by default. Hence, The
active master doesn't report its load because the report thread is sleeping in
waitForMasterActive().
{code}
protected void waitForMasterActive(){
boolean tablesOnMaster = LoadBalancer.isTablesOnMaster(conf);
while (!(tablesOnMaster && activeMaster) && !isStopped() && !isAborted()) {
sleeper.sleep();
}
}
{code}
In conclusion, the ClusterStatue#getServers won't contain the master name.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18637) Update the link of "Bending time in HBase"
Chia-Ping Tsai created HBASE-18637:
--
Summary: Update the link of "Bending time in HBase"
Key: HBASE-18637
URL: https://issues.apache.org/jira/browse/HBASE-18637
Project: HBase
Issue Type: Bug
Components: documentation
Reporter: Chia-Ping Tsai
Fix For: 2.0.0
{code:title=datamodel.adoc}
link:http://outerthought.org/blog/417-ot.html[Bending time in HBase]
{code}
The link is changed to "https://www.ngdata.com/bending-time-in-hbase/;
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18638) The old cells will return to client if the new cells are deleted
Chia-Ping Tsai created HBASE-18638: -- Summary: The old cells will return to client if the new cells are deleted Key: HBASE-18638 URL: https://issues.apache.org/jira/browse/HBASE-18638 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Priority: Critical |put_0(t0)| |put_1(t1)| <-- the latest cell If we call get, the put_1 will return. That is good. If we call get after a delete, the put_0 will return. That is weird. The put_0 is old data, and it should be dropped in flush. For client, put_0 should not exist after the put_1 happen. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18627) Fix TestRegionServerReadRequestMetrics
Chia-Ping Tsai created HBASE-18627: -- Summary: Fix TestRegionServerReadRequestMetrics Key: HBASE-18627 URL: https://issues.apache.org/jira/browse/HBASE-18627 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Fix For: 2.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-15804) Some links in documentation are 404
[
https://issues.apache.org/jira/browse/HBASE-15804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-15804.
Resolution: Duplicate
see HBASE-15461
> Some links in documentation are 404
> ---
>
> Key: HBASE-15804
> URL: https://issues.apache.org/jira/browse/HBASE-15804
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Heng Chen
> Attachments: HBASE-15804.patch
>
>
> http://hbase.apache.org/book.html#security
> The link to {{Understanding User Authentication and Authorization in Apache
> HBase}} return 404
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-16075) TestAcidGuarantees is flaky
[ https://issues.apache.org/jira/browse/HBASE-16075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-16075. Resolution: Duplicate see HBASE-17887 > TestAcidGuarantees is flaky > --- > > Key: HBASE-16075 > URL: https://issues.apache.org/jira/browse/HBASE-16075 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov > > https://builds.apache.org/job/HBase-1.3/744/jdk=latest1.7,label=yahoo-not-h2/testReport/junit/TEST-org.apache.hadoop.hbase.TestAcidGuarantees/xml/_init_/ -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-18019) Clear redundant memstore scanner
Chia-Ping Tsai created HBASE-18019:
--
Summary: Clear redundant memstore scanner
Key: HBASE-18019
URL: https://issues.apache.org/jira/browse/HBASE-18019
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Fix For: 2.0.0
The HBASE-17655 remove the MemStoreScanner and it causes that the
MemStore#getScanner(readpt) returns multi KeyValueScanner which consist of
active, snapshot and pipeline. But StoreScanner only remove one mem scanner
when refreshing current scanners.
{code}
for (int i = 0; i < currentScanners.size(); i++) {
if (!currentScanners.get(i).isFileScanner()) {
currentScanners.remove(i);
break;
}
}
{code}
The older scanners kept in the StoreScanner will hinder GC from releasing
memory and lead to multiple scans on the same data.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-18193) Master web UI presents the incorrect number of regions
Chia-Ping Tsai created HBASE-18193:
--
Summary: Master web UI presents the incorrect number of regions
Key: HBASE-18193
URL: https://issues.apache.org/jira/browse/HBASE-18193
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0, 3.0.0
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Priority: Minor
{code:title=RegionStates.java}
public Map
getRegionByStateOfTable(TableName tableName) {
final State[] states = State.values();
final Map tableRegions =
new HashMap(states.length);
for (int i = 0; i < states.length; ++i) {
tableRegions.put(states[i], new ArrayList());
}
for (RegionStateNode node: regionsMap.values()) {
tableRegions.get(node.getState()).add(node.getRegionInfo());
}
return tableRegions;
}
{code}
It always returns all regions...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-18268) Eliminate the findbugs warnings for hbase-client
Chia-Ping Tsai created HBASE-18268: -- Summary: Eliminate the findbugs warnings for hbase-client Key: HBASE-18268 URL: https://issues.apache.org/jira/browse/HBASE-18268 Project: HBase Issue Type: Sub-task Reporter: Chia-Ping Tsai -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18266) suppress the warning from the spotbugs
Chia-Ping Tsai created HBASE-18266: -- Summary: suppress the warning from the spotbugs Key: HBASE-18266 URL: https://issues.apache.org/jira/browse/HBASE-18266 Project: HBase Issue Type: Task Reporter: Chia-Ping Tsai Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 2.0.0-alpha-2, 1.1.12 It is hard to get +1 from QA currently because spotbugs is always unhappy... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18267) The result from the postAppend is ignored
Chia-Ping Tsai created HBASE-18267:
--
Summary: The result from the postAppend is ignored
Key: HBASE-18267
URL: https://issues.apache.org/jira/browse/HBASE-18267
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
{code:title=RegionCoprocessorHost.java|borderStyle=solid}
/**
* @param append Append object
* @param result the result returned by the append
* @throws IOException if an error occurred on the coprocessor
*/
public void postAppend(final Append append, final Result result) throws
IOException {
execOperation(coprocessors.isEmpty() ? null : new RegionOperation() {
@Override
public void call(RegionObserver oserver,
ObserverContext ctx)
throws IOException {
oserver.postAppend(ctx, append, result);
}
});
}
/**
* @param increment increment object
* @param result the result returned by postIncrement
* @throws IOException if an error occurred on the coprocessor
*/
public Result postIncrement(final Increment increment, Result result) throws
IOException {
return execOperationWithResult(result,
coprocessors.isEmpty() ? null : new RegionOperationWithResult()
{
@Override
public void call(RegionObserver oserver,
ObserverContext ctx)
throws IOException {
setResult(oserver.postIncrement(ctx, increment, getResult()));
}
});
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18088) The version of scala plugin in the reporting section is missing
Chia-Ping Tsai created HBASE-18088:
--
Summary: The version of scala plugin in the reporting section is
missing
Key: HBASE-18088
URL: https://issues.apache.org/jira/browse/HBASE-18088
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Chia-Ping Tsai
Priority: Trivial
Fix For: 2.0.0
I just noticed the following warns.
{code}
[WARNING] Some problems were encountered while building the effective model for
org.apache.hbase:hbase-resource-bundle:jar:2.0.0-SNAPSHOT
[WARNING] 'reporting.plugins.plugin.version' for
org.scala-tools:maven-scala-plugin is missing. @
org.apache.hbase:hbase:2.0.0-SNAPSHOT, /home/chia7712/apache/hbase/pom.xml,
line 3212, column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.apache.hbase:hbase-server:jar:2.0.0-SNAPSHOT
[WARNING] 'reporting.plugins.plugin.version' for
org.scala-tools:maven-scala-plugin is missing. @
org.apache.hbase:hbase:2.0.0-SNAPSHOT, /home/chia7712/apache/hbase/pom.xml,
line 3212, column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.apache.hbase:hbase-thrift:jar:2.0.0-SNAPSHOT
[WARNING] 'reporting.plugins.plugin.version' for
org.scala-tools:maven-scala-plugin is missing. @
org.apache.hbase:hbase:2.0.0-SNAPSHOT, /home/chia7712/apache/hbase/pom.xml,
line 3212, column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.apache.hbase:hbase-shell:jar:2.0.0-SNAPSHOT
[WARNING] 'reporting.plugins.plugin.version' for
org.scala-tools:maven-scala-plugin is missing. @
org.apache.hbase:hbase:2.0.0-SNAPSHOT, /home/chia7712/apache/hbase/pom.xml,
line 3212, column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.apache.hbase:hbase-protocol-shaded:jar:2.0.0-SNAPSHOT
[WARNING] 'reporting.plugins.plugin.version' for
org.scala-tools:maven-scala-plugin is missing. @
org.apache.hbase:hbase:2.0.0-SNAPSHOT, /home/chia7712/apache/hbase/pom.xml,
line 3212, column 15
{code}
We should add the version of the plugin to eliminate the warning.
{code:title=pom.xml#3212|borderStyle=solid}
org.scala-tools
maven-scala-plugin
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-18069) Fix flaky test TestReplicationAdminWithClusters#testDisableAndEnableReplication
Chia-Ping Tsai created HBASE-18069:
--
Summary: Fix flaky test
TestReplicationAdminWithClusters#testDisableAndEnableReplication
Key: HBASE-18069
URL: https://issues.apache.org/jira/browse/HBASE-18069
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Priority: Trivial
Fix For: 2.0.0, 1.4.0
If we run testDisableAndEnableReplication, we will get the following error
message.
{code}
testDisableAndEnableReplication(org.apache.hadoop.hbase.client.replication.TestReplicationAdminWithClusters)
Time elapsed: 2.046 sec <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at
org.apache.hadoop.hbase.client.replication.TestReplicationAdminWithClusters.testDisableAndEnableReplication(TestReplicationAdminWithClusters.java:160)
{code}
The critical code is shown below.
{code}
admin1.disableTableReplication(tableName);
HTableDescriptor table = admin1.getTableDescriptor(tableName);
for (HColumnDescriptor fam : table.getColumnFamilies()) {
assertEquals(fam.getScope(), HConstants.REPLICATION_SCOPE_LOCAL);
}
table = admin2.getTableDescriptor(tableName);
for (HColumnDescriptor fam : table.getColumnFamilies()) {
assertEquals(fam.getScope(), HConstants.REPLICATION_SCOPE_LOCAL);
}
{code}
Is HTD got from admin2 affected by admin1? I don't think so. We should remove
the related assertion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-18158) Two running in-memory compaction threads may lose data
Chia-Ping Tsai created HBASE-18158:
--
Summary: Two running in-memory compaction threads may lose data
Key: HBASE-18158
URL: https://issues.apache.org/jira/browse/HBASE-18158
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Chia-Ping Tsai
Fix For: 2.0.0
{code:title=CompactingMemStore.java|borderStyle=solid}
private void stopCompaction() {
if (inMemoryFlushInProgress.get()) {
compactor.stop();
inMemoryFlushInProgress.set(false);
}
}
{code}
The stopCompaction() set inMemoryFlushInProgress to false so there may be two
in-memory compaction thread are executed simultaneously. If there are two
running InMemoryFlushRunnable, the later InMemoryFlushRunnable may change the
versionedList.
{code:title=MemStoreCompactor.java|borderStyle=solid}
public boolean start() throws IOException {
if (!compactingMemStore.hasImmutableSegments()) { // no compaction on empty
pipeline
return false;
}
// get a snapshot of the list of the segments from the pipeline,
// this local copy of the list is marked with specific version
versionedList = compactingMemStore.getImmutableSegments();
{code}
And the first InMemoryFlushRunnable will use the chagned versionedList to
remove the corresponding segments.
{code:title=MemStoreCompactor#doCompaction|borderStyle=solid}
if (!isInterrupted.get()) {
if (resultSwapped = compactingMemStore.swapCompactedSegments(
versionedList, result, (action==Action.MERGE))) {
// update the wal so it can be truncated and not get too long
compactingMemStore.updateLowestUnflushedSequenceIdInWAL(true); //
only if greater
}
}
{code}
In conclusion, first InMemoryFlushRunnable will remove the worng segment. And
the later InMemoryFlushRunnable will introduce NPE because first
InMemoryFlushRunnable set versionedList to null after compaction.
{code}
Exception in thread
"RpcServer.default.FPBQ.Fifo.handler=3,queue=0,port=45712-inmemoryCompactions-1496563908038"
java.lang.NullPointerException
at
org.apache.hadoop.hbase.regionserver.CompactionPipeline.swap(CompactionPipeline.java:119)
at
org.apache.hadoop.hbase.regionserver.CompactingMemStore.swapCompactedSegments(CompactingMemStore.java:283)
at
org.apache.hadoop.hbase.regionserver.MemStoreCompactor.doCompaction(MemStoreCompactor.java:212)
at
org.apache.hadoop.hbase.regionserver.MemStoreCompactor.start(MemStoreCompactor.java:122)
at
org.apache.hadoop.hbase.regionserver.CompactingMemStore.flushInMemory(CompactingMemStore.java:388)
at
org.apache.hadoop.hbase.regionserver.CompactingMemStore$InMemoryFlushRunnable.run(CompactingMemStore.java:500)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-18159) Oracle JDK 7 is now only available for those with an Oracle Support account
Chia-Ping Tsai created HBASE-18159: -- Summary: Oracle JDK 7 is now only available for those with an Oracle Support account Key: HBASE-18159 URL: https://issues.apache.org/jira/browse/HBASE-18159 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Priority: Critical Context: https://builds.apache.org/job/PreCommit-HBASE-Build/7064/console Ref: http://www.webupd8.org/2017/06/why-oracle-java-7-and-6-installers-no.html I make this as critical because it is hard to get a +1 from HadoopQA for branch-1. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-9764) htable AutoFlush is hardcoded as false in PerformanceEvaluation
[
https://issues.apache.org/jira/browse/HBASE-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-9764.
---
Resolution: Won't Fix
PE don't use the AutoFlush flag because the HTable is deprecated
> htable AutoFlush is hardcoded as false in PerformanceEvaluation
> ---
>
> Key: HBASE-9764
> URL: https://issues.apache.org/jira/browse/HBASE-9764
> Project: HBase
> Issue Type: Bug
> Components: Performance, test
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Attachments: HBASE-9764-0.94-v1.patch
>
>
> In PerformanceEvaluation, htable AutoFlush option is hardcoded as false
> {code:title=PerformanceEvaluation.java|borderStyle=solid}
> void testSetup() throws IOException {
> this.admin = new HBaseAdmin(conf);
> this.table = new HTable(conf, tableName);
> this.table.setAutoFlush(false);
> this.table.setScannerCaching(30);
> }
> {code}
> This makes the write performace unreal.
> Should we add an autoflush option in PerformanceEvaluation?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-11223) Limit the actions number of a call in the batch
[
https://issues.apache.org/jira/browse/HBASE-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-11223.
Resolution: Duplicate
We had implemented the limit in the client (see HBASE-17408) and server (see
HBASE-14946)
> Limit the actions number of a call in the batch
>
>
> Key: HBASE-11223
> URL: https://issues.apache.org/jira/browse/HBASE-11223
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.99.0
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>
> Huge batch operation will make regionserver crash for GC.
> The extreme code like this:
> {code}
> final List deletes = new ArrayList();
> final long rows = 400;
> for (long i = 0; i < rows; ++i) {
> deletes.add(new Delete(Bytes.toBytes(i)));
> }
> table.delete(deletes);
> {code}
> We should limit the actions number of a call in the batch.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-18201) add UT and docs for DataBlockEncodingTool
Chia-Ping Tsai created HBASE-18201: -- Summary: add UT and docs for DataBlockEncodingTool Key: HBASE-18201 URL: https://issues.apache.org/jira/browse/HBASE-18201 Project: HBase Issue Type: Task Reporter: Chia-Ping Tsai Priority: Minor There is no example, documents, or tests for DataBlockEncodingTool. We should have it friendly if any use case exists. Otherwise, we should just get rid of it because DataBlockEncodingTool presumes that the implementation of cell returned from DataBlockEncoder is KeyValue. The presume may obstruct the cleanup of KeyValue references in the code base of read/write path. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-17948) RegionServer: Unable to fetch region information. java.net.UnknownHostException: cilm063-thinkcentre-a58
[ https://issues.apache.org/jira/browse/HBASE-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-17948. Resolution: Not A Problem Please ask question in HBase user mailing list > RegionServer: Unable to fetch region information. > java.net.UnknownHostException: cilm063-thinkcentre-a58 > > > Key: HBASE-17948 > URL: https://issues.apache.org/jira/browse/HBASE-17948 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.2.4 > Environment: Ubuntu 14.04 Linux >Reporter: Hemant Jain > Fix For: 1.2.4 > > > I have installed HBase (1.2.4) Hadoop(2.7.3) on Master slave multi cluster > combination. > Master > /etc/hosts/ > 127.0.0.1 developer4 > 192.168.1.149 master > 192.168.1.161 slave > Slave > 127.0.0.1 cilm063-ThinkCentre-A58 > 192.168.1.149 master > 192.168.1.161 slave > I have properly installed Hbase and working fine. > When I run the below command then getting following error. > hbase hbck details > ERROR: RegionServer: cilm063-thinkcentre-a58,16020,1492865892520 Unable to > fetch region information. java.net.UnknownHostException: > cilm063-thinkcentre-a58 > Please help me where I am doing wrong. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-17636) Fix speling [sic] error in enable replication script output
[
https://issues.apache.org/jira/browse/HBASE-17636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved HBASE-17636.
Resolution: Duplicate
duplicate, as [~Jan Hentschel] said.
> Fix speling [sic] error in enable replication script output
> ---
>
> Key: HBASE-17636
> URL: https://issues.apache.org/jira/browse/HBASE-17636
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 1.3.1
>Reporter: Lars George
>
> When enabling the replication for a table:
> {noformat}
> hbase(main):012:0> enable_table_replication 'repltest'
> 0 row(s) in 7.6080 seconds
> The replication swith of table 'repltest' successfully enabled
> {noformat}
> See {{swith}} as opposed to {{switch}}. Also, that sentence is somewhat too
> complicated. Better is maybe {{Replication for table successfully
> enabled.}}?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17980) Any HRegionInfo we give out should be immutable
Chia-Ping Tsai created HBASE-17980: -- Summary: Any HRegionInfo we give out should be immutable Key: HBASE-17980 URL: https://issues.apache.org/jira/browse/HBASE-17980 Project: HBase Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Chia-Ping Tsai Fix For: 2.0.0 This is similar to HBASE-15583. # Introduce RegionInfo class. HRegionInfo will extend RegionInfo. # Deprecate HRegionInfo to be removed in 3.0 # RegionInfo contain all of the read-only methods of HRegionInfo # Add "RegionInfo Builder" -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-8028) Append, Increment: Adding rollback support
[ https://issues.apache.org/jira/browse/HBASE-8028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-8028. --- Resolution: Won't Fix We don't need the rollback in 2.0.0 after committing the HBASE-15158. The rollback for Append/Increment in 1.x has been fixed by HBASE-17519. > Append, Increment: Adding rollback support > -- > > Key: HBASE-8028 > URL: https://issues.apache.org/jira/browse/HBASE-8028 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.94.5 >Reporter: Himanshu Vashishtha >Assignee: Himanshu Vashishtha > Fix For: 2.0.0 > > Attachments: HBase-8028-v1.patch, HBase-8028-v2.patch, > HBase-8028-with-Increments-v1.patch, HBase-8028-with-Increments-v2.patch > > > In case there is an exception while doing the log-sync, the memstore is not > rollbacked, while the mvcc is _always_ forwarded to the writeentry created at > the beginning of the operation. This may lead to scanners seeing results > which are not synched to the fs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
